Reliable Systems

A popular technique in project management is to create and maintain a risks list. This list is supposed to track the things that could cause the project to fail to meet its objectives and ensure that each one gets a mitigation strategy. You generally prioritize the risks by looking at the product of impact and probability: How bad would it be if the risk came to pass, and how likely is that to happen.

Risk mitigation is generally done in three flavors:

1. Make adjustments now to mitigate the risk preemptively.
2. Have a plan ready to go in case the risk materializes.
3. Do nothing and wait and see.

Most project managers (particularly the Project Monitor variety) are highly reluctant to take the last approach: Do nothing, wait and see. They want to have a mitigation strategy for every risk, preferably one that involves taking action now so that the risk is fully mitigated and can be removed from the list. This is counter productive to the project because:

• In the short term it will have the team spend energy and time on mitigating risks of ever decreasing probability, on tasks that are pure overhead in the project.
• In the long term it teaches team members to not mention risks because any risk mentioned will have to be mitigated. This is a strong disincentive to open risk discussion, much like obsessing about defects can cause people to not log defects.

If you want to get value out of a risks list, it has to be treated like a “hold harmless” list: The team has to believe that management won’t hold any risks against them, that they won’t have to mitigate any particular risk on the list, and that intelligent decisions will be made on what risks need to be drilled into. One way to help this is for the project manager to have a strong preference to have each risk either be categorized as Do Nothing or at most mitigate when it happens. Have the team accountable for pushing risks to a higher status by their own consensus. This can remove the fear on the part of team members that identifying a risk and speaking it aloud will cause extra work for the team to debate it and have to mitigate it. Instead, focus your team’s risk list as an opportunity for each participant to identify risks and then suggest mitigation for a risk if they so choose.

Can Your Project Create a Black Hole?

There will be some risks that have a reasonable probability and a serious impact that may require more serious intervention, however there is another item that comes into play at this point. Many high impact risks also should have no reasonable mitigation strategy. If the impact is that the project is sure to fail or even the company is sure to fail, unless you believe you can mitigate it with a modest amount of work, you should probably just let it go. This may seem crazy up front – these are your most serious risks yet I’m suggesting that you treat them as less important than others farther down the list. Quoting World Radio Switzerland (and also from The New York Times):

A lawsuit has been filed against Geneva’s CERN research facility over claims its experiments could destroy the planet. Two scientists in Hawaii say the European Organization for Nuclear Research might create black holes that could swallow the earth. The Large Hadron Collider is the world’s biggest particle accelerator and will essentially crash beams of protons together to create what the universe was like right after the Big Bang. It will do so in a massive underground ring stretching underneath the Swiss and French border and the scientists claim CERN has not fully tested the LHC.

From a project management standpoint, this is essentially the definition of a risk with infinite impact: What could be greater than unstoppable destruction of the Earth? This is a Terminal Risk.The practical reality is that if the result of a risk is that your project will fail, and it can’t be mitigated in a way that still has your project succeed, then you have already failed – if it happens, there’s no solution.

In business, these risks happen all of the time: There is a finite risk that the government will change laws that will ruin the economics of what you do. A competitor could come out with a game changing product that makes you effectively the last buggy whip manufacturer. These are all terminal risks: If they happen, you’re dead. Therefore, spend no time on them at all. Any amount of time you worry about them will not help your project succeed and will only demoralize the team. Additionally, once your team gets focused on a terminal risk, they will start identifying other similar terminal risks, and there’s no running out of them. It is a spiral that doesn’t produce any gain to your project or team.

Instead, focus your energy on the middle set: risks that are reasonable to mitigate, have a fair shot at coming to pass, and would have a real impact to the project. Those are the ones that you’ll have difficulty explaining why you didn’t do anything about them in a post-project review, and your team will likely feel better about the project and the process in response.