I’m writing like mad, trying to finish the program management book. I’m working on the “Integrating Hardware” chapter.
The problem is that hardware comes in several varieties:
- Mechanical engineering
- Silicon (part of electrical engineering)
- FPGA (which looks like software to me)
Each component (yes, I do call these components) has a different value at different times in the product development. The program needs all of them by the end. But how do you see the product evolve? Is it even possible?
Well, yes it is possible to see a product with hardware evolve. The problem is that hardware is expensive to transition to physical form. Every time you go to physical form, you incur NRE (Non-Recurring Engineering) Expenses. If you have to fabricate a chip or board, that’s expensive. In my experience, my organizations want to fab no more than three times(prototype, pilot, real product). And, all near the end of the program.
The first problem is ranking the features and organizing a product roadmap. In the book, I have a possible product, a robot arm. (None of my clients are developing robot arms, so I’m safe.) Here is the roadmap I created.
Notice that each monthly deliverable is a demo. For each of the first two months, the deliverable is component demos. The software team (OS) could show their completed software to date. The mechanical, silicon and FPGA teams would show their simulations. The simulations are separate for each component. For the third month, there is a potential joint simulation and a demo of the first prototypes.
The goal is to show every team’s work to every other team. For a complex product with hardware, the teams need to see what each other is doing, earlier rather than later.
You can try to do design by contract. It’s a great idea. My experience is it doesn’t matter what’s in the contract. The hardware is always a little different because the hardware people (mechanical and silicon) have to make tradeoffs be able to make the hardware fit the performance, footprint, or manufacturing capabilities. The earlier you can demo to each other on the program, the earlier you can see the changes.
This roadmap shows the teams what the program values first. It outlines the interdependencies. Yes, you need a product owner who either understands the interdependencies, or you need teams who can teach the product owner.
In my next post, I’ll talk about how to see the work each team does. The roadmap is insufficient for the details. The roadmap explains the big picture, and what you want to have happen. What the teams do is reality.
If you have an agile program with hardware, please comment on this post. I would love to know if this is helpful, what you do, and if you do something different what it is. Thanks.
