Build or Buy: How Do You Decide?

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's new book Risk Management for Project Driven Organizations is now available.

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.


Trending Articles

Are You Ready to Go Agile? (Part 2 of 3)

by Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP

This second article continues the discussion by looking at the second group of factors related to the readiness (and willingness) of the project team to adopt agile best practices. As with sponsorship factors, we need to consider cultural, structural and management aspects.

Topic Teasers Vol. 43: Benefits Management Is Hard!

by Barbee Davis, MA, PHR, PMP, PMI-ACP

Question: How much more can they heap on a project manager? Now I’m being asked to handle the benefits management for this project. There was nothing about this in my PMP prep course, or on the exam. Is the latest trend that anything no one wants to do becomes the responsibility of the PM? How do I proceed when I don’t even understand what this is?
A. Benefits management is now often asked of the project manager, but you should position yourself as the process facilitator, not the “responsible party”. Otherwise, they’ll blame you if the project benefits aren’t realized.
B. Benefits management has to do with salary, union contracts, insurance, 401K plans, sexual harassment concerns and training classes. It is rightly positioned in the human resources department, not in a project environment.
C. Since the outcome of your project is the sole indicator of whether or not the business objective will produce revenue, tracking benefits realization logically fits into the responsibility of the project manager.
D. Tracking benefits management is a time inhibitor in a project plan. For that reason, if your project is to finish as estimated, benefits management should be outsourced to a third-party organization.
Pick your answer then Test Your Knowledge!

Governance for Success — Six Elements Program Sponsors Need to Address

by Todd Bagley,Jim Gorski

The scope and dependencies of a complex program never appear more intimidating than when viewed for the first time. Too often this can be the perspective of the program sponsor, who is trying to stay focused on the goals of the initiative while juggling the significant responsibilities of his or her day job. This tough job of program oversight and governance can be exacerbated when an executive program sponsor is not adequately prepared and has the wrong expectations. The most damaging missteps of program governance can usually be traced back to an incomplete understanding of the scope of the job and its codependences by someone designated to function as its steward.

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.

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 is also on Twitter at RoffensianPM.



In many organizations, the buy/lease/build decision is managed by the BA before the PM is engaged.


"One of the symptoms of approaching nervous breakdown is the belief that one's work is terribly important."

- Bertrand Russell