October 15, 2012
Clearly, build versus buy is fundamental to the way that a project is to be executed. If 100 percent of the scope is going to be built in house, then you have a very different schedule, WBS, set of risks, acceptance criteria and resourcing needs than if 100 percent of the scope is to be outsourced. The decision changes literally every element of the project, except perhaps the scope. In many cases, the decision isn’t that black and white--some elements will be developed in house and some will be outsourced. But with such a wide ranging impact, how do you decide on the best approach?
The fundamentals
There are a few very basic considerations that we have to start with--and that will shape much of the decision. The first consideration has to be the preferences of the sponsor and customer. We can argue that the business stakeholders are responsible for defining the “what” of a project (scope and requirements) and the project team gets to make the decision on the “how” (which is where build vs. buy clearly sits), but the reality is never going to be that simple. We have to consider the preferences of the stakeholders, and while we won’t always align with those preferences completely they should still carry substantial weight.
The second issue that is fundamental to the decision is capability--do we have the skills and resources in house to do the work ourselves? If the technology is something that our teams are skilled and experienced in--and the business/product issues are ones that we are familiar with--then we are more capable of developing the solution in house than if the solution requires us to use unfamiliar technology and expand into new product areas. However, if this is going to be an ongoing need, then we may want to begin developing those skills in house through training and recruitment rather than create a long-term reliance on a vendor. Finally in this area, we have to consider what is available to buy--we cannot always assume that there are reliable vendors available to us who are capable of partnering with us on the solution; we may have no choice but to build.
Constraints drive considerations
The other main area to be considered is the major constraints and how they are impacted by our decision. The most obvious of these is budget, and you could argue that this should be considered in the fundamental category because it generally carries so much weight. Fair enough, but while it may be a significant constraint, we shouldn’t be making budget-based decisions in isolation from the other constraints. If the overall project cost is a fixed number, then we may be forced to take one course of action--but we have to recognize that the other constraints will also drive indirect costs.
Risk should be a major factor in making the decision, and both approaches will have their own risks (which will drive costs in the form of risk management and a need for reserves). If we buy, then we are transferring some of the risk for the solution to a partner, but we are trading that off for a lack of control and potentially a loss of secrecy and the competitive advantage that can come from an unexpected new product. On the other hand, if we build then we are assuming all of the risk for delays, problems and cost overruns ourselves with no recourse.
Quality also needs to factor in, and again this has a cost element associated with it. If we build the product ourselves then we have more control over quality--we can test at various different stages and correct if necessary, but we may not have the expertise to recognize some potential quality issues. A buy decision reduces the access that we have to testing and validating quality, even in an agile-based development process; but it should also provide a higher likelihood for a quality solution.
One of the often overlooked factors in a build vs. buy decision is the project scope. If we are confident that the scope that we have defined is exactly what we need, then we can be less concerned; but if there are still elements of uncertainty, then we need to be conscious that a buy decision may result in expensive changes or a product that doesn’t fully meet the needs. Either approach will only give the customer what is asked for, not necessarily what they need; but it’s usually easier to restore the alignment between those two elements with a build decision.
Conclusion
I am always amazed at how little time some organizations will put into deciding whether to build or buy. It’s a decision that has such a profound impact on the project and the product that comes from the initiative that it really needs considerable discussion and consideration among stakeholders. Yet often it seems as though the decision is predetermined before the scope is approved--and we wonder why so many projects fail.
Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at andy.jordan@roffensian.com. Andy is also on Twitter at RoffensianPM.