PHANTOM RISKS: what to report in a risk register 2

phantomPhantom 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:

  1. It is a dangerous absorption  of executive time.
  2. It causes unnecessary management hysteria.
  3. Phantom risks fuel pet projects and hidden agendas.
  4. At best they increases drag on project, and
  5. 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 is to define the amount of liquidity needed to cover unexpected project risk.  This means:

  1. 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.
  2. 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.


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.

quopteMost 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.


  1. Firstly, to be a risk a thing must satisfy the following criteria:
    1. 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.
    2. 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.
  2. Secondly, in order for risks to be commercially relevant they must satisfy the following criteria:
    1. they must be HOT:  They need to part of an emerging or ongoing adverse variance in the costs.
    2. 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.
    3. 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.

Risk Management is a Team Sport Reply

Good financial risk management requires a high level team team effort and cross-functional collaboration.  Risks, by their very nature,  are highlighted precisely for the reason that the project team is unable to do anything about them.  If they could be effectively mitigated or avoided by a single function (e.g. Legal, Finance, Operations etc) then they would/should not have been placed on a Risk Register.

If the project were able to mitigate the risk themselves, alone, then it wouldn’t be a risk.

Dealing with these risks, therefore, requires not only close collaboration from multiple functions but it also requires the delegation and intervention from pay-bands which are at a higher level than the project, i.e. effective management of financial risk is expensive.  The corollary is that project teams should ensure that whatever risks they have identified are very important and cannot be dealt with by the project team.


Traditionally, risks that populate project risk registers will be well-known risks.  To be unkind, these will be statements of the blindingly obvious.  A menagerie of opinion, Google hits, speculation and wild guesses.   In the absence of an external assurance function, risk managers work for Bid Managers or project teams.  They are not incentivised to look too hard or too deeply at risk.  The last thing that either of these roles want is prying executive eyes or torches shined into dark and dusty corners of the business.

Most risk registers are populated with a menagerie of opinion, Google hits, speculation and wild guesses.

Future blogs will go into this area in greater depth.  However, in the absence of an external assurance function curious risk managers can assuage their intellectual integrity as well as supporting their boss by deriving their risks statistically.  By going back through 6-10 similar projects they can analyse, categorise and classify risks by a variety of quantitative and qualitative measures.  In this way, the Risk Manager will bring cross-functional experience to the project team and, hopefully, become a catalyst for inexpensive, collaborative risk management.