« Smells Like ... Victory | Main | Obligations »
June 23, 2006
Build or Buy
One of the most common decisions that IT executives have to make is whether to build custom software to meet a business need, or to buy COTS (commercial off-the-shelf) software to meet that need. As you might suspect, COTS vendors tend to believe that a 100% buy solution is best for everyone, and large outsourcing vendors tend to believe that a 100% build solution is best for everyone. The fact that each is recommending the solution that happens to be most profitable to them is, of course, incidental: just look at the piles of arguments we've come up with, borrowed or paid for!
The major arguments of the 100% build side are that developing custom software is wasteful (inefficient and costly, and then you eventually discard the software anyway), risky (if you fail, who do you turn to for support?) and distracting (shouldn't you really be worried about your core business?). The major arguments of the 100% build side are that custom software meets your business needs exactly; custom software can give you a business advantage over your competitors; and if your business model changes, your custom software can evolve to meet your requirements, while COTS software often cannot, or at least not quickly. The dirty little secret of both is that both are entirely correct in their arguments, but neither really addresses the way that you can decide which type of solution best meets your needs. Please, allow me.
The first consideration is whether the business need being met is common across all companies. An example of this would be presentation tools, or word processors, or print queueing software. In those cases, there is zero controversy: buy a COTS tool.
The second consideration is whether the business need being met is unique to your company. If no other company in the world has a need for this tool, there is no COTS tool to address it, and thus no controversy: you have to build a tool or change your business.
Now things get more complicated, because those really are the only two bright-line rules that are available to an IT executive making these decisions. All other choices are balancing trade-offs. Before we get into how to make the decision, let's consider those factors being traded.
The biggest two factors in most managers' heads are schedule and budget, and they are closely linked. The longer it takes to develop or deploy something, the higher the cost because the people have to be paid for all the time. But reducing the schedule arbitrarily can increase costs beyond those that would be saved by employing people on the project for less time. Consider: if functionality has to be dropped, causing the business need to be met less well; or if milestones are constantly missed, causing the business to have to rework their plans for acceptance testing and deployment, the cost of reworking the business around the change is almost always higher than the labor cost estimated to be saved. Worse, the estimated savings don't materialize if the project misses deadlines, because the people are still there doing the work after your estimated budget for people costs has run dry. Also, look at TCO very closely. It can cost more to implement many COTS products (particularly very complex suites like PeopleSoft and SAP) than it would take to build your own software to meet your needs. (In the case of financial systems, though, unless you are a financial company, I would advise against it: the risks of missing or misinterpreting government regulations are quite high.)
The next most important factor is your IT department's ability to deliver on projects. Some IT managers can staff a project, gather detailed and testable requirements, monitor project managers and architects, know when to get involved, know when to stay out of the mud, and focus on the needs of the business; these are the managers who will consistently deliver their projects, usually on time and budget. Conversely, some IT managers are completely incapable of one or more of those management skills, and cannot deliver on time and on budget even if their project is to install MS Office in a department. Depending on the mix of skills and abilities among the managers, you might be able to deploy COTS or develop custom software, but not both. Recognizing this reality can help you to (a) correct it, or (b) make appropriate choices to increase the chance of successfully delivering a solution to the business.
There is an aside about management that is too critical not to mention here, even though it's a bit off-topic. You as an executive are a manager, too. If your department consistently cannot deliver projects, consider that you might be the problem. Either you've hired bad managers; or created or allowed procedures and policies that impede effective delivery; or forced your managers to respond to constantly changing requirements, schedules and budgets; or failed to understand what the business needs.
Back to the topic at hand. The next consideration is whether meeting 85% of the business need is enough, because that's about all you will usually get with COTS products. In many cases, that really is sufficient, and the gaps can be filled manually or with a process modification to better match the software. Typically, you can easily absorb this level of imperfect match of solution and requiremenst in areas that are not core to your business. A bank can accept, for example, COTS packages for HR, but might not be able to accept COTS packages for auditing accounts. In your core business area, unless everyone in your industry does things the same way, COTS packages are often not the best choice, because they force you to compromise your core methodologies, or work around the software, in order to be productive. A nearly 100% build policy in non-core, but still important, business areas can cost you, because a focus on meeting every need all the time in the systems can result in added acquisition and development costs that are not justified by the slight improvements in productivity that could be gained.
Your core business is the one place where you can hope to gain a competitive advantage through superior systems and the efficiencies they produce. If there are opportunities to save 10% of the time it takes to do the most common tasks required for your core business, and if you can realize those opportunities, you can beat your competition on price, quality or both. If you have adopted a 100% COTS policy, here is where you will fall behind your competitors. (Which is not to say that you definitely needs a custom solution here. Once you adopt a 100% buy or nearly 100% build mindset, you will simply miss many opportunities to do things better the other way. Agility is more effective and profitable than controllability in many cases.)
Finally, the legacy environment into which systems must be integrated has to be considered. The key factor in predicting schedules and budgets is comparison to similar tasks performed previously. If you know how long it takes to implement COTS package A, or develop service B, because you've done it before, you can predict your schedule and budget with some accuracy. One key reason why project management does not work as well with enterprise IT systems as it does with, say, building a bridge is that bridges don't have to deal with legacy systems. Often, even with a COTS package that has been implemented at a thousand companies, you will find that your environment has legacy systems that the new package has never before been integrated with. If you have an environment with many proprietary legacy systems, integration of new COTS systems is exponentially harder than in a relatively clean environment. By contrast, building a solution into an environment heavy with legacy systems often still results in inefficient systems (inevitable in having to do many stages of extract/transform/load (ETL) or writing interfaces for many different protocols), but at least you will be able to ensure that the system integrates well into the current environment. Sadly, in an environment with many legacy systems, it is often the case that adding a new COTS package worsens the problem for the next project, because there's one more proprietary package that your project teams have to figure out how to work with. Where you do buy COTS packages, try very, very hard to ensure that they use industry-standard protocols for inter-system communications, or you may eventually build an environment that cannot grow until many critical systems are ripped out and replaced at more or less the same time. This is not a career-enhancing move.
So when considing schedule and budget, management abilities, system criticality and how closely the system meets business requirements, competative advantage and legacy systems in the environment, how does one decide to weight each factor? Sadly, there is no easy rule for this, because each company is different. I will propose a few rules of thumb, though:
- If any of the five key trade-offs strongly suggests a solution be COTS or be custom, make everything else work around that.
- If one or more trade-offs strongly suggests COTS or custom, and one or more of the other trade-offs strongly suggests the opposite, you have a business conflict that has to be solved before you can provide a system to match. First fix the business problem, then reevaluate.
- The most critical success factor is management capability: you cannot do what you cannot do. You can fix this with hiring or policy changes, or simply accept that your current structure compels a build or a buy decision.
- After management capability, competative advantage is the key decision driver. If you cannot gain a competative advantage from a system, don't build it unless there is no COTS product that can meet your needs. It's sufficient in non-core areas to meet 85% of the needs, and in peripheral areas meeting 50% of the business' needs may be sufficient. In core areas, meeting 100% of the business needs can be vital. In fact, it's often the case that using IT architects to map the business process can result in process improvements even if no system is implemented, because the actual business process is rarely fully understood, even within the business. In core areas, rolling your own is often a good idea even when there is a promising COTS package, unless that package meets every business need completely.
- Next most important is what it's going to cost and how long it's going to take to implement a solution. Most of the time, this favors COTS products, but not always. Do your due diligence here on how long similar companies have taken to implement the COTS solution, and don't just trust the COTS vendor's word on that: call the customers.
- Finally, the environment is rarely dispositive — at least, not directly. Generally, the environment really acts as a driver by altering the cost and schedule to implement. In some cases (where you depend on a protocol that COTS products for that space don't support, for example), environment can become directly important. In any case, it's vitally important that your managers and vendors know the environment they are deploying into, or they will be likely to blow right through their schedules without slowing down. In heavily legacy-driven environments, COTS products are usually much more difficult to integrate than generally advertised or expected.
This discussion brings up more questions, like how to reduce project risk (more to the point, why most projects fail), whether to use open source products in your business, how to identify areas where IT can make a business more profitable, whether enterprise architecture methodologies are really worth the investment, whether and when to oursource and a host of others. Topics for another day, I'm afraid.
But if you're interested in knowing about any of those, let me know, and someday I'll tackle it.
Trackback Pings
TrackBack URL for this entry:
http://www.caerdroia.org/MT/mt-tb.cgi/1029