What happens when uncertainty and risk are poorly handled during a project? Almost always, it results in missed deadlines, wasted time, and unhappy stakeholders.
I once took over a project that did not have requirements documents. The developers were writing code without a solid vision of what it should do. When they shared their results, the stakeholders would complain and send them back to rework the code, which wasted everyone’s time. Later, we discovered the hardware would not work, requiring them to start over with a new architecture. That wasted even more time, and the project took twice as long to complete.
That’s what happens when uncertainty and risk are poorly handled.
For projects like hardware product development, where there is a lot of uncertainty and complexity, it’s critical to understand which tasks are most important. Otherwise, your team will find much of their effort is wasted. Successfully managing these projects requires a delicate balancing act between removing uncertainty, reducing risk, and progressing along your critical path. I call this approach “adaptive project management”, which takes elements from both waterfall/standard project management (which handles complexity well and uncertainty poorly) and agile project management (which handles uncertainty well, but complexity poorly).
Early in an adaptive project, your focus must be on removing uncertainty. How can you write code if you don’t understand the needs of your end-users or build prototypes if you don’t know what technology best meets your needs? At this point your focus will be engaging with stakeholder or end-users, exploring the capabilities of technologies you’re considering, and understanding resource and budget constraints.
This effort will continue throughout the project, but can drop off once you understand the project well enough to build a work breakdown structure (WBS). The WBS will include tasks to remove the remaining uncertainty. The nature of adaptive projects is that you march on with some uncertainties rather than drive them all to zero in the beginning, as you would in a waterfall project. As your uncertainties drop, your plan should start looking more waterfall.
Risks are set in the future; issues are happening now. The problem with risks is that they can develop into issues. Solving issues takes time, which can lead to delays and increased costs. The sooner you can turn risks into issues or make them go away, the better.
Once you have a reasonable understanding of your project, you need to build a risk register. Make a list of what might go wrong, how likely it is (probability), how bad it will be if it happens (severity), and what you can do if the risk occurs (mitigation). I prefer a ranking from 1 to 5. For probability, 1 corresponds to a likelihood of < 20 percent, while a 5 corresponds to a likelihood of greater than 80 percent. For severity, 1 corresponds to a small impact on the project that is unlikely to put any milestones dates or budget constraints at risk. A 5 means that the entire project might need to be canceled, possibly because a critical feature is not possible or our cost-of-goods sold will be significantly higher than expected.
I also include a column for importance, which is the product of probability and severity, and rank the risks in order of importance (see Table 1). Some of your effort should always be spent on reducing the most important risks, either by testing to see if they’re real issues or building the mitigation. This effort should be part of your work breakdown structure. I also build the mitigations of high-probability risks into the plan, with the goal of reducing surprises down the road.
|Unit fails electro-compatibility testing||4||3||12||Build Faraday cage around electronics|
|Passive cooling isn’t sufficient||3||2||6||Add a fan|
Table 1: This is a simple risk register. More complex versions include things like discoverability (how likely it is the risk will happen, but you won’t be able to detect the failure) and contingency (what you will do if the mitigation doesn’t solve the problem). I find a simple risk register sufficient and easier to keep current, which is more important.
Progressing Along the Critical Path
Once you have organized your tasks and time estimates into a work breakdown structure, you can use project management software like LiquidPlanner to build your schedule and a Gantt chart. You can then select a milestone and filter to those tasks that are on the critical path (i.e. tasks that will cause delays if they slip by a day). While all tasks need to be completed, those not on the critical path can slip without impacting deliverables.
Use your tool to determine if deliverables will be completed in time to meet stakeholders’ needs. If not, work with your stakeholders to understand how important this deliverable is and whether it can be descoped. Another possibility is to transfer resources from risk reduction to critical path tasks. If you go this route, explain to your stakeholder that this increases the chance of an issue appearing late in the project, when it’s harder to fix.
A Good PM is a Tightrope Walker
The job of the PM is to balance these three areas. Overtime the critical path will become more important and reducing risk and uncertainty less so. But there’s no formula to answer what you should do. A tool like LiquidPlanner is like the pole that helps the walker maintain his balance.
In the end, it’s up to you and your team to understand if: you’ve reduced uncertainty enough that you can start to focus on risks; that you’ve reduced risks enough that you can focus on your critical path; and that everyone is working on the most important task at that moment. When you get it wrong (e.g. a low probability risk turns into an ugly issue late in the project), just smile and focus the team on what are now the most important tasks.
Looking for more tips to help you save time, increase productivity and motivate your team? Check out our guide, “5 Practical Habits for Today’s Project Manager.”