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.

Measuring Legal Exposure Reply

Mind the gapThe function of a contract is to cover legal exposure.  It does not, by and large, govern the relations between parties.  Those are already established by the community and contracts merely document well established facts.  The way the parties will behave will already be a an established reflection of their education, training and previous business experience.  It is naïve to think, for instance, that a contract will be used by engineers to help manage the construction of a building.  On the contrary, the contract will present a myriad of hurdles, obstacles, impasse and problems as the workers try to get on and do their job – build.  It is a truism to say then that almost all litigation is a function of poor contract management rather than poor contract design.  Indeed, I have never met a client who had either fully read OR fully understood the contracts they were in.

A contract, rather, seeks to cover the inevitable areas of risk when two parties necessarily compromise to enter into an agreement. as my father used to say, ‘there are two parties to a contract – the screwor and the screwee.  One party is always disadvantaged.  The lesser party needs to cover their legal exposure and the greater party needs to ensure that not so much risk flows down that the lesser party is overloaded with risk, making the contract unworkable. Picture1Legal exposure is derived from financial risk.  Contracts will generally cover most financial exposure.  However, in Westminster-based systems much of the law of contract is still based in Equity.  Usually, there is still some degree of exposure that remains.  A party can only be forced to  indemnify so much; can only warrant so much and not beyond the reality of the exposure

Most contracts, however, do not measure the legal exposure a party faces.  Most contracts stick with the standard blanket coverage formula, i.e. zero exposure.  This approach is unhelpful and in many cases counter-productive, because namely:

  • Phantom Exposure.  contract negotiations become unnecessarily bogged down over non-existent risk.  Arguing for 100% coverage when the risk is well covered already is just chasing phantom risk.
  • Lazy.  Quite frankly, the body of knowledge which exists in each sector, the sophistication of clients and the modern quantitative tools which exist to make contracting easier give no excuse for legal laziness.

Measuring legal exposure is both qualitative and quantitative.  Firstly, deriving financial risk is a mathematical function.  Secondly, as exposure is derived from the limitations of contractual coverage then legal exposure is a function of qualitative assessments.

My own method uses a threefold approach, namely:

  1. sensitivity analysis to measure financial risk, and then
  2. three separate qualitative measurements to define whether an element is a legal risk, then
  3. a legal assessment to determine if the remaining elements are covered (i.e. measure the exposure) and to what degree.

All of this is done as a collaborative process around a single bubble chart (shown below).  As is shown in the chart,

  • the bubble size (Z ‘axis’) relates directly to the mathematical analysis of financial sensitivity.
  • the X-axis is a qualitative scoring designed to assess the relative complexity of each item of volatility.
  • the Y-Axis is another qualitative scoring to determine just how close the item is to the project team, i.e. can they actually do something about it?  The less a team can influence a risk the more such risk needs to be pushed upwards so that the corporate functions of a business (Legal, Finance) can act upon it with centralised authority,
  • the colouring, lastly, deals with the notion of immediacy, i.e. prioritisation.

In this way, if a risk is both very complex and not able to be influenced by the project team (i.e. cannot be mitigated) then it, most likely, needs to be dealt with by the Legal function as there will be no way to otherwise influence it when the risk is realised.

Risk-Based Bubble Chart to engender cross-functional collaboration

Once legal risk is conceptually isolated in the upper-right quadrant of the bubble chart then lawyers may make a qualitative determination as to the amount of legal exposure.  For instance, a builder may warrant the quality of workmanship on a specific structure and cover it with insurance.  Legal may determine that there is virtually no statistical evidence that such risk is likely to be realised.  Therefore, the existing premiums easily cover the risk highlighted in the chart.

Alternately, the chart may have defined financial risk beyond, say, the indemnities provided by a firm’s subcontractors.  In such a case insurance or contractual renegotiation may be necessary.  It is important to know that in such circumstances it is precisely targeted cross-functional management energy that is being expended to determine, define and collaboratively deal with specific  financial risks.  Indeed, there is little more any business could hope for.

Governance is More Than Openness 1

In a recent blog Richard Sage (@BakedIdea) points out that governance is just a matter of openness and sharing.  If only life were so simple.  If this were the case then what of Enron?  What of the whole global financial crisis?  These people were open?  These people shared?  They had GAAP reporting duties – So what went wrong?

The simple fact of the matter is that (i) governance is more than just sharing, but (ii) less than the full apparatus of conformance which Richard sets out.

More Than Sharing

Governance is more than sharing.  It is about design and flow.  Financial institutions shared information internally and reported it externally but this made not one jot of difference to the near collapse of the global economy.  Collateralised Debt Obligations (CDOs) were so complex that it would take a long time to unpick each one.  It is essential to understand that if an organisation actively conspires to confound regulatory procedures then there is no governance structure that will catch it.

“Governance without design is somewhat akin to looking at a ball of multi-coloured string and trying to guess what the pullover will look like.”

Organisations (here I extend the net to government and not-for-profit) need to design for misuse.  Understand that cross-functional information flows require some degree of architecture.  Without the necessary degree of design in governable artefacts (e.g. cost models, delivery schedules and contracts) it is impossible to unpick them.  In fact, it is somewhat akin to looking at a ball of multi-coloured string and guessing what the pullover is going to look like.

Governance Is Less Than You Think

I believe that governance is only the set of structures necessary to give confidence to institutional shareholders  that their interests are being well looked after.  The functions are the business processes and technical systems which enforce and deliver them.  This is why corporate governance speaks only of Directors Duties and not of business process.  The how will be forever changing in our modern and dynamic world.

In the end, governance is counterintuitive to business.  Good governance is seen to reduce profits, to close off avenues of growth and to burden management with bureaucracy and nugatory process.  Yet good governance should clear the way.  It should lower the bar and reduce the hurdles.  In concert with a stringent and effective assurance process governance becomes light yet effective.  It delivers confidence without suffocating the organisation.

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.

Corporate Fables: the value of enterprise storytelling Reply

Corporate storytelling is developing a huge following and it’s not just for CIOs.  Larry Prusak loves it, Patrick Lencioni has elevated it into a fine art and everyone seems to be getting the storytelling bug.  Stories are great because they help people from disparate backgrounds develop a common understanding of a problem or vision – one that sticks.  Storytelling has the power to corral even the most difficult of us and motivate us to play our part in the corporate journey.

Executives love stories because they require almost no detail, no plan, no roles and responsibilities and no changes in remuneration.  Done well, they can convince people into delivering more for less pay and when they don’t stories will shame those same underpaid workers into delivering the goods.  What’s not to like about storytelling?

Corporate Storytelling

At large UK outsourcing establishment there was an underperforming account in the Midlands.  Legend has it that the CEO of the local authority berated the account manager with the legendary phrase:  I’ll buy more IT when you can solve teenage pregnancy!” The account manager duly skulked into the corner and got on about his job of providing outsourced IT services.  What should he have done?  He should have used that story to develop truly value adding services which would have (i) increased the profitability of the account, (ii) built trust between him and the CEO, and (iii) possibly helped try and solve the actual problem.

He didn’t, so I did.  I went to India and spoke to our outsourcing partners.  I tried to engineer an end-to-end process whereby we could harness the incredible intellectual latency of our outsourcing partners, Genpact and Patni, to develop an integrated process for analysing local authority data then identify and target girls at risk for tailored social services.  In this way we could break the socially debilitating cycle of early teenage pregnancy whilst pushing account revenue into the stratosphere.  We needed to do this in a way that enabled us to retain the confidence of our customers as well as created buy-in from internal management.  So, we made sure the data security was right and that the project was aligned to the new corporate strategy of a greater push into outsourcing the middle-office.

I told the story.  I told it again and again but I used it to tease out the detail of the development process, the customer engagement process, the revenue model and the customer benefits.  Because, for every executive who smiled at the heart-warming vision there were 3 contrary developers, engineers and other middle managers who tried to shoot me down with the detail.  My story explained the engineering process.  My story was the glue which pulled all the systems engineering together and that is how I believe enterprise storytelling can help organisations.

Benefits-Led Contracting: no immediate future for outcome based agreements Reply

The IACCM rightly points out that key supplier relationships underpinned by robust and comprehensible contracts are essential to the implementation of significant strategic change.  Their research identifies a 9.2% impact on bottom line from contract weakness.  Top 5 causes being:

  •      Disagreement over contract scope,
  •      Weaknesses in contract change management,
  •      Performance failures due to over commitment,
  •      Performance issues due to disagreement over what was committed,
  •      Inappropriate contract structures or responsibilities.

Two things are given in this mess:  (i) Firstly, that contractual structures are weak and inappropriate to deal with high levels of operational complexity and technical risk, and (ii) secondly, that legal means of enforcement are cumbersome, expensive and ineffective.

That business is ready to solve this legal problem by contracting for outcomes is (a) nonsense and (b) missing the point.  Business is already dealing with the operational and technical risk of large and complex contracts.  Business is already structuring many of its agreements to deal with outcomes.  Large prime contracts,  alliance contracts and performance-based contracts are already commonplace in PFI/PPP and Defence sector deals.  That neither are wholly efficient or effective is for another time.  It is, however, for the legal community to devise more sophisticated ways of contracting in order to solve their side of the problem.



The primary reason for not being able to contract for outcomes is that the vendor doesn’t own the people.  This is critical because without the ability to control and intervene in the delivery of work the risk increases exponentially.  Consequently, the risk premium paid for outcome-based contracts will either make them (a) prohibitively expensive, or (b) impossible to perform (within parameters).  So, a business which offers you an outcome-based contract is either having you on or just about to charge you the earth.



INFOGRAPHICS: the worst form of risk management Reply

Aristotle wrote that “metaphor is the worst form of argument.  He’s right.  If you have something to show/prove, then do so precisely and in a way which is meaningful and useful to your target audience. 

Recently the guys at Innovation of Risk posted an article on the use of infographics to analyse risk.  I don’t know who coined the term “PowerPoint Engineering” but most infographics fit neatly into this category.  Infographics can save presentation or they can sink it but mostly they are used to convey ill conceived and poorly thought out ideas which snowball into worse run projects.  The best advice is to take these bath-tub moments (why do people think they have great ideas when they’re washing?) and run the analysis with an expert using an expert system.  If you can’t do that then (a) you’re in the wrong department for having the idea in the first place, and (b) chances are that there is a tonne of minute but important detail you missed out.

Whilst I think that visual display of graphics is vital to achieve stakeholder buy-in, it is also clear that imprecise PPT-engineering masquerading as infographics is the worst form of management snake-oil there is.  An erstwhile systems engineering mentor of mine used to say, “if you think they’re BS’ing you then ask them what the arrows mean”.  9 times out of 10 they won’t have a clue. 

Sometimes the best defense is deletion – CSO Online – Security and Risk Reply

Sometimes the best defense is deletion – CSO Online – Security and Risk.

data mining. big dataThe point is prescient.  In these early days of Big Data awareness the battle between information management v. store now/analyse later can obfuscate other issues:  Cost and Necessity.


Is there really the practical technology that an organisation can actually move away from structured databases and just stick all its information into one big ‘pot’, to be mined for gold nuggets at a later date?

Storing information (as opposed to just letting stuff pile up) is a costly business and the decision to store information usually comes from people on higher pay bands.  The decision of where to locate is often a manual decision which not only has a significant management overhead of its own but also involves co-ordination from other high pay bands.



Add to this dilemma the complexities of  ‘legal hold’ on material and the identification of ‘discoverable’ items.  Suddenly information management looks a lot harder and the siren song of Big Data seems a lot more alluring.  The problem is that information that is not valuable to some is valuable to others.  Who is qualified to make that decision?  Should all information be held given that it will likely have some enterprise value?  The battle is between cost and necessity:

  1. Cost:  Deciding what to keep and what to get rid of takes management time and effort that costs money.  The problem is that it is neither cost effective nor good policy to to push hold/delete decision making down to the lowest clerical level. The secret is to have those decisions made by more senior case-workers but only within their limited remit.
  2. Necessity:  The secret is to categorise management information to determine necessity.  Use a workflow to cascade and delegate (not to avoid) work.  As it moves it accumulates metadata.  No metadata means no necessity and therefore it should be disposed of automatically (eschewing arguments of regulatory compliance).


The answer is to automate the deletion of information (other than ‘Legal Hold’).  Once a document/question has reached the end of the workflow without accumulating any metadata then the information should be disposed of automatically.  Case-Workers make the decisions to act on the document/question and metadata is attached by more clerical staff (on lower pay bands) as the item moves through the workflow.  If no metadata is attached it can be assumed that the item is not important and is therefore disposed of.  Cost is minimised by letting case-workers make decisions of relevance within their own sphere of expertise without the additional management overhead for de-confliction/meetings etc.   In this way, the enterprise makes a collective decision of importance and stores the information accordingly thus answering the issue of necessity.

The Failure of Risk: lessons from the GFC Reply

risk management. hop scotchWe live in uncertain times. The failures in risk management which lead to the global financial crisis have created an unprecedented set of circumstances. Not only are regulators imposing heavier compliance burdens but shareholders and investors are demanding greater reporting and higher levels of information transparency. On top of all this operational costs are too tight to carry the overhead of separate risk and assurance functions.

When the analysis is done there are 6 key lessons to learn from the global financial crisis:

  1. Integrate G, R & C.  In medium and large corporations isolated risk management practices actively work against the business.  Technical and operational experts will identify risk from experience and create risk slush-funds to mitigate them.  These increase the cost of business and in many cases price the company out of the market.  In an integrated GRC system the firm is able to manage risks across business units so that the risk funds are held centrally and do not add a premium to initial project costs.  Risk identification and analysis percolates from the bottom up but governance is driven from the top down.  In an integrated system they both to work within the business lifecycle to add the right mix of checks and balances so that no additional drag is added to investment/project approvals.
  2. Make Passive GRC Active.  Systems need to be active.  They need to hunt out risk, define it, quantify it and measure the dependencies of the risk.  Then, those same systems need to bring it to the attention of the executives so that they may make informed investment decisions.  In the end, humans follow the law of least effort:  employees will follow the path of least resistance in designing and gaining approval for their projects.   GRC must not follow a system of honour & audit but rather one of  active assurance.  When GRC systems are passive the business lifecycle becomes clogged with nugatory and useless program reviews that turn into technical sales pitches by design teams.  Such events and practices only serve to affirm the belief that GRC is a legal burden and one which only serves to satisfy the needs of regulatory compliance.  Raytheon, for instance, have an excellent system of governance-by-exception.   Their Integrated Product Design System (IPDS) has active governance measures and allows Raytheon to manage a pipeline of thousands of critical projects dynamically and by exception.GRC
  3. Get Granular.  When projects fail it is not usually because the risks have not been adequately managed.  The primary problems in risk practices are the failures of risk identification and analysis.  Managers are simply unable to deal with risks at a granular level and then weigh them up on a per project basis.   This is largely because the technical skills needed to do so are not within the standard sets of most executives (but they are within the more mathematical ones of the FS&I industry).   Where this disparity exists then businesses need to develop separate Red Teams or Assurance Teams, either from the existing PMO of from hand picked executives.
  4. Bottom Up & Top Down.  Risk management is bottom-up but governance is top-down.  The technical skills and software reliance involved in effective risk management mean that the entire practice usually percolates from the bottom of a business, upwards.  Consequently, unless it fits within a comprehensive governance framework it will be open to being gamed by senior executives.  This is why major projects which are seen as must-win are often approved with little or no governance or assurance.
  5. Risk Ownership.  Risks need to be owned at the lowest responsible level.  This is to say that when things go wrong the person at the lowest level who has the greatest amount of operational responsibility must be able to take charge to mitigate all aspects of the risk.  It is vital that the person owning the risk be able to recognise the variables which may see the risk realised.  It is also critical that the risk owner understand the corporate decision points, i.e. the points at which the contingency plans should be triggered.
  6. Invest in the Right Type of Risk Culture.  Risk should not be a dirty word.  Risks are inherent in every project and balancing them quantitatively and qualitatively is an essential skill for all senior executives.  Risk should be as much about seizing opportunity as it is about guarding profitability.  Businesses need to invest in top talent in order to drive good risk practices from the top.  Effective, Active-GRC involves a complex array of tools, practices, structures and processes which need an experienced senior executive to drive them constantly and consistently in the business.  The softer side of risk management cannot be neglected.  The nature of risk forces people onto the defensive as they attempt to justify all aspects of their project designs.  CROs need to help executives understand that all projects must balance risk if they are to attempt to push profitability.  Otherwise, risk cultures will mire companies in conservative, risk averse cultures which only act to add friction and reduce profitability.

Risk practices need to work together inside a single, comprehensive risk framework that goes beyond simple probabilistic modelling and disjointed regulatory compliance.   Businesses need to implement processes which not only integrate the business lifecycle but actively increase both liquidity and opportunity for risk to be seen to add real value to the company.   Only once this is achieved can risk management cease to be an operational drag for the business and become a value-adding proposition which works actively to increase the profit and performance of a company.


Top 5 Benefits of Effective Risk Management 1


After the failure of risk management during the recent (and ongoing) financial crisis one could be forgiven for thinking that risk management – as we know it – is dead.  However, effective risk management is the only means which businesses have to:  (i) assess and compare investment decisions, (ii) seize subtle opportunities, and (iii) ensure regulatory compliance.  Risk management has greater utility beyond these obvious benefits.  Listed below are 5 of the top financial benefits of effective risk management:


When managers cannot identify or mitigate complex risks they create risk contingency slush funds and pad their accounts with excessive risk premiums. This is not an efficient allocation of capital and it can even price a business out of the market. Precise identification of risk premiums removes these slush funds and creates greater firm liquidity and the ability to allocate capital where it is needed.


The best methods for risk identification and analysis of risk in projects are through the quantitative analysis of cost models and project schedules. However, these methods are only useful where such models are in enough detail. Good risk management leads to greater collaboration by cross-functional teams to optimise cost and schedule performance.


With greater liquidity comes the ability to seize emerging opportunities. Not only can the company use this capital across portfolios to manage risks but it can also seize opportunities for M&A, talent acquisition, share buybacks, increased dividends, employee bonuses or increased project funding/investment.


As managers work across the business to calibrate cost models with the project schedules; the contract and commercials with the technical architecture, the business is forced to adopt a more consensual, multi-disciplinary approach. Where GRC is implemented as part of a high-performance business initiative the culture is more likely to stick rather than one imposed from the top-down.


An active GRC process which is fully integrated with the business relies on the quantitative analysis of core artifacts (cost models, project schedules and technical architectures and contracts). A quantitative culture coupled with regular, detailed analytical outputs also greatly improves the standard of financial and operational reporting and therefore the possibility for improved investment decision making.