The Problem

Many modern engineering projects are comprised of a variety of sub-systems which all must function correctly to successfully meet requirements.  However, it is almost never the case that every single one of these sub-systems must be developed from scratch.  For instance, imagine an entrepreneur is developing a novel detachable antenna system for smartphones.  The smartphone is a critical sub-system for this project, but the entrepreneur shouldn’t try to develop his or her own smartphone from scratch - the effort to do so would almost certainly dwarf that of designing the antenna, and almost no benefit would accrue.   

Most successful products build their success around one or two novel or proprietary features.  The smart developer focuses his time and effort on these features and tries to minimize the amount of resources required to implement other supporting features.  The three main resources any project manager must manage are budget, risk, and schedule.  Herein lies the crux of this issue: given that nobody has unlimited time or money to bring something to market, how does one decide whether spending money to buy something at market price with almost no risk of failure is better than devoting time and money to building it oneself in the hopes of ultimate cost savings and taking on the risk that doing this is unsuccessful?

 The Tradeoffs

It all comes down to making the most optimal use of the three resources, and to do that we must answer several questions:

1. How much does buying the thing cost and what is the lead time?
2. How much budget and schedule will developing it in-house consume?
3. What are the schedule impacts to other tasks that flow through from developing the thing in-house?
4. How certain are we as to the schedule and cost requirements for in-house development?

Oftentimes, the price of buying something will feel higher than it should be, but we must remember that we are making a classic engineering trade-off: spend money to save schedule and eliminate risk.  The problem with developing a system that is already commercially available is that frequently the high price-tag for buying it is since the system is in fact very difficult to engineer and produce successfully.  

When we decide to build something ourselves, we are taking on a potentially large risk without fully understanding it.  There are some situations in which buying the parts and expending budget is the better move and vice versa.  Again, there are some questions that can shed light on what the best approach might be:

1. How difficult is the system to design, fab, and test?  Are there complex physics that must be understood?  What about difficult manufacturing challenges?
2. Does having an in-house design for the system create more value for the entrepreneur or investors?
3. Do existing products/designs serve the needs of the current project well?

 We need to answer the questions above very honestly.  If the system requirements are difficult to fulfill and there are existing products that can be purchased, it is nearly always better to pay for a finished product, as it has a well-known price tag and schedule impact.  Developing it ourselves could turn into a larger engineering project than the novel element of what we are trying to build.  However, there are circumstances when it is worthwhile to go down the rabbit hole and do it in-house.  For instance, if there simply is nothing available that works well for the project, one isn’t left with much choice.  

Another common situation arises when there is a commercially-available solution that is more expensive than the desired price point for a project moving into production.  In this case, the best decision may depend on where in the project life-cycle we are.  If we are looking for investors to help launch a product, it is likely better to just buy the expensive part and develop a credible plan to spend investors’ money on creating an in-house design that is cheaper once the project is closer to production.  However, if we are focused on cost-optimization for production, the decision is then whether the investment required to bring it in-house is justified by the reduced production costs.  

The Conclusion

In any case, it is very important to keep all elements of risk management in mind when deciding whether to build or buy something.  If that item is not central to the project’s success (IE it is an existing solution that meets requirements well) it is nearly always better to buy the existing product and eliminate all the known and more importantly unknown risk associated with that element.  That way the development effort can focus on the truly innovative and unique parts of the project, and avoid being bogged down needlessly.  

Interested in learning more about Boulder Engineering Studio? Let's chat!

Previous Blog Posts

Embedded TDD: Breaking the Hardware Dependency	The Non-Linear Nature of Engineering Development