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.jordan@roffensian.com. 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.

ADVERTISEMENT

Trending Articles

Generating a Useful Construction Activities Work Schedule

by Edwin Rivera Sierra

Construction project planning requires creating detailed construction activities work schedules. Being organized with all your construction documents can minimize missing key information. Learn how to develop a clear and complete schedule, and how it can make a complex project seem a bit easier to handle.

Topic Teasers Vol. 48: Irritating Web Design

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

Question: I’m a programmer, but this is my first agile team and first web design project. Even though I hear customer feedback is a big part of agile, my organization doesn’t have a process to allow for it beyond the opinions of the team members and a few surrounding employees. I’m sure some of my colleagues have ideas, but what kinds of things on websites are known to irritate the public in general?
A. As long as your website loads quickly and serves the basic function of allowing purchases, downloading data or providing product information for customers, it’s a successful website.
B. Customer loyalty, goodwill, purchasing your products and posting favorable comments on social media rest on your knowing what the public at large likes and dislikes. In the absence of company sponsored studies of your customers, rely on the internet and your own informal questioning of people with whom you come into contact.
C. Your new agile team will include members who are more experienced than you. They will show you how to keep the new website creation consistent with those of the past. It is more important to have it look and feel the same as it always has than for you to implement changes, even if they are customer driven.
D. Use your own personal preferences as a guideline for what you will agree to create for your portion of this new corporate website. Your opinions matter as much as those of anyone else on the team, because after all you have had customer experiences on other websites.
Pick your answer then Test Your Knowledge!

The Coming Irrelevance of On Time, On Scope, On Budget

by Andy Jordan

Everything that you thought you knew will soon be wrong. Are you prepared for that? Project managers rarely give benefits a second thought. This needs to change, and in the near future it will change with an increasing focus on project management that prioritizes business benefits over arbitrary constraint compliance.

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.


comments

Network:0

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

ADVERTISEMENTS
ADVERTISEMENT

Sponsors