A version of this post originally appeared on Product Creation Studio’s web site in January 2016.

This post is the last in a series of three that explores the shortcomings of common project management approaches for hardware product development and proposes an alternative.

In my first blog post, I wrote about waterfall project management. The structure of this approach allows one to effectively manage complex projects, but deals very poorly with unknowns.

In my second post, I looked into agile project management, which is a method predominantly used in software development. This minimally structured approach works well on these projects because the cost of making a mistake is low and the tasks have simple interactions. However, it works poorly on projects with long lead-times and complex interaction between elements.

In both posts I discussed how these approaches worked well for the types of projects they were designed for, but poorly for the types of projects we do here at Product Creation Studio: designing new hardware products. Most importantly, while a strict adherence to these paradigms will lead to agony and pain when designing hardware, there is still much of value in both approaches. Waterfall and agile can be combined into an effective project management paradigm for hardware development.

This combined approach is called adaptive project management, which is similar to what the Project Management Institute calls Rolling Wave planning. This approach manages risks and tracks the critical path while recognizing that our knowledge is inherently incomplete and re-planning will be necessary. Using an adaptive approach, the project manager does just enough waterfall-style planning to be confident that the team is working on the right tasks. These tasks are chosen to minimize project risk as early as possible, while making sure that long lead-time tasks are completed when they need to be. As the project moves forward, the plan is reworked and expanded to leverage the most recent understanding of the project.

Writer E. L. Doctorow described writing, “like driving a car at night: You never see further than your headlights, but you can make the whole trip that way.” This metaphor is just as apt for product development. A good map is helpful, but it doesn’t absolve the driver from paying attention. The map won’t mention the cow in the road, the traffic jam, or the bypass route that was built since it was drawn. Your map will be imperfect, but if you keep moving towards your destination, you might get there. Or you might discover the road is impassible.

The product development process is a march from high uncertainty and risk towards a de-risked, highly specified product that’s capable of being manufactured and sold. Early development phases will focus on understanding the customer needs, the competitive landscape of the market, and the technological opportunities. Middle phases will focus on proof-of-concept experiments and narrowing your possible concepts to those that best solve the problem at hand. Late phases will focus on designing, building, and testing commercial devices. The final phase will be transferring a manufacturable design to production.

Development phases typically include work across all disciplines, including design, hardware, software, testing, and documentation. Each phase begins with a detailed waterfall-style plan to complete that phase. Throughout the phase, the plan is refined and extended into the next phase. Planning and work on long lead-time deliverables for one phase may begin during earlier phases. For example, the mass production partner may be selected early in the process, though they aren’t critical until later. By selecting them early, their input into the manufacturing design can produce a product that is easier and less expensive to build. While planning, the team constantly asks, “What are the biggest risks and uncertainties to this project and how can we reduce them?”

The tools for adaptive project management are similar to those for waterfall. Project managers create a list of tasks that need to be completed, called the work breakdown structure (WBS), but only build a detailed schedule for the tasks that are in the near future, have long lead-times, or have high risks. The WBS is reviewed often and tasks are added as they are discovered. Like an agile approach, the planning is constantly focused on adding value. The difference is that there’s an acknowledgement that some tasks simply take a long time or have complex dependencies. One must do enough planning to understand what those tasks are and when they need to begin.

I was part of a team that used this process to develop a consumer electronics product. Reliability was a high concern, so for each prototype iteration we built enough samples to demonstrate not only that the product would work under normal conditions, but that it would continue to work after being heated, cooled, pulled, twisted, soaked in water, and coated in sweat. We were constantly updating our design based on the results of the testing, but to meet our schedule we started building the next round of prototypes before the testing on the previous variant was complete. To stay on schedule we needed a detailed waterfall schedule for each build, but what was in the build was unknown until the last minute, when the design was released. At any given moment, the design and the plan were based on the best available information. The program met our schedule, was reliable, and of high quality: it was a design that the team was proud of.