Few companies have the money to waste on useless or sub-optimal service providers, yet few seem to apply the necessary rigor to the money they spend on their technology organizations. The closest that they come is slashing budgets without understanding when costs ‘seem too high’.
Long post warning! tl;dr – I present best practices in setting a technology organization to fulfill business goals without wasting money.
Estimates are that 3 out of 4 venture-backed startups will fail to return venture capital amounts. Failure rates for bootstrapped startups may be more than 90%. One of the key reasons for failure of these companies is running out of money â€“ this results from many reasons but one of the significant expenses for many startups/small organizations is their information technology (IT) organization.
What is IT?
IT, short for information technology, covers a large number of areas. IT refers to any use of computer technology for business purposes. In larger organizations, it may refer exclusively to infrastructure or pure support functions. IT and its cousin IS (information services) are often lumped together in medium or larger size organizations to make best use of economies of scale.
IT/IS can consist of raw Internet connectivity, email systems, servers on which your systems are hosted, the development organization creating your apps and/or software, ERP, content management systems including SharePoint, and many other things. It also includes things such as your information and computer security, any policies associated with computer use by customers and employees, even how customer information is stored.
The first question that every organization needs to ask when thinking about setting their IT infrastructure is â€˜Whyâ€™ – why should your company have an IT organization? What will it do? What problems will it solve? The outcome of this step is to ensure that whatever you do with technology, you do with the business end goals in mind.
IT too often is one of the first groups that a business sets up â€“ part of this is pragmatic (everyone needs email, of course!) but part is that it is seen as something that has to be done as part of the initial setup. This attitude leads to a greater chance that companies will invest in IT organizations without properly considering their rate of return.
Ironically, when asking how to set up an IT organization, the first question should be why, followed by what. Too many startups and small organizations believe in the power of IT to
- solve problems that it is not intended to solve
- do things that it was not designed to do, and
- address problems that do not exist
This may seem controversial but all too often, the chief purpose of IT is forgotten or obscured â€“ it exists only to solve business problems. Period. Any other reason is irrelevant or fraudulent, and any movement away from this is a dilution of the business focus for an organization.
Unless your company explicitly provides infrastructure as a service (IaaS), platform as a service (PaaS), or some other variation, your IT is an enabling center. What it enables is your companyâ€™s business function â€“ your business goals, your strategic planning, and such. What it will not do is generate your business or ‘fill in the gaps’.
Note â€“ even if your business is selling apps or software as a service (SaaS), IT is not the product; it is how you deliver your product
An old saying is that â€˜customers do not buy a one-eight inch drill; they buy one-eight inch holesâ€™. IT is the drill â€“ your business needs to figure out where to drill the holes. This metaphor works even better when considering investment needs â€“ it does not benefit an organization at all being able to drill the hole twice as fast if it is the wrong size, in the wrong location, or goes too deep.
IT does serve a critical purpose in every organization â€“ it is a force multiplier, dramatically amplifying the work of people in sales, marketing, engineering, and project management. Too often, IT is treated like a hammer, able to smash down any problems, issues, or rough edges. Unfortunately, it often succeeds at doing this, at least at first.
To illustrate the extent of this issue, let us consider a 3- and 6-month â€˜delayâ€™ in which IT is not working on the top priority items of the business. With four developers, one QA person and one manager (using Calgary estimates, the full annual loaded costs of these people are approximately $160,000, $120,000 and $200,000, for a total of $860,000 â€“ for your local area, the ratios are similar even if the absolute amounts may change somewhat), the cost for 3 months is $210,000 and the 6 months is $420,000. These numbers are very conservative and although the total amount of this delay is not completely lost, it is reasonable to expect that we would lose at least 50% of it plus opportunity costs, client goodwill and time to market.
Given these, it is easy to see that lack of focus and alignment of IT to business goals can cost upwards of $400,000 annually even in the most optimistic scenarios and with the smallest companies. The best way to minimize this loss (it is impossible to eliminate it) is to ensure that IT is doing the highest value, highest priority work in any circumstance, at any time.
Note â€“ these conclusions do not change using external providers; they are in fact, worse, as there are fewer options for payments and negotiations with third parties
The first thing that any organization has to do is ensure that everyone from the CEO to the janitor understands understand its business goals. This is necessary to ensure that both the management and line staff involved in IT and the associated business units can make informed decisions about the expending their resources, both personal and company.
Another great technique is to drill down as an organization and determine exactly what and how IT will support the business. A good way to do this is to keep asking why you want your IT group to do a particular activity until you have the real reason â€“ at this point, you will be in the best position to determine if you still want to do this IT activity.
This is a standard technique for fault and postmortem analysis but it can be used with great effect to determine what you want to do with your technology group and, more importantly, why. Using this technique, companies can dive down to the heart of what they do and how to best use IT. To best facilitate this, ask why you need to do a particular activity or spend a particular resource. When you repeat this five times â€“ you may hit it sooner or have to do additional iterations â€“ you will reach the real reason why you do this activity.
Example of a key or necessary activity
â€œWe need to automate our code testingâ€ –> â€œWhy?â€ –> â€œTo test it several times a day, every dayâ€ –> â€œWhy?â€ –> â€œTo ensure that any changes, big or small, do not cause problems in parts of the system that we did not expectâ€ –> â€œWhy?â€ –> â€œTo ensure the smoothest, happiest experience for our customers and clients, even when adding new features or fixesâ€ –> â€œWhy?â€ –> â€œTo ensure that our customers keep us as a vendor and continue to pay usâ€
Example of a superfluous activity
Looking at these two examples, you can see that while some IT activities are useful and push the business forward, some do not. Understand that in the second situation, if the features had actually been important for the business activity or had been a real competitive or strategic differentiator, the final answer would have been a lot different.
What (will your IT do?)
Too often, one of two things can happen with a company â€“ IT can be either lumped together to include any and all things technology or conversely, the functions of IT can be separated ad infinitum, causing a glut of mini-organizations to exist. Neither of these scenarios is optimal â€“ the former does not allow for economies of scale by separating the critical from the mundane and the latter causes a huge barrier for coordination between the IT functions.
One area of IT compromised by the extensive siloing of IT function is disaster recovery and business continuity. One of the reasons for extensive testing of these recovery procedures in larger organizations is that the individual, isolated departments often have their own process and procedures for backing up and restoring information, based on their own unit preferences. Unless and until you have to separate IT functionality out to this level, keep it together as much as possible â€“ whatever â€˜lossesâ€™ you suffer from scale will more than be made up for with simplified backup, restoration and security procedures. This simplification can run up to an order of magnitude.
One simple way to split up an IT organization is with both operational IT (back office functionality, server management) and application development (software development, QA/testing, UI/UX, etc.) each having separate domains.
Note â€“ not all businesses will have the latter functionality; a bank or construction company may not have any need for these activities, for example, or if they do, they can use contractors or outsourced development.
Application development covers a wide range of activities from updating the web site and its functionality, to development apps and SaaS software through which business delivers its functionality. Again, this group does not do these activities for their own sake â€“ it does so to provide business functionality. This key concept should be emphasized and stressed at all times, both to the IT and business personnel.
How (will you organize your IT?)
Part of the problem with many organizations now is that there is a lack of clarity about where IT reports and to whom. Ideally, the IT organization should report to operations or product management/development â€“ these are the business areas that correspond most closely with the actual functions of IT. A group reporting to two different managers is a recipe for failure â€“ a solution to this is to split IT into operations and development as above or to have one of the business functions subsume the other (generally not the best idea).
Where (should your IT group live)
One of the first choices that an organization must make is in-house vs out-source. This choice is not as clear-cut as first thought, certainly not as clear as many people on the finance or accounting side would believe. The success of this decision depends on how clear the vision for your organizationâ€™s business goals is and how concrete is your idea of how IT can force multiply your business activities. In addition, it depends heavily on how much time is available to fulfill these requirements.
Generally speaking, the looser the requirements or tighter the timelines before the output of the IT activity is needed, the closer rein an organization must have on its IT and IS activities. The diagram below outlines the general relationship between time, requirements solidity, and success with outsourced IT functionality.
Note â€“ these general relationships will be different for both operational and application development functions; they will in fact be different for separate projects and should be considered differently
I realize that there are multiple people standing up now and screaming that, â€œNo! We outsourced all of our IT functionality and it all turned out perfect!â€ To those people, I say, â€œCongratulations â€“ you found the four leaf clover.â€ For everyone else, outsourcing has many inherent issues and problems.
The main decision needed with outsourcing
The biggest issue and decision with outsourcing relates to near shoring vs offshoring; basically, the selection of where the IT activities should be sourced â€“ same (or similar) country vs. different (usually developing) country, respectively. Almost all accounting and financial people push for offshored development and IT â€“ they only see the costs of the technology activities and are rarely responsible for the outcomes.
On a side note, one of the cost factors that is never factored into these decisions is that adding multiple low cost, low value resources imposes a very real organizational cost â€“ community complexity. The difficulties with communication for any project or work increases exponentially with the number of people involved. For anything more than completely trivial technology activities, it is more effective long-term to hire fewer people that are higher quality to simplify the communication channels. This does not mean that the use of multiple low cost resources is never the best bet â€“ it means that all costs, long term and short, must be part of the decision.
Offshore provider considerations
The main difference with near- and offshoring relates to the ability to communicate with the people doing the work. For offshore development, there are usually multiple barriers to communication â€“ language, cultural, and temporal (i.e., time zone differences). This presents a serious challenge for the proper management of offshored resources as well as proper communication of tenuous or incomplete requirements. This last difficulty is responsible for much of the failure associated with the offshore development.
With near-shore (or contract) development, both the problems and savings are more modest. For organizations attempting to realize some savings in their IT activities while attempting to optimize their ability to use requirements that are incomplete, this may be a reasonable option.
Offshoring takes more work, time, and attention
As mentioned before, there is a fair amount of anecdotal evidence that offshore IT projects, specifically application development, can succeed and provide useful outcomes. However, looking more closely at these successes, one notices that they usually have very low time pressure (i.e., development can occur over multiple quarters or years), very solid requirements (i.e., translation or UI projects, or for the more historic minded, Y2K turnover projects) or low management impact (do not require much shepherding). In the event that the project or functionality meets these conditions, your company may wish to consider offshored development for these.
One of the critical pieces for the success of outsourced IT activities, particularly offshore, is how much time is available to fulfill any particular project. With additional time available for discussion and back-and-forth improvement in the project outputs, even teams with communication issues can produce a valuable, useful product.
There are multiple other issues associated with offshoring, however. For example, near shoring means that the vendors to whom you are sending your IT work are subject to the same laws as you are â€“ this is not inconsequential in finance, security, health, government or military contract work. If companies consider this possibility as part of an organizationâ€™s financial perspective, they must also account for policy or security compliance and fixing the previous outputs in its final cost.
For an organization to embed IT/technology into its infrastructure properly, we suggest performing the following steps in order
- Determine what that base business goals for the organization are
- Determine how IT can support these business goals, both strategically and tactically
- Determine the ROI for IT investment
- Determine the wasted investment in IT you currently spend
- Determine the best way to organize your IT organization, including ultimate reporting authority
- Determine on a function-by-function or project-by-project basis whether to in-house, near-shore, or offshore
- Include all costs when assessing where and how IT activities are performed
Image courtesy of Paul Downey / flickr.com