Home > On-Demand Archives > Talks >
Build Versus Buy
Kim Fowler - Watch Now - EOC 2023 - Duration: 20:48
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
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.
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:
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.