How to Construct a Risk Statement Reply

Risk is not a self-licking lollipop.  Nor is risk a beautiful and delicate flower to be tended and admired on its own.  Risk is part of a system (Assurance) and that system has a point and the point is to reduce cost and time growth; both now and in the future.


It does this in two ways:  (i) operational pull-through, and (ii) commercial pull-through. Where operational pull-through reduces cost and time overrun now, commercial pull through reduces cost and time overrun (often the same) in the future by breaking the causal chain of a potential claim as well as by reducing future liability by addressing specific areas of causation.  Traditional Risk Management addresses operational pull-through.  The goal is to assess what might go wrong on a project in the immediate future.  The structure of the deal and any inherent soft-spots within it are rarely given thought.   Commercial pull-through is just as, if not more, important.  Commercial pull-through will support or defend claims (either extension-of-time or cost) and it will help resolve further issues of liability.

“The financial risk is hardly ever worth taking. I have just seen a £5m job ending up with a £12m claim.  A lot of clients are still not prepared to spend the money up front to get the contract, the budget and the contingency right. I would say you can end up spending around 10 times as much resolving a dispute compared to what you would have needed to put in at the start to avoid it becoming an issue.”

Gary Kitt, head of contract solutions in the UK for EC Harris.

The linchpin for both is causation and the key to proving causation is through causal chains.

Causal Chains

Figure 1 below outlines a causal chain for a fictitious business problem.  In this case, low quality steel is likely to affect the build of a steel frame on a construction site.  The Contractor, warranting the workmanship of the building, they will be liable for defects in the future.  Additionally, they have operational liability now and will likely incur some cost growth through re-work.  ‘What is the cause?’  is an ontological question.  ‘How can the business reduce their liability and current costs?’ is a business question.  In the example below the Supplier’s liability is counterweighted by an equally damaging causal chain derived from the Contractor’s poor welding.  Without the ability to define and delineate these causal chains – and therefore limit libility – the Contractor will have, prima facie, extensive liability from poor workmanship.

In exploring the context of our example somewhat more, we begin to understand that although the lower capability of the workforce was compounded by a low supervision ratio, the welds themselves were of a sufficient standard to warrant their quality.  A poor understanding and examination of the causal chain would not have held out such analysis. A poor understanding has the lawyers and commercial team clutching at straws rather than aiming to rebut or settle the claim.

Causal Chains

Figure 1 – A causal chain from a Construction Company example.

Causation:  Assumptions v Weaknesses

The primary problem with causal chains in the poor understanding of causation itself.  In the aforementioned example at Figure 1 many Risk Managers would misassociate the possibility of the framework buckling with the assumptions and technical trends further upstream.  None of them, however, on their own are either sufficient or necessary to cause the buckling of the frame.  Causation can have multiple factors but only so many that are sufficient and necessary to give rise to the risk.  In this case, some of our causes can be demarcated into a different causal chain altogether.  If placed together, therefore, would confuse the commercial negotiating leverage that such risk analysis was able to provide.

Counter-Factual Argument

Be careful of counter-factual arguments, i.e. the “but for” or sine qua non analysis of causation.  Scholars of causation theory, such as David Lewis, were deeply sceptical of counterfactuals.  For example, were a cat to jump out of a window after I had unlatched it, prove causation?  No but under a sine qua non my guilt would be highlighted.

Risks:  Events v Transitions

One should never think of a business risk as an event.  This may be heresy to some but unless you can easily distinguish between the causation events, risk events and impact events then you should seek to differentiate the language used to define them.  To try and conceptually isolate individual events is like trying to spot the offending domino.  They all played a part. However, by having a language and methodology to differentiate causal elements and causal chains one has the ability to reduce duplication and redundancy in quantitative risk simulations.  For instance, when deconstructing problems we talk about ‘structural weaknesses’ and not causal events.  Such language helps us delineate between causal events rather than redefine a taxonomy of risk.

Risk statements are often the hardest to differentiate.  One can understand causal events (although pinning them in time can be difficult without the right language) but structuring a risk statement itself can be conceptually difficult.  A risk, after all, is artificial.  Instinctively, we know cause-and-effect but risk is far less intuitive.

Conceptualising risk as yet another event in the causal chain opens risk up for too much confusion.  What is needed is a way to encapsulate, in  a risk statement, the impact to the business of a causal chain.  One way to do this is through transition statements.  Viewing risk as a potentially harmful state transition is a useful way to construct effective risk statements.  For instance, the risk of falling off my chair at work is not in hurting my back or even breaking the chair.  It is that I will transition from earning to not earning.  Wording risk as such allows us to articulate the causal chain without contaminating it with an artificial risk statement, i.e. the risk statement is the conceptualisation of a discrete part of the causal chain.

Impacts:  Impacts v Effects

It is important to distinguish between types of impacts in causal chains, after all, not all impacts are relevant or useful but can be included by naysayers and contrarians to obfuscate the effect of a risk and thereby avoid being delegated work.  The impact that is relevant in risk is the direct causal impact.  Impacts felt further downstream are important and may be relevant but not to an accountant or lawyer.  Downstream impacts may be distinguished as ‘effects’ and therefore only of indirect causal significance.

In summ, there is not commercial pull-through without precise causal chains.  Claims can be developed and leverage gained without them but always imprecise and far more costly to generate.  If Risk is ever to be a sophisticated, value-adding practice in the business then it must show commercial pull-through and to do that it must start with supporting the development and analysis of causal chains.

The Fallacy of Process Reply

“Every block of stone has a statue inside it and it is the task of the sculptor to discover it.”


Michelangelo felt that defining a beautiful statue was a constant labour of chipping away at the stone that wasn’t ‘David’, for instance.  It wasn’t a process that started at the feet and ended at the head.  There was structure to his activity but none which could be codified.

Corporate Risk Management is far less artistic but the analogy is nonetheless useful.  Risk Management often defies process because it is not an architectural pillar of the business.  There is no design in Risk Management.  By its very nature it revolves around the constant engagement with the business to define and refine the potential impact of business problems.  Risk Management, therefore, is highly iterative but just in the same way that Michelangelo chipped away at the statue, so too does the effective Risk Manager chip away at corporate problems in order to define their true reality.

This lack of process is upsetting to some and indeed unsettling to many Risk Managers. Corporate Services, unnerved by their lack of operational necessity always feel they have to sit within a process in order to find meaning in their labours as opposed to defining the value they create in the overall outputs.  Risk Management – as part of the Assurance function – needs to justify its intrusion into the business by:

  • the costs and time it helps to save,
  • the risks it helps to mitigate, and
  • the workload it reduces within teams.

and ultimately by doing so in the least obtrusive manner.

Like the sculptor, however, there is process underneath it but this is often highly specific to the industry and level of the role.  What is key is that there is a common maturity level in Risk Management, namely:

  1. Structure.  Risks must achieve structure before anything else.  They need to be made up of singular statements of atomic risk, i.e. the risks are granular.  The statements themselves need to be clear and precise and broken into causation, risk and impact which articulates a complete and direct causal chain.  The key to remember is that the structure and the granularity of the statement will refine over time as more information is borne out.  Risk is fractal.  The closer one looks, the more detail becomes apparent.  Structural weaknesses giving rise to problems can be traced deeply; internally and externally.  Knowing when to stop is often half the art.
  2. Completeness.  The risk statement must also be complete.  Like structure, completeness will be a battle.  Mitigations will change and develop over the life of the project as will impacts as the resilience of the surrounding architecture develops.
  3. Quantification.  Risks should be quantified but not all of them can.  It is hard to quantify reputation and relationship risks.  However, at the operational, service and technical levels quantification in terms of time and cost impacts will be vital.
  4. Traceability.  Risks need to be traced.  It is self evident that a risk must have provenance if it is even to be considered.  If it can’t it does not necessarily mean that it won’t eventually be a risk but rather that, currently, all it can be is the feeling of a problem; however legitimate a feeling nonetheless.
  5. Utility.  Lastly but most importantly, a risk must be useful., either to the business or the team.  Regardless, if the risk does not add value then it serves no purpose.


These five points go to the heart of effective Risk Management:  that it is not process but methodology which drives its effectiveness.  Section 3(J) of ISO 31000 clearly sets out that Risk Management is an iterative process.  A process, on the other hand would imply a sequential jump from one completed phse of Risk Management onto the next.  According to Deloitte’s (Figure 1 below), the third biggest challenge to businesses is in achieving clear and effective risk data.  A concern which underscores the need for iterative cycles of assurance right throughout complex projects.  Chipping away at risks using the aforementioned approach, therefore, is a useful and highly effective way to achieve assured projects without the need for over-prescriptive and intrusive processes.


Figure 1 – Deloitte Global Risk Management Survey, 2015.

“The financial crisis has underscored how insufficient attention to fundamental corporate governance concepts can have devastating effects on an institution and its continued viability. It is clear that many banks did not fully implement these fundamental concepts. The obvious lesson is that banks need to improve their corporate governance practices and supervisors must ensure that sound corporate governance principles are thoroughly and consistently implemented.”

Danièle Nouy,  President of the Supervisory Council at the European Central Bank.

Trying to add too much structure is doomed to failure and being over-prescriptive is counter productive.  Risk does not create value and so the RM needs consent and co-operation to perform deep, effective risk management because it iss all about gaining trust and confidence to explore into the deepest and darkest spaces of the business.  Indeed, the entire Assurance function needs to justify its interference and intervention to make sure that it’s not holding up delivery  or interfering with operations.  This can be extremely uncomfortable and even confrontational.

In large and complex programmes the burden of governance is onerous.  Lots of things can go wrong and statistically they do and ultimately people are working with and because of someone else’s money.  For that reason project teams need to structure for transparency and be prepared to report the detail and context of their variances.  Under such circumstances the process of sculpting risk becomes much easier.  The image of David more obvious.

The organisation should be motivated to maximise their gains, tempered only by a mature, well-developed, empowered and independent assurance function which has the ability to monitor, measure and rein in projects in a precise and appropriate way.  This relies on the systems to achieve transparency and the expertise to achieve visibility.

It is impossible to say how effective this approach is as the more successful Risk Management is the more likely it is to be seen as unnecessary.  The approach, however, is certainly more sustainable. The pendulum swings between over-regulation and laissez-faire operational focus.  Rigid structures are always too brittle to survive.  The only way to achieve a sensible and sustainable balance is not to clip the wings of the business but give them give them strict parameters within which to spread them and fly.  As the saying goes:

“You don’t know who’s swimming naked until the tide goes out.”

Warren Buffet.

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 executives on 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 problem statements.  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.

Rory Cleland

riskHive Ltd

What is a Risk? Reply

“When you combine leverage with ignorance you get some pretty interesting results.”

Warren Buffet.

To extend Warren Buffet’s sentiment, the greatest threat to effective risk management, therefore, is poor risk identification.  Put simply if we can’t discover and quantify risks then our exposure is neither visible nor manageable.  This may be acceptable to small, contained project/investment teams who have a greater inherent understanding of the risk context but it certainly should send shivers up the spine of any senior executive.

Business v Metaphysical Risk

Firstly, let us be clear that we are trying to identify business risks, not metaphysical risks.  A business risk has a clear and direct impact in cost or time.  A metaphysical risk might still, theoretically, be a risk but without any effect which may be directly quantifiable in cost or time, is not a threat to the business.

Business Artefacts

It stands to reason, therefore, that business risks can be uncovered from the Business Artefacts.  The 5 core business artefacts are the:  Contract, Cost Model, Schedule/Plan, Architecture and, of course, Risk Register.

Business Elements

Business artefacts are made up of business elements and should encompass all the discoverable things that could potentially go into a Risk Register.  A business element is not necessarily a business driver, because business elements should be used to extend visibility in a project.  For instance, a construction company may be building a steel frame. The steel is the core component.  Its price is a critical driver of cost and its arrival is a critical driver of the schedule.  However, what happens when upon inspection of the welds and joins the company discovers that the steel is of poor quality?  Insurances and liability  clauses indemnify the company for loss but they will never get all their money back and nor will they recover their schedule.  In this real life example the business would never have had any visibility over their supply chain risk.  It would not normally go in the cost model because their is no cost of quality, i.e. it isn’t a cost driver, it’s a compliance factor.  It should, however, go into the cost model as a business element in order to give visibility to the project team and allow them to draw out risks. It is, therefore, vital that teams have as much visibility as possible into business drivers if they are to develop effective mitigation strategies.  For instance, the business without full visibility into the elements of cost and quality will naturally use insurance to offset the risk from having to indemnify clients from faulty workmanship.  The business with visibility into the elements behind the cost or steel or its delivery or place in the business architecture, will be able to place simple quality mechanisms in place to reduce their insurance costs.  Will this come from the cost model?  Possibly but if not then such technical risk may be modelled or measured  from the architecture (a topic we will look into later).

3 Criteria of a Risk

As not all business elements are business drivers, so too not all business drivers are risks. For a business element to be a risk it needs to have the following  criteria, i.e. it needs to be:

  1. HOT.  Once the deal has started, the element needs to be running at a variance (negative or indeed positive).
  2. SENSITIVE.  The element needs to cause volatility within the cost model or the schedule.  It needs to cause exposure in the contract or significant problems within the architecture.
  3. WEAK.  The element needs to exhibit some structural weakness.  The structure may be a commercial structure, a financial structure, a technical structure or an organisational structure.  The key point is that it must not be something that the business or agency traditionally recovers well from.  For example, a business element might be running hot and it might be sensitive but if there is no inherent structural weakness in it then it’s highly likely that it is just following a standard pattern of variance trajectory.
Risk Criteria Venns

Risk Identification

A business element may evidence one or more of these criteria but unless it fulfills all three then it just isn’t a risk.  A problem, a potential problem maybe but not yet a business risk worthy of inclusion on a business’ Risk Register.  After all, a business can only quantify tangible problems, not the metaphysical.

The 10 Commandments of Risk Reply

Old Newtonian physics claimed that things have an objective reality separate from our perception of them. Quantum physics, and particularly Heisenberg’s Uncertainty Principle, reveal that, as our perception of an object changes, the object itself literally changes.

Marianne Williamson.

All risk is a wet finger in the air.  A scientifically wet finger but a wet finger nonetheless.  In large and complex programmes which have a fluid dynamic all of their own we are unable t0 define and analyse detailed statistical models in order give certainty to probabilistic analysis.

Why Bother with Risk?

Why bother with risk in an every changing programme, if our analysis will always be insufficient and caveated by a long list of exceptions?  Why not just trust our technical experts and their inherently detailed understanding of the technical risks and their commercial contexts?  There is a strong argument for letting technical expertise run the projects in the absence of structural control.  There are far more powerful arguments which provide counterweight, though.  The primary concern is, of course, that large and complex programmes – statistically – never achieve their cost and time parameters, usually causing embarrassment to the contractor and concern to the investors.

So, what should the ground-rules of Risk be to ensure that our analyses have a modicum of consistency in order to achieve some consensus in their predictability?

The 10 Commandments of Risk:

  1. Not all Genuine Concerns are Risks.  In all honesty, most ‘Risk’ statements in Risk Registers are more generic problem statements;  large aggregations of things that might have an adverse impact on the business.  They are issues, assumptions and trends.  To be a ‘Risk’ it has to be an atomic element of the business that can directly and quantifiably cause an impact in cost and/or time.  If it can’t then it needs to be decomposed and deconstructed until it can.  Which brings us to our second commandment,
  2. Risks Require Contingency (Assumptions Require Analysis).  Risks are used to develop contingency.  A business should have as few risks as they can in a Risk Register.  The more risk, the more contingency (cost or time).  CYA risks have no place in a Risk Register and it is the job of the CRO to ensure that all such Risks are weeded out.  What is left can be sifted for legitimate concerns.  In turn, these can then be decomposed and deconstructed in order to drive out the golden nuggets of risk which lie hidden inside such large, clumpy statements.
  3. Most Risks Need to Be Traced to Cost or Schedule.  In order to determine contingency the Risk needs to be simulated within a cost model or schedule.  In order to do this the Risk needs to be attached to a specific cost item or line in the schedule.  There are some risks at the strategic level (corporate reputational risk) which are not attached to cost or time and we will delve into these when we show how risk frameworks are used to classify and categorise risks.
  4. Risks Need To Be Classified and Categorised.  Categorising and classifying risks is an extremely useful way to ensure that duplication and redundancy is avoided.  It is statistically likely that a relatively even spread of risks will occur in a large and complex project.  In fact, in large technical delivery projects the majority of risks are usually technical because that is all that the business knows.  Unnatural skewing should reveal where exposure is more likely.  For instance, significant Risks around ‘resourcing’ often highlight capability gaps in processes or a lack of role clarity.
  5. Risks Require Resources.  Real risks need accurate and adequately resourced mitigation plans.  If the Risk Register is loaded with fanciful and fictitious risks then it would be astronomically expensive to actually mitigate them.
  6. Risks Must Be Hot, Sensitive & Weak.  See our first blog.
  7. Risk Statements Must be Singular and Atomic.  Risk statements must be singular and atomic if the ensuing Monte Carlo simulation is to have any meaning at all.  Simulations founded on duplicated or overlapping risks will have no credibility at all.
  8. Risk Statements Must Articulate a Direct Causal Chain.  A Risk statement must be made up of three direct elements of a causal chain:  The transition statement (RISK), the structural weakness (CAUSATION) and the impact (direct causal impact on time/cost).  Too often, Risk statements are taken from different parts of a causal chain and may only display loose and tenuous relationships between each other.
  9. Risk Causes Must Highlight a Structural Weakness.  Causation must clearly and precisely point to some form of structural weakness.  In a business, this may be legal, organisational, financial or technical.  However, if accurate and delegable mitigations are to be created then then clear structural weaknesses must be identified.
  10. Causes Must Be Necessary and Sufficient.  The test for causation is necessity and sufficiency.  For instance, a fire needs both the presence of combustible material as well as the absence of fire retardant, to be a business risk.  It is not sufficient to say that there is an electrical fault somewhere.

In future blogs we will delve deeper into some of these elements but together they form the core rules of risk identification and management.  Indeed, by following these simple rules, along with the underlying context, Risk will become simpler and more meaningful.