Do you know where your risks are?
Five principles for training your project management spidey sense.
Project management can be called an exercise in applied risk management. As a PM, almost everything you do is aimed at seeing trouble down the road and doing something about it before it gets out of control. With experience, you get a sixth sense about things. Michael Lopp calls it the spidey-sense — it’s that little voice at the back of your mind that says “oh no”, generally without conscious thought and sometimes without an obvious reason. It’s what people mean when they say to pay attention to your gut. It’s the voice of experience, speaking quietly, making you uncomfortable, because millions of years of evolution have given you excellent pattern recognition skills and there is something about this situation that is tweaking them. The usual way to acquire it is to be exposed to those kinds of situations, over and over again, and to pay attention. This is why experience is valuable.
But that’s not great news for a project manager with a new project.
And that’s why, as a PM, you should be doing formal risk management. The point of risk management is to force you to chase down and harness the spidey-sense, and ideally the spidey-senses of multiple experienced people. If you do it right, it will help train your spider, feeding it lessons learned from dozens of other similar projects or scenarios. It will also help you manage your project right now, so you don’t have to learn through painful experience.
Less pain, more gain, sounds great. But maybe you’re doing risk already and you don’t think it’s working that well, or you view it as an exercise in tedium and spreadsheets. There are lots of ways for risk management to be poorly executed. To avoid them, our five guiding principles for high-value risk management are:
- involve as many experienced people as you can
- identify the characteristics of your project that drive risk and focus attention there
- right-size your risk practices to your project
- think clearly about the future and capture your risks accordingly
- then use risk to focus on management of your most important areas.
No Risk Solos
Risk involves imagining the future through the lens of the past. What could happen? Why? What would that result in? What should we do about it? How likely is it? It’s not something that should be done solo, ever (a topic for another day); for one thing, you’re trying to make use of as much past experience as possible. For another, everyone has different levels of risk tolerance, and individual people are notoriously bad at both probability and estimating, so you want the wisdom of the crowd. Get multiple people together. Start with the project team, then strive for as many other crusty, rain-on-your-parade old experts and veteran PMs as possible. The minimum is two or three. Ten is even better. Sixty is not too many if the project is large enough.
Find the Hot Spots
Projects are viewed as high risk for all kinds of reasons. Sometimes it’s ridiculous expectations for schedule or budget; sometimes it’s touchy stakeholders, or it’s brand new technology, or the project is very large for your organization and any problems could sink you. Risk tolerance is also a subject for another day. The important takeaway is to understand what is really driving risk levels on your project: the location and environment, the project scope itself, the various participants including stakeholders and the organizational context, or the overall process for the project.
On small projects, this is a mental list; on large projects, it can be a full fledged database. This is your first spidey-sense exercise: what about this project makes you uncomfortable? You don’t have to think about why right now, just list some things and maybe put some stickies on the design.
Don’t Kill a Fly with a Rocket Launcher
If you’ve gotten a good grasp on where your risk is, you should also be starting to get a feel for how much risk you have. The reason that you should think about drivers first is that it’s not just project size; some projects are higher in cost but they’re repetitive or the cost is mostly materials, and the risk is not very high. Some projects could be a tenth the cost, but with huge public failure potential.
The curse of many larger organizations is a risk process that is one-size-fits-none, too intensive for low-risk projects and not close to enough for high-risk projects; the curse of smaller organizations is that there is no risk process. As a PM, your risk process — how much detail is in the register, what kinds of tools are you using for identifying your top risks, how often is it updated, how often are you checking on mitigations, what does your reporting look like — should reflect what is needed, and it should focus energy and attention on the most important parts. If a given component of the process isn’t adding much value, cut it out, or scale it back to the bare minimum.
Write Risks for your Future Self
One of the most challenging parts of risk analysis is capturing the full risk, clearly and accurately, in such a way that you can quantify it well and so that everyone on the team can understand what it means. A good risk definition will capture what might happen — the uncertain event — and a detailed description of the impact if it does occur, measured against a baseline expectation. “Material supply” is not a helpful risk definition. “If critical material delivery is more than 1 month later than expected, then the project may be delayed by 1 month or more, resulting in damage to our reputation with key stakeholders, additional costs, and loss of potential revenue” is a risk you can sink your teeth into.
Defining risks well helps you understand what’s really important. Sometimes a driver everyone is initially worried about doesn’t translate into a significant risk, once you step through the real potential outcomes. Good definitions also help you understand if there are multiple real scenarios hiding in a risk; for example, in the material delay risk above, what happens if the shipment is completely lost? The delay would be far more than 1–2 months but the corresponding likelihood would be much lower as well, so that might need to be a different risk.
Risks are for Managing
The purpose of the entire exercise is to develop and direct your spidey-sense, so that you can make decisions and take actions that will help reduce those risks. The only reason to do risk analysis is to help you focus on what to do. With that in mind, endlessly re-quantifying is not really that helpful; you should plan on quantifying at key milestones or if something dramatic happens, but other than that it’s much more important to spend time updating what’s happening with your key risks and thinking about how to handle them better.
Takeaways
If you’re managing projects, or anything really, the best favor you can do for yourself is to take risk seriously, put resources into it, and do it well. Get the right people involved, get to know the kinds of places where risks are lurking, plan for a process that makes sense and adds value, get good at defining and describing your risks, and then spend the rest of your time on risk mitigation. Train your spidey-sense and it will repay you with the ability to spot future disasters when they are very small and can be squashed like… well, flies.
Sorry for all the spider imagery, folks.
