Home > On-Demand Archives > Talks >

Build Versus Buy

Kim Fowler - Watch Now - EOC 2023 - Duration: 20:48

Build Versus Buy
Kim Fowler

When developing embedded systems, the decision to build or to buy a subsystem is difficult. Most of the issues are not of a technical nature but of human failings. Commitment to one another and to the project, along with a negotiated plan is the only feasible antidote to biases and irrational thought-processes that lead to failure to meet schedule, budget, and requirements.

Topics covered in this talk will include:

  • Identify some problems in developing embedded systems
  • Understand some cognitive biases
  • Consider modeling and simulation of the development process
  • Compare parameters that tend to be important in projects
  • Suggest some ways to improve the decision process
italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 1 | 1 year ago | no reply

Wow, great questions and ones that must be asked. I am only able to give the most basic of answers, because this decision is has no "silver bullet" answer.

It all depends on business context, company vision/mission (explicit or implied), the company culture, and your personal relationships. Let me try to provide some partial answers to your questions, one at a time:

  1. Stakeholders and departments - this is most important and a first step in building credibility with both your company design team and management. Number one is to identify the decisions makers - learn their "hot button" issues and address their concerns thoughtfully. Spend time developing the various considerations your company deems important; bring in other issues that you see as very important but overlooked (I suggest expertise, training, and tools - side note: companies can be short-sighted in this respect when they will not spend $5000 on a labor-saving tool or instrument but will spend $50,000 in your team's time and labor to grind through a problem; this tends to occur repeatedly. Try to break this cycle with logical and reasonable arguments. I use arguments in the truest sense - reasoned and rational discussions that consider all sides of an issue; not hot-headed yelling matches.)
  2. Some stakeholders that you should consider:
    a. Who makes the final decision?
    b. Who has significant input to the final decision?
    c. What does the client or customer(s) really want? Get their input, if possible.
    d. Your team members.
    e. Other teams that have subsystems or interactions with your subsystem or product.
    f. Manufacturing
    g. Technical support and maintenance – these folks often know the real performance and issues within a product cycle.
    h. Sales – yes, those folks; they need good, basic technical information to sell your product to the right people; ultimately, a salesperson is a problem solver for the customer – solve customers’ problems and they will buy your product and become repeat customers.
  3. Iterative process – almost everything in engineering is iterative, making the build-versus-buy decision is no different. Careful preparation of your considerations will reduce the iterations to an optimum number to reach a satisfactory solution. Make sure to identify and involve your stakeholders. Do the extra work upfront to justify your position. Build credibility with a track record that shows you have estimated well (at least better than a wild guess by your design team or by management).
  4. Inertia and timeliness – yes, that is a good question and depends on company culture. As mentioned in #3, do the extra work upfront. Keep a record of your history and show that you are good at estimating or at least are improving. Most situations are much better executed if time is spent planning and estimating because you identify pitfalls and issues early before mistakes are encased in the design and a long, painful revision must occur. A NASA study from 2003 showed that the most expensive mistakes are made very, very early in the design and development process. An incorrect decision or design mistake made in the conceptual design can end up costing a company 150 to 3000 times (yes! 150 x to 3000 x) the amount to fix the mistake in the beginning. This supports the need to plan carefully early in the development cycle.
  5. I would be happy to send you my two papers that support my talk and some of these thoughts here. My email is kfowler@campbell.edu .
Score: 0 | 1 year ago | no reply

Hi Kim,
Very interesting presentation, it seems to me that the industry could do with more rational thinking in the area. I have personally have yet to be engaged with clients that perform such thorough analysis, possibly they do but perhaps to a lesser extent as derived decisions would have "make or break" consequences; I have certainly not been involved in that process or been made aware of the decisions made. Based on your broad experience, who tend to be the stakeholders or departments involved in generating these type of cross over assessments? How much of an iterative process is it? As I said it feels these sort of decisions could have big inertia, so unsure how long it would take for one to take feedback without being too late.