Build or Buy

A Build or Buy decision informs an organization if a proposed solution (normally in the form of a Portfolio Request) should be built "in house", provided by a supplier or otherwise acquired "off the shelf".

Organizations with significant internal development capabilities are sometimes tempted to build everything they need - not just the strategically important. This can waste expensive development capability, and intellectual capital, on building something that is readily (and often cheaply) available externally. Similarly, organizations with supply chains, especially embedded suppliers are sometimes tempted to out-source (or near-source) all of their Solutions to suppliers putting high risk requests that provide core business value in the hands of suppliers poorly equipped (in terms of knowledge, resources and contract models) to deliver them.

Several factors affect Build or Buy decisions:

Risk
Strategic Positioning
Cost/Benefit

Build or Buy: Risk Impact

The most important factor in deciding whether to build or buy a solution is the risk impact. If the solution is risky and the impact of those risks would damage the organization, then the solution should be built in house. Risks are never actually transferred; they are only shared at best.

A Risk is any potential threat to success.

Unexpected events happen frequently during knowledge work. Tracking ones we think might happen gives us an advantage because we can do things to try and avoid a risk, or roll out pre-prepared plans if they do happen. Risks may be technical, business, quality, related to resources or people, related to requirements, competitive, political and other aspects.

We do not recommend exhaustive risk categorization, instead we recommend tagging risks with categories. This allows an organization to look at risks from different angles without presupposing the nature of risks, possibly leading to missing some.

Risks should be tracked by every team and at the business leadership level. Risks should always have mitigation plans associated as otherwise there is no point in tracking them. Mitigation Plans provide a thought through response that teams can implement when a risk becomes an issue.

Not all risks will be identified before they happen, so organizations need to be able to deal with unplanned events rapidly.

Build or Buy: Strategic Positioning

Market analysis is useful in determining whether there is any competitive advantage in building a solution rather than buying it. As ideas move from being innovative market differentiators to specialist solutions the value proposition in building them rather than buying them diminishes. As solutions move from being specialist solutions to commodity or utility products the value proposition diminishes even further in terms of achieving Business Value.

Exceptions to this trend include service organizations who aim to disrupt a market by introducing a competitor to an established commodity or utility service, typically by exploiting a new idea that reduces delivery costs or enhances customer experiences.

Generally speaking, we recommend against building utility or commodity systems (unless that is the organizations core business) and instead recommend buying these systems from suppliers or using open source solutions.

Commercial Off The Shelf (COTS), increasingly including Open Source (OSS) products, are bought or acquired by organizations to deliver or enable Business Value instead of built directly by the organization.

Many organizations wish to use agile methods while implementing (COTS) products with varying degrees of product customization. Holistic Software Development provides a simple approach to dealing with the selection, deployment and adoption of COTS products. In simple terms the area under the H-Model is mostly unnecessary, other than for heavy customization and configuration, whereas the rest of the H-Model largely applies.

Build or Buy: Cost/Benefit

Sometimes due to specialist knowledge in the organization a Solution may cost less to develop internally than external estimates, or indeed the other way around where a supplier can offer a cheaper solution. Suppliers have a commercial interest in being able to offer solutions at a reasonable cost, and so may underestimate the solution and its risks. The Weighted Fixed Price contract model introduces feedback into this commercial situation to control it however we recommend the clients perform a risk assessment of every solution prior to placement with suppliers.

Return on Investment (ROI) is based on a simple formula:

Return on Investment = Business Value - Cost of Implementation

Where business value is qualified in terms of the POFL tests and cost of implementation is the cost of the product (and/or maintenance agreements) as well as the internal Delivery cost of deployment and support (as well as and configuration/customization costs). HSD helps organizations determine cost of implmentation by illuminating all of the work related to a Portfolio Request.

Where business value is not defined financially (e.g. in non-commercial organizations) we end up with a simple "Business Value vs. Cost of Implementation" equation which offers a simple decision to Business Leaders: Is the benefit worth the cost? We recommend that a wide stakeholder group is used to answer that question rather than just the Business Leaders so that decisions have wide support as they are made, rather than trying to gain support afterwards, especially when those decisions relate to tools, environments or COTS selection.

Open Source Alternatives

Additionally to Build or Buy options there may be an open source solution that is close to the required solution meaning that forking or collaborative contribution is a possible alternate option. Typically adoption of open source utility and most commodity solutions is preferable to purchasing a solution however the more to the right of the commoditization scale a product is the more we can expect change in both the product and its market environment. This kind of change will often lead to a difference of opinion between open source community members and contributing organizations as well as competitive pressures to not expose differentiating intellectual property.

Specialist and Innovative projects are likely to be internally built more than externally provisioned but they may still be based on, or extend, open source solutions.

Adoption of open source solutions isn’t getting something for free, organizations need to ensure there is an active ecosystem around the open source solutions they adopt and will need to invest in contributing back to that ecosystem.

Software as a Service

Another alternative is to make use of Software as a Service (SaaS) providers. Typically cloud based offerings allow organizations to out-source not just product development, but hosting, support, infrastructure, security and information risks.

SaaS is an excellent option for commodity and utility software as the amount of change is relatively low, user experience tends to be high (to attract customers) and predictability is high.

Build or Buy Decisions change over time

As external markets change and product availability changes an internal product that was once specialist and therefore made sense to build internally may become commoditized by progression in the industry. This means that Build or Buy decisions may need to be revisited over time to ensure that continued investment in a product is sensible for the organization.

Regardless of the source of an external alternative (open source, proprietary, SaaS) insist on the use of open APIs based on standard technologies so that external products can be integrated and developed against within your organization. The alternative is paying external suppliers for every small change and integration.

The Portfolio Selection process, which covers review of both New Investments and Business As Usual Portfolio Requests verifies the Build or Buy decisions intially, and they are reviewed as part of Continuous Investment Review.