RISK: A Quick-Start Methodology Reply

Enterprise Risk Management Systems (ERMS) are a powerful means to aggregate and assess risk data in large portfolios.  The systems empower better decision making by enabling project teams to collate, analyse and report on complex risk information and support senior decision making upwards and across the organisation.

However, it is only through the accurate input of risk information that users achieve deep insight by precise analysis.

The following methodology provides for a detailed approach to structuring risk statements as well as collecting and aggregating risk information.  The method is part of a wider approach to governance, risk and compliance that enables the fast, efficient and effective capture and management of risk.  It does so in a way which not only reduces the overall cost and burden of effort but also increases the value that risk management adds to the organisation by increasing stakeholder buy-in through more effective cross-functional collaboration over complex risks.  In turn, organisations and teams derive a far greater benefit from an ERMS’ analytical power with the additional support of the extended project community.

Together, an ERMS and accompanying methodology provide mutual support for a more streamlined and cost-effective means for managing complex portfolios of risk.

The 8A Methodology

Identifying what might go wrong on projects is often self-explanatory.  A good project manager will usually know most risks, when they might occur and what to do about them.  The value of a system, however, is in managing the sheer volume of risk in large projects as well as understanding and mapping the interplay of subtle and complex risk factors across portfolios.  The 8A Risk Methodology provides users the guidance to collate and calibrate risk data across a wide range of projects so that collection is streamlined, analysis is precise and the necessary management action is accurate and effective.

  1. ABSTRACT.   Identify and isolate the information sources to be analysed and used.
  2. ASSEMBLE.   Extract and gather uncorrupted information at source.
  3. ARTICULATE.   Deconstruct complex problems and structure singular statements of atomic risk.
  4. AGGREGATE.   Demarcate and delineate risk data so that there is no duplication of risk across the portfolio.
  5. ANALYSE.   Run quantitative and qualitative analysis on risk information.
  6. ASSESS.   Increase stakeholder buy-in of quantitative analysis through subjective scoring and prioritisation.
  7. ADVISE.   Report risk across and upwards in the organisation.
  8. ALIGN.   Assign, delegate and track the progress of risk mitigation action.

Identifying Risk

A risk is not always a risk.  More importantly, business risks must be filtered from all the metaphysical risks.  The following definition enables users to define the real and tangible business risks from the plethora of vague and tenuous risks which unnecessarily fill risk registers and sap management attention.

  1. HOT – the ‘heat’ of a risk only applies to in-flight risks/ contract management.  The ‘heat’ of a risk/element/item is traditionally derived from Finance’s assessment of adverse variances.
  2. VALUABLE – the value of a risk depends on how sensitive the overall cost/schedule is to the particular element.  This can be derived from a sensitivity or statistical analysis.
  3. WEAK – the element must also have or be part of some weakness in the project.  This may be a physical or conceptual weakness, e.g. the weakness in steel or the weakness in a contract or the weakness in a claims management process etc.

All 3 of these criteria must be satisfied if something is to be classed as “at risk”.  For instance, an object may be running hot and it may also be highly volatile in the cost model but if the variance is within parameters and it is a thing that is traditionally managed well then it is not really at risk.


The abstraction process involves the identification of the types of risks which exist in the projects, usually around some form of risk framework.  From there the teams can identify sources of risk information.  The Risk Manager will not have deep experience across all the functional areas of the project and so will need to direct departments and teams in a simple but effective manner.

The abstraction process involves the identification of the types of risks which exist in the projects, usually around some form of risk framework.  From there the teams can identify sources of risk information.  The Risk Manager will not have deep experience across all the functional areas of the project and so will need to direct departments and teams in a simple but effective manner.


The process of assembling the myriad risk data that the user has identified is not always a simple process.  Despite the supposed ease of technological interoperability most data is designed to reside in and be used by single systems (and perhaps their proprietary add-ons).  Assembling risk data often involves the export of data from a variety of systems into excel spreadsheets so they may be manipulated.

Extracting data, especially on a monthly basis, must be simple, repeatable and non-intrusive.  It should always be conducted by the Risk Manager for 2 reasons:  (i) for confidence in the provenance of the numbers, and (ii) because extraction (along with all other areas of risk management) must not increase management effort, unless the task adds value.


Deconstructing risks into singular statements of atomic risk can be surprisingly difficult and often leads to the most experienced managers tying themselves in mental knots.  In simple risk registers it is often not necessary as risk may be clumped into rough blocks of obvious risk.  In this way organisations may precisely allocate and manage contingency funds.

When deconstructing ‘clumps’ of risks it is often best to work backwards:

  1. Impact. Focus on the financial impact, i.e. the potential loss.  This will help remove irrelevant risks from the analysis.  For instance, if I fall to the ground because I sat on a broken chair the financial impact will be my loss of earnings whilst recuperating.
  2. Risk.  Identify the change in state which caused the financial impact.  Note:  Risks are best seen as an ‘adverse change in state’, e.g. changing from ‘employed’ to ‘unemployed’.  Focusing on risks as events can be too narrow.
  3. Cause.  Ask ‘why?’  In our case why did I stop earning money?  The risk will be realised by some weakness (either structural or operational).  The weakness may be in the schedule, costs or contract as well as part of any physical structure.  In our example it was the weak leg of a chair.  Note that it was not just the weak leg of a chair.  I also had to sit on the chair, there had to be an absence of any soft landing and I had to fall awkwardly.  All these additional conditions are necessary but in and of themselves they are not sufficient to cause my injuries.  The single causal statement is the weak leg which was both necessary and sufficient to cause my injuries.  The other conditions were also necessary and should figure somewhere in the risk equation but they will not form part of the causal statement.
  4. Outcome. Ask the question: “what happened when it broke?”  This will refer to what happened when the chair broke, when the contract broke, when the management process broke etc.  This will be the effect statement.  In the example, when the chair broke the effect was that I fell to the ground but the outcome was that I injured myself.  The distinction is small but important.  As risk managers we need to be aware of how to reduce the probability that I sit on the chair as well as the outcome should it break.  So long as all the parts of the risk statement link up in a single, direct causal chain the distinction is not important.
  5. Calibrate.  The whole statement needs to be a singular statement of risk in a direct causal chain.  This is to say that the cause > risk > effect > impact are all directly causally linked.


One of the greatest benefits of an ERMS is in its ability to aggregate risk data across large and complex portfolios.  Not only can the system manage numeric data visually – with BowTie diagrams – but it has the ability to analyse large volumes of data using project tree-structures.  In order to do this risks need to be singular statements of atomic risk.  In this way the user may demarcate risks and delineate between them.  This not only comes from tagging risk data with categories and classifications but also through the structured statements of deconstructed risk.

  • Singular.  Make sure that the risk statement only contains one risk.
  • Atomic.  Make sure that the risk statement only refers to one element of structural weakness.
  • Classify.  Classify risks.  Classifications are ‘objective’ groupings of types, e.g. a girl is female human.  Project classifications typically include:  construction or IT or financial etc and are best derived by asking “what sort of project is this?”
  • Categorise.  Categorise risks.  Categories are ‘subjective’ groupings of risk types, e.g. an “IT Girl” is a type of girl based on subjective factors and may change from time to time. Project categories may include: Projects in the Bowen Basin and are best derived by asking “what type of classification is this?”
  • Categories and Classifications are very important in large portfolios as they are an essential step in reducing duplication and redundancy.


Risk is about seeing around corners.  Any good risk system must be able to provide some sort of predictive analysis based on the data that is already known.  Stochastic simulation through Monte Carlo analysis provides for a degree of objective, quantitative scoring.  Coupled with qualitative assessment both help the users predict what might go wrong, when, where and what it might affect.  Importantly:

  • Inputs are the hard bits but the better the inputs the better the outputs.
  • Quantitative simulation and analysis provides for irrefutable, objective results.
  • The provenance of risk data is critical.
  • Qualitative assessments increase stakeholder buy-in and executive confidence.


Subjective (qualitative) assessments of quantitative data drastically increases the quality of the analysis along with the level of overall stakeholder buy-in.  Subjective analysis may include scoring prioritisation but it may also include other factors such as ‘complexity’ or ‘proximity’.  All these factors help executives and project teams decide on and delegate the best management action.


The primary purpose of risk analysis is to assign management action.  This may be the allocation of contingency funds, insurances or the injection of liquidity from elsewhere.  Regardless, risk is not being managed if it is not reported in a useful and meaningful way across the organisation and upwards.  It is also worth noting:

  • People, generally, know how to manage their own risks.
  • Enterprises do not, generally, know how to manage complex webs of risk with multiple interdependencies.
  • Visual reporting creates better buy-in beyond risk/project personnel.
  • Resist the urge to misrepresent risk information in non-standard PowerPoint diagrams.  Infographics are excellent but PowerPoint engineering is an executive crime.


Alignment is used to describe the  process of calibrating risk data across the projects and portfolios.  This is a vitally important activity and it ensures that the analyses made in one area are carried through to their logical conclusions.  For instance, project risks need to have assigned management action in the project Risk Management Plan.  Likewise, an analysis showing that £X contingency allocation is necessary needs to show up in the project funding.

Alignment is usually where the science of risk stops and the ‘art’ of risk management starts.  Equipped now the relevant, detailed data there will invariably be areas which simply do not make sense.  It is the job of the Risk Manager to muster all their soft skills to ask the difficult and uncomfortable questions.  In doing so they will inevitably align much of the data with the artefacts.


Deconstructing risks is often not self explanatory.  Risk managers and project teams can get bogged down in what seems like a simple task.  Unable to move past what seem like trivial semantics, risks are clumped into clunky statements.  The duplication of risk and redundancy of mitigation strategies leads to the artificial inflation of sums at risk and the over-allocation of contingency funds. The 8A Methodology provides a structured approach to the problem of deconstructing risk problems and building a comprehensive Risk Register which provides a dynamic means of analysing risks across broad portfolios.


  • ISOLATE data based on a structured methodical approach/framework.
  • EXTRACT data at source in a non-intrusive way.
  • DECONSTRUCT clumps of risk into singular statements of atomic risk.
  • ANALYSE risk with a variety and range of sophisticated tools in order to develop unassailable objectivity in the results.
  • ASSESS quantitative data qualitatively.  Create better stakeholder buy-in through internal and statistical scoring.
  • REPORT risk information across and upwards.
  • CALIBRATE risk data across all business artefacts.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s