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.
Read more: Risk Driven Lifecycle
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.
Read more: COTS Implementation
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.
Read more: Return on Investment
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
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.