The CASE for risk identification

“The first principle is that you must not fool yourself, and you are the easiest person to fool.”

Richard P. Feynman, Nobel Prize–winning physicist

Not long ago, I was invited to facilitate the review and update of a risk management plan for an IT project that had been running for a number of years. You might be forgiven for thinking that a $120-million program would be well documented, and that my job would be relatively straightforward. My first clue that this was not the case was when I reviewed the documentation and discovered that the project was currently in Year 12 of a 10-year project and had at least three more years to run. The second clue that things were not well was that I was invited to facilitate a risk management workshop with just a few days' notice.

Surprisingly for a project which had been running so long, there was a complete lack of concurrence by workshop participants regarding even basic things, such as the risk ratings that had been previously assessed for the project. Quite simply, the risk registers comprising some 300 risks were unworkable, not only in quantity, but in the quality of their descriptions. The project risks had been described using terms such as "procurement," "shortage of skilled labor," and "cost overruns." These terms reflected some very real risks, but you simply can't address a risk like cost overruns unless one knows what might cause it and the "so what?" factor. Thus, I went back the next day to the client to negotiate a change of scope to completely revise the risk register before running the rest of the planned workshops.

For the want of a shared understanding
The challenge faced by the project stakeholders in trying to agree on risk ratings and risk treatments was akin to someone trying to assess and manage the risks associated with the "war on terror". Everyone has their own concept about what terrorism means, so asking a group of 10 people to rate it, or treat it, is likely to result in 10 different ratings and even more treatments. To achieve a degree of consistency one must, at the very least, be specific about what type of terrorism one is concerned about before one can hope to assess, much less mitigate it. Consider the terrorism risks in the following examples:

• Religious fundamentalists seeking to inflict maximum loss of life to gain international publicity and leverage for their cause with no fear of sacrificing their own lives.
• Environmental activists in inflatable boats seeking maximum media attention through minor acts of sabotage with minimum personal risk and no loss of life.
• Local right-wing thugs seeking to incite fear by committing assaults and arson on properties owned by immigrants.
• Sarin attacks in the subway by religious sects with unstated objectives.

As you can see from the above examples, the so-called risk of terrorism can actually be multiple different risks with correspondingly different likelihoods and consequences.

The actual CASE methodology
So how do we actually record a risk in a way that everyone can reach some sort of agreement on its severity or relative priority? The most consistent way I know is to use a method that I call the CASE risk identification tool. CASE comes from the following four characteristics discussed in analyzing a risk:

• Consequence: What is the likely impact of this risk?
• Asset: What asset(s) are actually at risk?
• Source: What are the hazards or threat actors that might lead to the risk manifesting?
• Event: What particular type of incident is being considered?

Why do you need these four items to define a risk statement? Let's look for example, at the risk of compromise to sensitive information. It's difficult to analyze and rate this risk if we only have the event and the asset listed. Consider the following examples and how you might rate theses risks to your organization:

• industrial espionage by competitors
• theft by criminals seeking to sell it back to you
• theft of a briefcase from a car by petty criminals
• staff inadvertently releasing sensitive information to the corporate website.

The consequences of each of these would vary quite considerably and so too would the likelihood of the risk occurring.  This in turn would affect the risk rating and the risk treatments that you would use to address them. Consider however just how much easier it is to assess the risks if they were written to include CASE:

• Financial loss (Consequence) due to espionage (Event) by competitors (Source) resulting in reduced profits (Asset).
• Failure to protect information (Asset) in transit from theft (Event) by opportunistic criminal activity (Source) resulting in adverse impact on reputation (Consequence).
• Compromise of sensitive information (Asset) due to untrained staff (Source) bypassing controls and inadvertently posting files to corporate website (Event) resulting in competitive disadvantage, reputation damage or financial loss (Consequence).

Is it complicated?
At first glance, it may appear challenging to use CASE to define risk, but it can be done in a sentence or two. The easiest way I know to build a list of risks in a systematic way is to put the into an Excel spreadsheet and use drop-down menus to limit the options. For example, you might want to limit the potential consequences to some key categories:

• People
• Information
• Property
• Financial
• Reputation
• Capability 

The light yellow cells are the data entry areas and blue cells are used to select risk ratings (eg: from a risk matrix). Putting this spreadsheet up on a data projector makes running a risk workshop to compile risks, very fast and transparent.   I've also used this approach in Excel to automatically generate an initial written risk statement.

If there's interest, I can put this Excel document up on a website to download but if you'd like to know how to do this yourself, just create the above cells in Excel and put =E2&" loss due to "&B2&" by "&C2&" leading to compromise of "&D2&"." into Cell 'I2' you will see the following risk statement generated: "Financial loss due to Espionage by Competitors leading to compromise of Information."  You would probably want to tidy this statement up a bit in the final report but it's one way to speed things up.

Need some more examples of other types of risk?

• Financial loss (Consequence) associated with collapse of international property development portfolio (Asset) due to foreign currency fluctuations (Event) as a result of global financial crisis (Source).
• Loss of life (Consequence) of personnel (Assets) due to improvised explosive device attack (Event) by terrorists (Source).
• Loss of income (Consequence) due to non-availability of personnel (Asset) as a result of injuries flowing from under-reporting of hazards (Event) caused by lack of training in hazard reporting procedures (Source).

Opportunity realization
The same structure can be used to describe positive risks:

• The business case analysis shows a potential net present value of $1.2 million financial benefit (Consequence) if we tender (Event) the facilities management contract (Asset) in the open market (Source) this year.
• Market research indicates that opening a branch office (Event) in the European market (Source) has potential to increase profits (Asset) next year by 25 percent (Consequence).
• The internet (Source) marketing campaign (Event) is expected to deliver a 30-percent (Consequence) return on equity (Asset) within two years.

The above examples present information in a way that helps facilitate meaningful discussion by creating a shared understanding of what is actually being discussed.

Another great use for CASE
Another great use for CASE is to evaluate someone else's risk assessment by testing the quality of risks identified against the CASE criteria. You'll be able to spot and point out any flawed risk descriptions or shoddy analysis at a speed that will be the envy of your colleagues.

And as for the IT project I mentioned earlier? The proposed "quick risk review" took slightly longer than expected. Before running any more risk review workshops I sat down with a couple of stakeholders to rewrite the risks into about 50 succinct descriptions. Once that was done, the subsequent workshops easily and quickly achieved consensus on risk ratings. The updated treatment plan that resulted from those workshops helped get the project back on track by refocusing on key initiatives and allocating resources where they were needed most. Had we not re-written the risks in CASE format, it is likely that the workshops would have been taken over with debate on the meaning and rating of each risk; with little benefit to the project.