Simple Risk Analysis
Ron Friedman’s post today got me thinking about simple risk analysis.
The biggest advantage in risk analysis comes from the simple act of getting the risk down “on paper” so that others can see it… and see what you haven’t listed. In effect, you apply a bit of crowdsourcing to risk analysis. Perhaps the better metaphor comes from James Surowiecki’s The Wisdom of Crowds, where he details how bringing a variety of independent (and for technical or specialty tasks reasonably informed) viewpoints to bear on a problem usually yields a better result than having a single opinion, even if the opinion-maker is highly skilled.
In managing projects, I’ve always tried to make the risk worksheet public within the project team and encourage everyone to add to it, take issue with the current analyses, and so on. It’s rare that you’ll miss or even seriously mis-assess a non-black-swan risk by getting broad input. More importantly, it’s a task that team members seem to enjoy and that takes little time.
I’ve published risk worksheets before, and detail them in my book Legal Project Management. Here’s what you need in a core risk worksheet (modified from the book):
Risk Name: The risk itself is the starting point, the condition that could threaten the project if it comes to pass. There are six factors to track for each named risk, plus a time dimension (how risks change from week to week):
Consequence: What happens if the risk comes to pass? Is it a delay, additional cost, project failure, egg on your face, extra pressure? Stating the consequence in words helps the team focus.
Probability is the likelihood, as you understand it at present, that the condition (risk) will occur. This needn‘t be some exact number; “T-shirt sizing” precision is sufficient (small, medium, large, extra large). Express it as a percentage, and keep your eye on it until the probability goes to 0%, meaning the risk is gone, or 100%, indicating the condition has happened. Here is where the time dimension is most helpful. Is the probability increasing or decreasing? How worried should you be?
Expected Loss is the cost to the practice and/or the project if the condition occurs. If you express it as a monetary value, it will be easy to size risks against each other and determine your exposure, the probability times the expected loss. Sort the risks by exposure each week to get a sense of the project‘s biggest danger zones.
Mitigation Approach: What can the project team to do minimize either the likelihood of the risk, the expected loss, or both? There may be multiple mitigation opportunities. Some project managers keep a risk log to track mitigation steps taken and the changes wrought thereby.
Contingency Plan: Mitigations minimize risk before it occurs; contingency plans are kicked off when the condition comes to pass, in order to minimize the damage to the project. Some risks may not have (useful) contingency plans, such as a client shutting a project down.
Trigger: The team needs a clear signal that a risk condition has occurred, that it‘s time to put the contingency plan into action.
Here is a screenshot of the risk worksheet I use most often. (I don’t know why WordPress is stretching the image, but I’m scrambling on too much other stuff today to figure it out.)
Here’s a link to the real thing.
Comments are closed.