Adaptive Project Management for Hardware Product Development
This blog post is for you if you have ever worked on a project …
Where a request or some information was presented late, creating a lot of extra work.
That failed for reasons that should have been obvious sooner.
Where the product development team and client weren’t on the same page.
These scenarios are all examples of a breakdown in project management.
In this article, we talk about the different project management paradigms and takeaways from each that can help reduce the probability of these things happening.
Project Management Paradigms
Any project can be broken down into one of four groups based on how complex they are and how many unknowns there are going into it.
For example, cooking dinner. Complexity is low and there relatively no unknowns. You can find a recipe, pull the ingredients together and make the dish. You’ll be successful enough. For this, there is minimal (or no) planning required.
However, once you start adding complexity and unknowns to the project, you will need a paradigm that properly fits the project at hand.
Waterfall Project Management
The most popular project management paradigm is waterfall.
What is waterfall project management?
The project flows from requirements to implementation to testing (like water flowing off the edge).
Alternatively, once a plan is completed, work flows through the plan.
The plan is very detailed. Complete plan is broken into tasks and each task is assigned. This paradigm tolerates very little unknowns.
These tasks determine the critical path. If any of those tasks slip by a day, your delivery date slips by a day.
For example, the prototypical waterfall project is building a skyscraper.
This is a project that includes thousands of people that work for dozens of different companies, located in 20 different cities or counties.
You have very complex interactions that have to be done in a certain order, e.g., an inspection has to be done after the infrastructure is built but before it’s covered up.
Material has to arrive on site, on time. If it’s too late, it delays production. If it’s too early, you have to deal with finding a place to put it.
Building a skyscraper is a very complex project, but the unknowns are fairly small (the one uncertainty here is the weather).
What is required for waterfall to work well?
Practitioners are very experienced in the tools and processes they are using.
Everyone knows what they’re doing so there is very little uncertainty.
Why waterfall works poorly for hardware product development:
New tools and processes are constantly becoming available so everyone will always be learning.
New product development is inherently uncertain.
Uncertainty is typically large because innovative products mean no one has done it before, not just you.
Useful lessons from waterfall:
As best as you can track your critical path and long lead time items because sometimes there will be a part you need that is going to take 14 weeks to be delivered.
Track your dependencies because they can be a very complex in hardware development.
Understand what tasks are needed (do the work breakdown structure) to meet your requirements. Even if it’s going to be incomplete, you need to do it as best you can.
Agile Project Management
The next popular project management paradigm is agile. This project management philosophy was developed specifically for software projects.
What is agile project management?
You develop stories (light weight requirements) for each work phase.
Typically built into two week sprints where, at the end of the sprint, you have something you can take to the stakeholder for feedback and incorporate that feedback into the stories. It’s basically building a prototype every sprint.
Priorities are set at the beginning of each sprint.
You deliver a product to the client for feedback prior to starting the next sprint.
Input from the client sets the priorities for the next sprint.
Focus is on automated testing to ensure that the product does what you said it was going to do.
What is required for agile to work well?
Projects where the cost to complete a “build” is small e.g., a new button on an app.
Projects where the cost of making a mistake is small e.g., code doesn’t work, maybe you’ve lost a day.
Why agile works poorly for hardware product development:
No way to deal with complex product dependencies.
No way to determine a critical path.
No way to deal with long lead time items.
The cost in time and money of making a “build” may be large (prototypes can be an expensive effort).
The cost of making a mistake may be large e.g., architecture of a product isn’t tested and it turns out it doesn’t work with the product. You find this out a year later. We were going down a path that did not lead to success but we didn’t realize it.
Useful lessons from agile for hardware product development:
Customer collaboration is valued over contract negotiation.
Responding to change (value-added learnings) rather than following an outdated plan or contract.
Show preliminary work to client/stakeholders as early and as often as possible so you know you’re on the same page and can get feedback.
Test often and well (make it straight forward and automated).
Adaptive Project Management
Adaptive Project Management is the paradigm we follow here at Product Creation Studio, and what makes the most sense for hardware product development.
When describing what it was like to write a novel, writer E.L. Doctorow said, “…like driving a car at night: you never see further than your headlights, but you can make the whole trip that way.”
Hardware product development is very much the same. We don’t have complete knowledge of the project, we don’t have a detailed map (like with waterfall), but you know where you want to go and need to focus on what’s right in front of you in order to move forward.
What is Adaptive Project Management?
The most important focus is on reducing risk early (whatever point you’re working on, reduce risk at that point). Examples of reducing risk: build a prototype, create a mitigation plan (when you can’t test), etc.
Includes sufficient planning so that you know the team is always working on the correct tasks, but no more planning than that (like waterfall-style planning but without the same amount of precision).
Focus on the critical path and long lead time items (but not at the expense of risk reduction). An example includes ordering the part you know is going to take 14 weeks to get here is accounted for in the critical path.
To build you Adaptive Project Management plan, you need to:
Understand your greatest risks and how to reduce them (this is the most major point of the adaptive paradigm).
Set your milestones and build a plan to achieve them. Examples of milestones can include investor meeting, conference, board meeting, etc.
Get it in the ballpark; focus on accuracy rather than precision e.g., that should take about two days vs. figuring out exact number of hours. You can’t focus on precision because you’re constantly rebuilding your plan due to the amount of uncertainty. Some days you’ll overshoot, others you’ll undershoot but it should average out.
As your understanding increases, so should the detail in your plan.
At Product Creation Studio, we use LiquidPlanner and it is well suited for the Adaptive Project Management philosophy because it allows the entire team to contribute and update the plan.
Communication rules in the Adaptive Project Management paradigm:
Communicate status to the stakeholders regularly and clearly so they know things are changing.
Make sure that team members have the information they need to do their jobs.
Agile Scrum daily standup meetings are useful.
Example of an Adaptive Project – Lewis and Clark’s Corp of Discovery
“The object of your mission is to explore the Missouri River and 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 and practicable water communication across this continent for the purpose of commerce.” – Mission Statement from their president, President Thomas Jefferson
Before Lewis and Clark took off on their trip, they:
Spent a year studying previous expeditions, training and gathering supplies.
Created a plan for the early days of the expedition. Their plans extended as far up the Missouri river as possible, but they didn’t have maps that would allow them to build a detailed plan all the way to the mouth of the Columbia River (just as far as their headlights would reach).
There was an approach they would take and plan for, but it didn’t have a lot of detail to it e.g., make friends with the natives with peace medals, hunt for food so they carried guns, they learned the skills they needed to make boats or houses during the winter, etc.
They had a clear goal: find a water route to the Pacific and establish sovereignty in the newly acquired land.
If they had taken an agile approach, they wouldn’t have spent a year studying and preparing. They would have just taken off on their mission and would have probably died.
If they had taken a waterfall approach, they never would have left St. Louis because they weren’t able to build a detailed plan with the information they had at that time.
The trip was too complex to be agile, and too uncertain to be waterfall. They took an adaptive approach and they were successful in their project.
The Best Project Management Paradigm for Hardware Product Development
How many of you have worked on a project:
Where something came up late and created a lot of extra work?
That means there wasn’t sufficient planning done to know or understand the task order. Waterfall approach can help with that.
That failed for reasons that should have been obvious sooner?
That means risk reduction was not prioritized and checked at every project point. This is where adaptive project management can help.
The team and the client weren’t on the same page?
That’s because communication lines between vendor and client weren’t open or information wasn’t shared often enough in the process. This is where the agile approach can come in handy.