Phantom risks are, technically, unproven or unprovable facts which, if true, would pose as risks. At the macro level they are an issue for western societies as they generally arise from poorly made scientific inferences which are hijacked and used to legislate pet projects. Think of the religious right in the US trying to use scientific quackery to get creationism taught in schools. Dangerous stuff.
Equally so for the corporate world. Phantom risks are poorly made out inferences or assumptions, when misapplied, have teams chasing them for the life of the project. This is commercially dangerous for 5 key reasons:
- It is a dangerous absorption of executive time.
- It causes unnecessary management hysteria.
- Phantom risks fuel pet projects and hidden agendas.
- At best they increases drag on project, and
- At worst they dangerously misappropriates essential liquidity by artificially inflating the need for contingency.
More importantly, without an accurate, precise and robust quantitative methodology for identifying, defining and quantifying risk it is most likely that the corporate risk register will be full of phantom risks.
THE PURPOSE OF A RISK REGISTER
The purpose of a risk register is to define the amount of liquidity needed to cover unexpected project risk. This means:
- Risk register risks must be below 50%. If they are over 50% then they have a better than even chance of happening (i.e. they are expected) and therefore they should be managed in the baseline project cost model.
- Unexpected project risks – truly unexpected – should have liquidity assigned from outside the project budget.
The last point is a hugely contentious issue. Logically, a project should not be saddled with the financial burden of improbable risks not of their making, i.e. if a project did not bake in its own risks by its own poor design and management then it should not have to pay for them when they occur. The necessary contingency funds should come from Treasury. This means that project teams are encouraged to sail as close to the wind as possible and are not penalised for doing so.
In most cases, however, savvy project teams will artificially inflate risks in order to create the greatest possible contingency. These funds, held outside the project budget, then act as a black-budget slush fund for the project. The nett result is a project which is more likely to hit its margin targets but an unhealthy corporate balance sheet.
WHEN IS A RISK NOT A RISK?
A risk is not a risk when it is an issue. Much of the difficulty in generating real risks is that most risk register risks contain elements of risk. They allude to risk and there is usually a gold nugget in there somewhere. However, until there is a quantifiable financial impact they cannot be used to determine liquidity requirements and they should not be included on a risk register. They may be pressing issues for the business but they are not risks. The difference is key: Risks require liquidity. Issues require analysis.
Most risk registers contain risks which have no business relevance. These things are, technically, risks but they are usually so remote or unprovable that they (i) are hard to argue with, and (ii) obfuscate the real risks often hidden within their confused semantics. Most of these things are pressing business issues but issues require further analysis and planning. They do not belong in a risk register.
HOW TO DEFINE A RISK
- Firstly, to be a risk a thing must satisfy the following criteria:
- it must be derived from a structural weakness, i.e. a design flaw in the program plan, the technical architecture, a contract clause, a cost model imperfection.
- there must be a threat/disposition. For instance, a chair with the broken leg might highlight a structural weakness but it does not represent a real risk until someone becomes disposed to sitting on it.
- Secondly, in order for risks to be commercially relevant they must satisfy the following criteria:
- they must be HOT: They need to part of an emerging or ongoing adverse variance in the costs.
- they must be VALUABLE: these variances must show high volatility in the cost model, i.e. if the risk is realised there will be worrying financial implications.
- they must be WEAK: they need to be part of something (or dependent upon) that the business often gets wrong. This is critical because adverse variances and financial volatility might merely represent the natural trajectory of a cost variance in a project. There is often little cause for concern. Unless, however, these variances are part of a statistical problem within the company’s projects.
If all the criteria above are satisfied and a relatively accurate number can be used to quantify the financial impact of the risk, then it is a real risk. If it has high probability and was found during the estimating process then it probably needs to be managed as part of the Baseline and not the risk register. If, however, it’s a low probability risk and not something the project team should be held responsible for then it likely belongs on a risk register (the funds for which should come from Treasury).
When done right this method usually reduces risks by 80%. What is left are real risks which point to real liquidity requirements and the need for real action plans in order to minimise real legal exposure. A risk register of such quality is useful and practical not only to Operations but also to Legal and Finance as well. Most importantly, no one is chasing phantom risks.