Adaptive Project Management Strikes the Right Balance Between Structure and Flexibility
A version of this post originally appeared on Product Creation Studio’s web site.
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.
I think the most interesting example of a challenging project that used an adaptive approach was Lewis and Clark’s exploration of North America. They started out with a mission statement from their client, President Jefferson:
The object of your mission is to explore the Missouri River, & such principle stream of it, as, by its course and communication with the waters of the Pacific ocean, whether the Columbia, Oregon, Colorado or any other river may offer the most direct & practicable water communication across this continent for the purpose of commerce.
They had a literal map that got them started up the Missouri River and a figurative map that informed them of some of the risks and challenges they would face. They selected members for the Corp of Discovery with the skills they would need, like speaking the languages of the people they would meet, boat building, and hunting. They gathered supplies like guns, boats, food, scientific instruments, and gifts for the tribes along the way. Selecting and training the Corp of Discovery and preparing for the voyage took about a year. As they moved west, they drew the map that others would follow. Every encounter with a friendly tribe added to their knowledge and increased their chances of success. They added team members as they moved west, like Sacagawea and her husband, who joined the expedition six months after the journey began. If they had used a waterfall approach Lewis and Clark would still be in St. Louis building a Gantt chart. Using an agile approach would have been worse; they would have left without sufficient planning and preparation, most likely ending in the death of the team and the failure of their mission. Only an adaptive approach had a reasonable chance of success, and even then, success was far from assured.
Though adaptive project management is not optimal for all projects, it works better than waterfall when there are more than a handful of unknowns. It works better than agile when early mistakes can doom a project, or when the interactions between tasks are complex. Hardware product development almost always includes complexities that make agile and waterfall approaches unacceptable and an adaptive approach more likely to lead to success. But even the best possible project management approach will not make the impossible possible, it just reduces the cost of learning that lesson. You may come across a waterfall that you didn’t expect, but that doesn’t mean you have to go over it and drown.
Originally published at https://asilberlining.com on August 26, 2016.
