Adequate risk management requires responsibility and response-ability

The other side of the coin

A couple of days ago, I wrote an article on risk acceptance and how it actually requires a lot of work in terms of contingency planning. Of course, there is another side to that coin.

The curse of middle management

What is the scope of your responsibility? How able are you to respond to challenges that come your way? If you are an average middle manager in an average organisation, my guess is: not that wide. Our traditional, hierarchically built, production oriented organisations seldom give any real delegated authority to middle management.

This, by the way, is not the "fault" of senior management. It's likely to be a combination of three key factors:

• The traditional structure of organisations, which are built for industrial production optimization. Industrial production entailed making a lot of the same things at an as low a cost as possible. Hence, the need for middle management (shop floor management) decisions was likely limited to hiring and firing what in the production mentality were replaceable assets (i.e. workers) and how to "organize" the daily work. There was no real need for middle management to be able to respond outside of the framework of a very limited set of parameters. In short, our traditional organisational structures do not promote middle management taking broad responsibilities.
• the traditional training and schooling of our middle management, which, especially in larger organisations, waits and sees before acting. By waiting and seeing, you are limiting your own ability to respond, of course. I'm with Sir Ken Robinson when he states that our current schooling does not respond to the needs of our current environment, but that's another blog post, or perhaps even a book. In short, middle management has not been trained to be assertive in taking responsibility.
• the hierarchical structure itself, which traditionally does not promote (both literally and figuratively) people who take too much initiative and come and ask for formal authorisation later. Traditional hierarchies promote like-minded, hence predictable people. This makes "renewal" less evident. It's interesting to see that this holds even in organisations that proclaim their own innovative approaches, such as major consulting organisations. In short, even if middle management would take the initiative, it would not necessarily be appreciated in most organisations.

Back to risk management

With risk "management" becoming more and more embedded in organisations, it does not pay to make risk management only about risk identification at the middle management layer, with decisions to be taken only at the top management level. If that were to be the purpose, I would propose to automate middle management to the maximum extent possible, as the cost to benefit ratio would never be positive enough to actually keep real people in play.

Middle management, ideally the management layer closest to day-to-day operations, is the management layer which is the most intimately aware of what can go wrong in day-to-day activities. Rather than establishing an elaborate reporting system where all information needs to go to top management for decisions, it would pay to make the middle management responsible and hence able to respond to certain types of risks, without the need to consult (hence bother and pull away from other, more strategic responsibillities) top management.

How to?

This of course all remains rather conceptual. What do we need to do in order to make sure that our middle management has adequate means and abilities to deal with the risks they are being faced with? The solution I propose here is not new. About 10 years ago, Josiane Van Waesberghe and I wrote what would eventually become the MobiRisk methodology, which went on to win the European strategic risk management award in 2009.

In this methodology, we were thinking about how to solve these issues as well. When the main reasons we started to look at this problem is because we noted that quite a few middle managers were unable or unwilling to go beyond the very restrictive scope of their authority in order to deal with problems.

In other words, because they did not feel responsible they were not able to provide an adequate response. And sadly, this has become more the rule rather than the exception. The fear of making a mistake leads people to no longer decide at all. The responsibility for all issues, including operational ones, is being put on the shoulders off top management. But we should never forget that top management was not necessarily selected for its operational competencies. Rather, they are responsible for managing a strategy.
Of course, this digression does not bring us closer to a solution. So let me offer my five cents worth.

One of the solutions that we came up with is to have top management agree on the principles of risk management, and leave actual execution to middle management. That of course requires adequate monitoring. This simple but in my experience rather effective approach gives the ability to response to middle management, while asking top management to make the initial decision on how to deal with this type of problem. This approach recognizes the issues raised above, and deals with them appropriately, but not in an aggressive manner. It is important to recognize that certain sensitivities remain and need to be correctly addressed. It would be an illusion to believe that these deeply embedded, structural issues can be resolved in a couple of days.

Practically

A middle manager discovers a risk, or a real issue, in one of the activities under his responsibility. This risk has never been dealt with before in the organization. He or she knows this because he has consulted the risk reference framework for his organization. The risk reference framework is nothing but a structured repository of answers the organization has developed for risks it has encountered before.

The manager consults with his operational experts and these A proposed solution for the problem. He proposes this solution to top management, which considers not only the solution but the overall impact On the other responsibilities. In case the solution is deemed acceptable, the middle manager gets a go. In case it is not, the remarks are communicated to the middle manager, who goes back to the drawing board.

All accepted solutions are captured in the risk reference framework, where they will remain available for the entire organization.

Consequences

The consequences of this approach are interesting. First it actively involves top management in the decision on how to deal with a specific risk. However, they're not alone in this. They use the experience available in the organization to solve the problem.

On the other hand it enables middle management to take more and more responsibility in the actual day-to-day management of the risk. This is important because it moves them beyond the traditional risk identification towards an approach in which they take real responsibility in order to deal with the problems that they're facing.

This approach recognizes the important role of top management while at the same time ensuring that middle-management plays its core role in the day-to-day management of risks. In order to do that they need to be recognized by top management as being authorized and relevant to do that work.

Risk acceptance requires hard work

Rereading the title of this post, my first reaction is that this is stating the blindingly obvious. The problem is, in reality this is far from that obvious. More than once I've been confronted with situations in which risk acceptance by a manager turned out to become risk ignorance. And risk ignorance is just another way of saying that someone no longer feels responsible for dealing with the risk.

This may come as a shock: any identified risk in your area of responsibility falls under your responsibility, whatever your preferred risk treatment will be. Sadly, that is quite often not the case.

Accepting a risk is not the end of management responsibility

Some managers believe that accepting risks, whether related to issues raised in an internal audit report or identified based on appropriate risk management, is the end of it. By accepting risks, they often feel they can make the demon of having to solve a problem go away. They feel they can sleep soundly ... at least for a while.

Of course, nothing is further from the truth. As I stated above, all identified risks needs to be properly managed. Risk acceptance is a risk management option, but choosing to accept a risk does not imply that risk has gone away or no longer matters to you.

On the contrary, it puts the burden of making sure the organization is adequately prepared to deal with that risk plainly with the responsible manager. After all, as a manager, if you have been informed of an issue and you have accepted the risks related to the issue, you need to be ready to deal with that risk if and when it occurs. That's called contingency planning, and it may actually involve quite a lot more work that you believe it does. Let's examine why this is so very important.

Accepting the risk is not ignoring its potential consequences

Let's illustrate the issue with a concrete example most of us can associate with:

Imagine you are driving a car faster than you are allowed to drive it. Your risk of having an accident will increase. You accept that risk by making the decision to drive faster as well as by the actual act of driving faster. Hence, you have accepted that risk.

Now, does that attitude of risk acceptance allow you to ignore any required contingencies you would normally take, such as having a fire extinguisher in the car and making sure your airbags are functioning correctly? Let's be clear ... it does not.

Whether we are talking about driving a car or managing an organisation, the same principles apply. The fact that you consciously decide to accept an exposure does not free you from the burden of managing the organisation, the entity or the process you are responsible for. To make it crystal clear, risk acceptance assumes that the responsible manager is fully aware of the potential yet very concrete consequences a risk occurrence may have as well as what needs to be done to deal with that contingency. You cannot avoid that responsibility. At all.

In essence, each manager is responsible for exercising the due diligent behavior with respect to the responsibilities that have been delegated to him or her. Correct behavior is then not ignoring a risk you have "accepted", but preparing your organisation for the eventual possibility that the risk may occur. Rather than working on reducing the likelihood of occurrence of a risk, you focus on reducing the impact if it were to occur.

Let's revisit our speeding example. Your car is, or should be, equipped with minimum safety measures, such as a fire extinguisher or airbags. If the risk of an accident were to occur, you will be bruised, but hopefully safer than you would have been without those measures. You will still face a loss, in this case the car or the convenience of driving your own car for a while, but the loss will ideally not be of a completely disruptive nature.

Lack of due diligent behavior requires removal

In the same vein, all managers should regularly review the risks they have accepted and assess whether or not there are measures in place to deal with the potential impact of a mishap. If these measures do not exist, I firmly state that the manager has not shown due diligent behavior. In that case, the board should take all appropriate actions to remove this manager from his or her position.

Practical steps to wider adoption of risk management: simplifying risk models for more frequent use

What went before ...

In the early '00s, the relevance of using risk models was very much disputed. A number of leading companies in the risk management field did not see the reason to use models, as they felt that practice impeded organizations from assessing the entirety of their risks. In the late '90's of the past century, Arthur Andersen was one of the first companies to start structuring risk models as a basis for the structural implementation of enterprise (wide) risk management.

The wider adoption of risk models

Risk models really came to the fore towards the end of the '00s, when experiments in implementing enterprise risk management or ERM systems showed a significant flaw in the prior reasoning: people did not share a mutual understanding of the term 'risk', much less individual risks. They even failed to agree on a common definition for the most traditional of risks.

This was broadly solved by the development of risk models: industry specific structured overviews of potential risks which could occur in companies active in a certain industry, with a clear definition of what the risk means in agreed upon terms. Agreed upon terms would be adapted to company specific terms, in order to limit the risk of misunderstanding and thus mistreatment of a specific risk.

The challenge of today's risk models

But in our quest to increase the transparency and the unified interpretation of risk models, I fear we may have overcomplicated matters. We actually overcomplicated risk models themselves.

Overcomplicating a risk model – or any model for that matter – lowers the adoption rates by its potential users. It's pretty much like using formula in a book, or in a blog post for that matter. It is 'understood' that each formula halves your audience. Risk models are not necessarily different. The more specific the model, the fewer its users.

Therefore, while the move towards a more complex set of risk models was necessary to develop enough detail in the risk models, we now need to make the reverse move. This move should not be towards no risk models, but towards another method of using these risk models. What I have in mind is a list, an overview of possible risks.

The added value of risk management

Let's examine what the actual added value of risk management can be? It is the optimization of our response to priority, identifiable risks if and when they occur. I may be insulting quite a few experts with the following statement, but risk management should NOT be a central pillar of a management system. It adds to better risk response, and can be added to ways in which an organization is run, but should not be the central element.

In essence, even if no management exists, this would not preclude risk management systems to exist across an entity or a group of entities.

An example of simplied risk models in risk management - the case of distributed ad hoc structures

The context of the example

We see the demise of certain (types of) corporations, especially, but not only in the services sector. These mastodont, monolythical structures are being replaced by decentral, distributed networks of independent contractors which come together on a project-by-project basis. This is the context in which I want to develop this short example.

The case for risk management

Given their increased exposure to larger and larger projects, hence larger and larger responsibilities and linked to that larger and larger potential liabilities, perhaps now more than ever, these decentralized networks need risk management, but they inherently do not have a management structure to, well, structure or 'manage' their risk management.

A quick detour - the trigger list in Getting Things Done

So, how do you manage risk in a distributed, decentralized environment, or in any type of environment for that matter, in an as cost-effective way as possible? You develop a risk trigger list for that specific environment or for that specific project they are engaging in.

Actually, this idea is not new. I borrow the central idea from David Allen, who in his excellent book "Getting Things Done" refers to an incompletion trigger list as an essential tool for the brain dump, in essence a way of clearing any issues in your head and getting them on paper, for further processing.

The trigger list is a very powerful tool: it is small enough (David Allen's trigger list, here in its excellent Merlin Mann interpretation covers at most 2 modest pages) to be used on a regular basis and yet complete enough so all elements you may have forgotten can be dealt with. What is even more interesting is that the tool can be used again and again in the same type of environment, and is easily adaptable to other types of environment.

The solution - The Risk trigger list

In order to enhance adoption of risk management as a tool, in order to make it usable on a regular basis and complete enough to deal with most risks one could forget about, I advise to develop a risk trigger list per project, process, organization or even industry. This trigger list, which should not be more than 2 pages long, contains trigger words, words that will result in a comprehensive listing of most of the relevant risks which can occur in that process, project, organization or industry.

You may be surprised. At least per industry, I believe at least 50% of the risks will be the same across organizations. The list will partly be generic, and partly specific to the organization, the process or the project. Developing a risk trigger list should be one of the first responsibilities in any new process or project.

The relevance

By simplifying the comprehensive risk models we've developed in the past 10 years and condensing them into risk trigger lists, we may reach the critical threshold to wider adoption of risk management principles, which will in turn lead to better managed processes, projects, organizations and industries.

Regarding unknown unknowns, hindsight is 20/20

I've been teaching a risk management class at Solvay Brussels School (SBS) this week. Teaching these classes always brings home to me how much I love to teach. The exchange, the pace, the ideas ... as long as it stays concrete, I really feel as if I'm contributing and learning at the same time, even in my role as the lecturer.

I've been lucky to once again find myself with a wonderful group of enthousiastic, intelligent people in the room that are excited to discuss the practical aspects of risk management implementations. Away from just theoretical concepts, away from high level consulting lingo which does not contribute any real added value. Just focusing on how to make it work. Practical risk management, in other words.

One of the aspects we touch on when discussing the practicalities of risk event identification is the aspect of unknown unknowns. These are, very simply put, the risks we never saw coming. While they only represent a minority of all risks, they usually wreak havoc on your activities and its related operational and strategic objectives, because you quite often have not built any risk mitigating measures to deal with them.

"He saw it coming, he only had himself to blame"

During the discussion, we agreed that hindsight on unknown unknowns is almost always 20/20. It's relatively easy to look back and 'see it coming', with all the information transparantly available to you. However, looking forward, you don't have that luxury.

Making an unknown unknown

So let's consider what makes an unknown unknown so hard or even impossible to know? I consider the following three elements to be among the determining elements of an unknown unknown.

Aspect 1 - Time to onset

Some unknown unknowns move very fast. The time you have between the first moment you could have theoretically identified the risk and the actually occurrence of the risk event, i.e. after it would have blown through all your measures aimed at reducing the likelihood of occurrence, is very short. This "time to onset" determines whether it is at all feasible to start up any risk mitigation activities.

If you want to visualize this, think Wiley Coyote hanging over the abyss with a text balloon over his head saying 'oh darn' ... these are the moments you know the worst is yet to come, and that you do not have anywhere close to adequate time left to handle the issue.

Aspect 2 - Available expertise

Looking back with the required expertise is easy. After all, you know what has happened and you bring in the experts to expound on why this happened and how it could have been avoided. Network TV is often especially strong at this, in cases where the resulting exposure to the risk is big enough to put egg on a lot of faces.

However, the likelihood you have the expertise available to examine every possible risk before any such risk occurs is unlikely. Expertise is expensive, and especially if a risk is in the perifery of your activities, it is possible you never had access to the required expertise to begin with.

This really becomes a problem if the expertise is available in your organization, but silo mentality and the lack of communication across organizational or hierarchical chasms has prevented the both of you from talking to each other.

In essence, the reality is that you will never have all the expertise required to assess all possible theoretical eventualities.

Aspect 3 - Required width and depth

But even if you were to have access to all expertise required, unknown unknowns are still very much a reality you will have to deal with. You simply cannot keep your eye on everything all the time. In essence, an unknown unknown risk event has to get lucky once. You, on the contrary, need to be lucky all the time.

In conclusion

Monday morning quarterbacking gives a lot of people a feeling of control. I believe a lot of that is psychological. It is very hard to admit to ourselves that there are things we will never see coming, and those are the risk events that often hit us hardest.

For us, as a human species, as a result of our nature, it is a lot less scary to create that false sense of security that it is a personal or structural failing rather than a fact of life that sometimes the comet is real, and sometimes it is heading for us with nothing we can do about it ... without us even knowing about it.

Is goal management in a public sector environment relevant?

Just finished a discussion with a friend on whether it's possible to do goal management in a public sector environment. But before we go into that, perhaps I need to define a goal first.

Defining a goal

A goal in a public sector context is, in my book, the object of your efforts, the aim, the desired result. A public organisation strives towards goals which are an operational translation of either the laws and regulations they are bound to uphold or of a strategic intent a minister has defined in a formal or informal set of policy objectives.

Managing goals

Hence, can you manage goals? I don't think so. You define goals at the start of your journey. You may re-evaluate the feasibility of your goals during your journey, when you become more aware of the capabilities of the team aiming to achieve these goals. What you should not do is "manage" these goals.

What management entails

When you are managing something, such as for example a risk, you are "using" your resources to optimize your exposure to risk. You are in effect changing the way in which you behave towards that risk in order to allow you to reach your objectives.

Herein lies the difference: your attitude towards risk changes throughout your journey towards your goals. You adapt your organisation (your people, your processes, your systems) to make sure the organisation reaches these goals.

Goals of a public sector organisation are not dynamic

The goals, on the contrary, are not dynamic. They are clearly defined at the outset. Imagine for a moment that we had the liberty to change goals. Reaching a goal which can be adapted becomes very easy, because you are in charge of what is defined as the goal. Flying to the moon becomes flying around the earth becomes reaching orbit becomes reaching space becomes building a functional prototype of a rocket ...

A concrete and SMART goal should be cast in stone for a public sector organisation. If it is not, it means it was either a bad translation of a law, a regulation or a policy objective or it was not adequately concrete to begin with.

The relevance of the strategic cells

Either way, the lack of specificity means that a lot of public means were lost in the process of making sure the administration is doing the right thing.

This is why the concept of the strategic cells under the Belgian federal Copernicus restructuring were so right: the strategic cells were charged with making sure the administration was doing the right thing. The administration needed to take care it was doing the things it was doing in the best possible way. And the ideal tool for that mission is risk management.

Just managing your risk impacts is rarely a good idea

Risk impact management complements risk exposure management

Managing risk impacts is a common practice among risk practitioners. It is a recognized approach which, if used well, complements actions aimed at reducing the likelihood of occurrence of a risk. What is more disconcerting is finding out that risk impact management is all that is being done to manage risks.

Managing impacts is often easier than predicting occurrences

Quite often, managing impacts is the easier of the approaches. After all, managing the likelihood of occurrence requires us to consider, identify and establish controls related to risk root causes, in order to avoid risk occurrences to the best of our abilities. It truly requires the organisation to develop an in-depth understanding of the underlying dynamics of a risk. Given that risk management is not an easy subject to begin with, an upfront investment in deep risk analysis is quite often a hard sell in a lot of organisations.
To make the comparison to a common household situation: It's far easier to have a band-aid ready than to take the time and educate your kids on the dangers of running around with scissors.

The erroneous assumption of risk impact management

There is, however, an erroneous and potentially quite lethal assumption underlying this relaxed primary focus on risk impact management. That assumption is that the anticipated impact will likely fall within a manageable bracket.

When we are managing the impact of a risk, the implicit assumption is that the management of the risk impact will immediately avoid any knock-on effects. Such an approach assumes you can predict the range of outcomes of the risk event occurrence as well as the speed and depth of knock-on effects with reasonable certainty.

Risks are the consequences of the assumptions we make

By this definition, your reliance on what may be faulty assumptions is inherently risky, and should be managed as well. Not only should you take in account that you need to manage not only the risk you want to manage, but all potential downstream risks as well. Let's examine in a bit more detail why this is relevant.

1. You may not be able to predict the impact of the event on downstream risks accurately: imagine you are managing the impact of a risk. Unless you can reduce the impact to a low enough level, the risk event may cause downstream, related risks to occur, hence creating a cascading effect. If you have no controls in place, you may have a significant problem even with your risk impact mitigation controls in place;
2. You may not be able to predict the onset of the impact accurately: your risk mitigation actions are likely to be slightly delayed. Take a fire, for example. Before the smoke detectors go off, you already have a fire. Even if the fire extinguishers will go off, you will have some damage. This may be less relevant if the damage is to some replaceable asset, but it may be a disaster if for example you are protecting art;
3. You may not have thought through the entire set of risks impacted downstream: your risk impact mitigation strategy should ideally extend to the risks directly downstream from the risk you are trying to manage. But what if you are not quite sure which risks will be impacted? What if you fail to identify a downstream risk that sets in motion a catastrophic set of events?

Conclusion

Sole reliance on risk impact mitigation activities may create a feeling of security that is not at all waranted. It pays to invest in carefully examining the interrelationships existing between the different risks in your risk universe, how they influence one another as well as the speed with which they can influence each other. In the back of your mind should be what is most mission critical to you, as this is what you would mainly be aiming to protect. Developing risk occurrence mitigation strategies for all risks impacting your mission critical elements is a wise decision for any risk manager.

Why sum formulas better reflect the risk appetite in calculating risk levels

How to determine a risk profile and calculate a level of risk?

Introduction

This is a significant rewrite and a first time write-up in English of an article I published in Dutch in May of 2009. I'm revisiting it because I had an interesting exchange with my ERM class at Solvay Brussels School last week, where we discussed the issues related to risk calculations.

As is always the case in this area of risk management, there will be both proponents of the approach and people contesting it. For me, a large part of the value of these posts is in the discussion that follows. For that, I refer to the ERM group on Linked-In, where I will post a link to this post.

Finally, I understand that the number of readers of a post halves with each formula you put into an article. This may actually mean I will be the only one reading this one to the end.

The controversy

Risk analysis tasks you with "measuring" risks. To date, we most often use qualitative information. There are a couple of reasons for that.

First, quantitative information is most often not readily available in sectors other than banking or insurance. Even if it were available, it can cloud rather than clarify the issue. Look for example at risk management failures in the banking sector over the past years.

So, we start with qualitative information. My implicit assumption here is that definitions of scales are agreed upon with all evaluators and are consistently applied in the evaluations. Everyone evaluating should be very clear about what "high", "medium" or "low" risk actually means.

In some cases, simple scoring along the axes of probability of occurrence and impact on objectives is not enough. Some analysis requires a roll-up from these "traditional" scores for impact and probability of occurrence to a single dimension, which we will refer to here as the "risk level".

Now, most of us, risk management nerds, agree that the risk level is a function of impact and probability. However, the controversy starts right after. Traditional risk management usually uses a product formula to calculate the level of risk:

Level of risk = I(mpact) x P(robability) = I x P

The problem with this approach becomes apparent pretty quickly. Risk related events with a high impact and low probability are scored in a similar manner to risk related events with a low impact and a high probability. The assumption these events are comparable in "risk level weight" is an unfounded assumption. Let me give you a concrete example:

The likely low impact even of a fly hitting your vehicle has an overall lesser level of risk than the luckily unlikely high impact event of a deer hitting your vehicle.

However, traditional risk management will yield a same risk level for a event with P=6/6 and I=1/6 as for an event with P=1/6 and I=6/6. Both are valued at 6.

See the problem? Right. Now, what can we do about it?

Alternatives to the product formula

Using a sum formula rather than a product formula allows us to attach a numeric weight to the dimensions impact on objectives (which we'll call impact or I) and probability of occurrence within a certain time frame (which I will refer to as probability or P). This weight is a function of the relative importance of impact and probability to the organisation where we are performing the risk analysis.

How does that work? Well, depending on your risk appetite as an organisation, you can give more weight to one dimension over another, which allows you to tweak the risk analysis to the risk profile of your organisation. This is where product formulas fall short. They cannot be used to integrate this aspect:

W x (I x P) = (W x I) x P. However, W x (I+P) does NOT equal (W x I) + P

You could rightly remark that weighting in the product formula can be realised when applying exponential values to the dimensions. However, it's exactly that exponential nature that will quickly reduce the relevance and weight of the not-weighted dimension to virtually nothing as compared to the weighted dimension. Hence, it makes little sense to take the non-weighted parameter in account. But as it is valued, we do need to take in account the scores that have been attributed to that dimension for the different risks evaluated.

In short, applying a sum formula to calculate the risk level ensures a more transparent calculation which allows the management to better reflect their risk appetite … provided the dimensions are weighted in a manner that reflects the risk appetite of the organisation.

But what do these weights mean?

Weights are applied to a dimension to give that dimension more importance in the calculation of the risk level of the specific risk. If the risk appetite calls for the avoidance of high impact events, impact will be weighted heavier than probability. If we want to reduce the probability of event occurrence, we will put more weight on probability.

There is some, but not a perfect, correlation between impact preferences and organisations with a preference for proactively managing the consequences of risks and probability preferences and organisations with a preference for proactively managing the sources of risks. That however is the subject of another blog post.

If we let W be the weight factor, we can distinguish three different profiles, which depending on the value of X can be more or less extreme.

impact oriented profile

This profile weighs impact as more important than probability of occurrence. This organisation will prefer to work on high impact risks with less attention given to the probability factor. Coverage of frequently occurring, low impact risks, such as clerical errors, is less important.

The risk level calculation is RL = (W x I) + P) / (W + 1)

probability oriented profile

This profile weighs probability of occurrence as more important than impact. The organisation wants to avoid the frequently occurring risks, but sacrifices coverage of high impact, lower probability risks.

The risk level calculation is RL = (I + (W x P)) / (W + 1)

indifferent profile

This profile does not weight probability or impact. Risks with high impact and low probability are treated in the same manner as risks with low impact and high probability.

The risk level calculation is RL = (I + P) / 2

Who gets to determine these weights?

Well, management does. It's there responsibility to determine weights as these represent the risk profile of the organisation. They need to translate the mission and vision into a strategy which is supported by a risk profile. That decision is theirs and theirs alone.

An example

Let's assume we have two situations for which the impact and probability of occurrence have been established. Let's further assume that the impact score for the first situation equals the probability score for the second, and the probability score for the first situation equals the impact score for the second. The traditional calculations using the product formulas will of course show these risks to be at an equal risk level to one another.

Let's further assume that the weighting factor applied will be W = 2. In essence, the parameter it will be applied to will be considered to be twice as important than the other parameter. In this case, we chose for an environment which values impacts more than probability of occurrence, as stated with a factor of 2.

Let's finally assume that the evaluation of each dimension is done on a five point scale and that the final risk level score needs to be normalised to a five point scale.

• Situation 1 is a collusion between a responsible and a supplier to perpetrate a fraud damaging the organisation.
• Situation 2 is a clerical error in the administrative registration of a demand for a service of that same organisation.

We first perform the calculations to get a non-normalised result, which then needs to be brought back to a score on an axis from 1 to 5. We then normalise to a five point scale.

Evaluation of situation 1

the weighted product formula yields: (2 x I) x P = (2 x 5) x 1 = 10

the non weighted product formula yields: I x P = 5 x 1 = 5

The weighted sum formula yields: (2 x I) + P = (2 x 5) + 1 = 11

the non weighted sum formula yields: I + P = 5 + 1 = 6

Evaluation of situation 2

the weighted product formula yields: (2 x I) x P = (2 x 1) x 5 = 10

the non weighted product formula yields: I x P = 1 x 5 = 5

The weighted sum formula yields: (2 x I) + P = (2 x 1) + 5 = 7

the non weighted sum formula yields: I + P = 1 + 5 = 6

Normalisation

As all risk scores need to be brought back to a five point scale, we need to perform a "normalisation", which is just a fancy way of saying we are bringing the score back to a reference scale. Depending on the formula used, the normalization calculation is different.

For the product formula, we divide by the maximum possible score (normalisation to 1) which we then multiply by the maximum value on the scale, in this case 5. This leads to:

2 x Imax x Pmax / 5 = 2 x 5 x 5 / 5 = 50 / 5 = 10

In other words, the normalized risk level for situation 1 becomes:

• for the weighted calculation: 10 / 10 = 1
• for the non-weighted calculation: 5 / 10 = 0,5

The normalized risk level for situation 2 becomes:

• for the weighted calculation: 10 / 10 = 1
• for the non-weighted calculation: 5 / 10 = 0,5

For the sum formula, we divide by (W + 1), where W is the weight given to the dominant dimension. This yields the following normalized results for situation 1:

• for the weighted calculation: 11 / 3 = 3,66
• for the non-weighted calculation: 6 / 3 = 2

For situation 2, this becomes:

• for the weighted calculation: 7 / 3 = 2,33
• for the non-weighted calculation: 6 / 3 = 2

In other words, where the product formula fails to distinguish the two very different risk events, the sum formula distinguishes the risk events and considers the risk with the higher impact as of a higher priority.

The example demonstrates the sum formula better answers the needs of management to reflect its risk appetite in the calculated risk level of individual risks.

Embedding risk management in the strategy cycle

As of its inception, there have been a lot of comments on COSO-ERM and how it can be applied in practice in an organizational setting. Those of you, dear reader, who have followed this blog know I am not an avid fan of the framework. However, contrary to some experts I don't agree the authors made an error when introducing risk appetite as a concept as early in the ERM cycle as they have.

Understanding risk appetite

Dr. Larry Rittenberg (Ernst & Young) and Frank Martens (PwC) authored a short(ish) document on understanding and communicating risk appetite, which was published by COSO in January of 2012. It aimed to present a set of answers to the unclarity surrounding the concept of risk appetite as it was introduced in COSO-ERM:2004. In its executive summary, they clearly state that:

"Risk appetite is the amount of risk, on a broad level, an organization is willing to accept in pursuit of value. Each organization pursues various objectives to add value and should broadly understand the risk it is will to undertake in doing so."

In defining risk appetite in this way, they aim to get ERM out of the compliance corner it has been painted in for a long time. It elevates risk management above the level of a mere tool or requirement and positions it where it should be and informally often already is: an integral part of the strategy process.

Risk appetite as a key element in strategy setting

A strategy can be defined as it is in venerable Wikipedia as follows:

"A plan of action designed to achieve a vision. Strategy is all about gaining (or being prepared to gain) a position of advantage over adversaries or best exploiting emerging possibilities. As there is always an element of uncertainty about future, strategy is more about a set of options ("strategic choices") than a fixed plan."

Hence, reading this again, the key risk element, the uncertainty element, is an inherent part of the definition of a strategy. A lack of awareness of what, in broad terms, this risk may be and to what extent it would be acceptable for the organization to be confronted with it, is required to develop the action plan. Hence, risk and especially risk appetite drives strategy.
In my personal opinion, the authors did not adequately emphasize this.

An illustrative example

Imagine that your organization, for the sake of argument a non-profit organization, is offered the opportunity to start activities in an area which in content is adjacent to what the core purpose of the organization is. Imagine the organization is about assisting the development of civil society in fragile states, and the area you are invited into would like you to work in post-conflict issue resolution between two tribes. There are some elements of uncertainty here.
However, the geographic area and its culture is completely unknown to your organization. There is no prior experience here. Hence, there are quite a few elements of uncertainty here.
Without a clear view on the risk appetite of the organization as compared to the potential risk exposure the organization may encounter, it is virtually impossible to develop a relevant strategy.

Conclusion

COSO-ERM is far from perfect. However, in light of some of the, already old, comments on the risk appetite, I believe it to be essential to consider risk and risk appetite, even in the broadest of terms, during strategy setting.

Fear is good - continuing the Kaplan conversation

Fear is Good

Remember the Gordon Gecko character in Oliver Stone’s landmark “Wall Street”? His credo was “Greed is Good”.
I want to offer that “Fear is Good”. Fear has helped us surviving as humans, and fear - or its relevant equivalent - can make a survival difference for organizations as well, if we get it to function correctly.

Fear is an important survival mechanisms

It’s how we as humans got here, where we are today, on top of the food chain. Let’s be clear, we did not get to be where we are by being heroic and standing up to a hunting lion or tiger as a small ape-like being. That would have gotten us eaten.

On the contrary, our entire human system has been geared towards survival, avoiding the fast(er) predators with sharp teeth on the savannah. What guided us then is still guiding us now, even though most of us have moved away from the savannah. These are our evolutionary retained, succesfull reactions, which through the mechanism of evolution were programmed into our very being. The most important part of our brain involved in those reactions is the amygdala, one of the older parts of our brain.

The amygdala has recently been put in a bad light as it is often blamed for preventing us from exhibiting risk taking behaviour. And risk taking behaviour is often linked to innovation. So, according to some great thinkers, amongst which Steven Pressfield, this built-in reaction prevents us from achieving greatness. That’s the result from hunderds of thousands of years keeping our heads lower than the surrounding tall grass.

Now, in cases where the amygdala fails to function properly, imagination appears disfunctional and fear is often notably absent. But that feat is what prevents us from getting killed. Hence, this part of our brains is a very effective risk management engine, continuously identifying, assessing, prioritizing and treating risk. And it errs on the side of caution. And it never needed reading ISO 31000 or COSO-ERM. Risk averse behavior has evolved and has aided us our survival.

The fear dynamic

Fear uses our imagination and our emotions, and emotions are, at least partly, governed by the amygdala. Fear provides our imagination with cues as to possible consequences of certain risks. We can visualize them, but we in case of strong emotional links to fear experiences, we do more, we “live” them.

The link between emotion, fear and risk aversion is often very hard and very confrontational. Hence the intensely emotional reactions to 9-11, or to the recent bus accident in Sienne, Switserland, in which 22 children lost their lives. It’s a combination of proximity and direct relevance for us which creates a deeply emotional reaction, leading to fear. To illustrate, I know quite a few people who no longer felt safe in tall buildings. I also did not feel happy about putting my own children on a bus days after the Sienne accident.

The possible consequences of this imagined risk manifest themselves in imagined pain or loss which in turn leads to an overall activation of all key survival systems and the related de-prioritization of all other activities. Again, this is not a considered reaction. No, it’s an automatic, intuitive reaction, powered mainly by the amygdala but rationalized ex post by our brain on the basis of fear. It’s not perfect risk management either, as you get the tendency to prioritize the recent and close risks to the more distant risks in time and space. But that’s a subject for another post.

Organizations lack brains and imagination

All of this puts us in a bit of a hard place. Organizations do not have brains, so they don’t have an amygdala. In addition, they don’t have imagination. So pretty much all requirements for effective risk management are not present in organizations. Hence organizations have no inherently present systems for risk identification, assessment, prioritization and treatment.
Organizations exhibit no fear. But is that entirely true?

Organizations have lots of brains and imagination

While organizations themselves have no brains, nor imagination, they are made up of - and actually by - people. Lots of people bring lots of brains and imagination to organizations. They also bring lots of fear. But this is not enough to make organizations act like good risk managing environments. What is required is the deep identification, a deep link between the individuals and the organization. And that, exactly that, is what we are moving away from. And that’s a problem.

Long term self preservation

Let’s look at mechanisms of basic self-preservation and their scope. Our survival reflex extends beyond our own body, our own life. It also extends to our children and to our children’s children. After all, they are a genetic mix of ourselves and our significant other. Our genes literally live on in our children. Self-protection and structural preservation of our (genetic) heritage result in risk averse behavior.

This is all good, but there is no (longer) such self-identification with the organizations we work for. Rather, people tend to treat work more and more as an obligation, and no longer own, care for and manage the risks inherent in their responsibilities. Because of this lack of identification, fear does not enter into consideration when executing a responsibility. And that is problematic.

I’m wondering whether an important part of this disassociation with the employer has not been the latest result of the permanent reengineering and down-sizing or right-sizing drive of the ’90s and early ’00s.

Fewer and fewer people are willing to truly commit to the organizations they work for. Because their organizations do not commit to them.

The parent-child relationship between employer and employee is broken

The parent-child relationship is not a wrong way of illustrating the employer-employee relationship. Employees often come to an organization with the full engagement and commitment to really make a difference. Some organizations allow and even support that. A beautiful example is this welcome message new Apple employees get on their first day.

However, more and more organizations, due to free rider behaviour of some shareholders and some members of management fail to honor that commitment of their collaborators. Which leads to loss of engagement, loss of identification and loss of true risk management capability.

Organizational fear lives with those accountable

Because, and this is essential to understand, any fear reaction exhibited by an organization is the manifestation of a risk averse reaction by its accountable collaborators. Hence, any lack thereof means there is no risk averse reaction by its accountable collaborators.

The accountable collaborators may have lost their link, their identification with the organization. They may no longer consider themselves accountable. Worse, they may start to exhibit free rider behavior themselves, often a corruption and fraud indicator or precursor. Rather than protecting the organization from exposure, they may point it on a road to higher and higher exposures which result in big upside risks for themselves and long term, almost certain downside risks for the rest of the organization.

So what’s next

I hope I’ve gotten everyone depressed enough.
The key question then is, is it worth considering risk management in organizations? I believe it is, I believe it is essential for long term survival, but I believe it will require a significant adaptation to traditional organizational structures.
I don’t think it needs to be the end of large corporations, but it will require a decentralization of power and management structures to make organizations more nimble and, let’s face it, more personal. People need to be able to identify with their organization to be able to exhibit good and relevant risk responses. So how do we do that? That’s fodder for another blog post.

A reaction to "Kaplan's heresy"

I just found this very interesting blog post on the blog of Peter Bonisch. You can find the post here and I suggest you read the post in full.

I’ve reacted to this post with my own thoughts on the subject matter. You can find my reply below.

---

Hi Peter, Mike, Matthew,

Just wanted to jump into this quite interesting discussion. First, when I read heresy, I hear “against dogma”. Now, let’s be clear that dogmatic behaviour is not good under most circumstances. Especially in developing areas such as risk management, which Matthew called the new Wild West only a few years ago (Matthew, I’m paraphrasing, but I really liked the snake oil salesmen reference you made ;-)) we need to make sure that we don’t hold on to dogma’s that are unproven.

However, and this is important as well, what I feel that Kaplan fails to address is the error in expectations we all appear to have with respect to risk management. While not by far the perfect risk management approach, we need to look beyond the limitations of ISO 31000 and look at what it does bring to the table. However, it’s easy to dismiss an approach based on the problems perceived by the experts, while within certain limitations COSO ERM, ISO 31000, AS/NZS 4360 assist in developing a better and better view on what good risk management should be.

Compare this to physics, for example. Any theory which explains even part of what we see and internally and externally shows consistency is considered as a valuable addition to the overall body of knowledge. It explains perhaps only part of the issue, but at least it does that. It may be wrong but it will give us a basis to sharpen our insights. The steady state theory, for example, even while mainly wrong, has significantly contributed to our understanding of how elements were created in the early universe.

This being said, I believe that COSO ERM, ISO 31000 and other risk management approaches will gradually make way for newer approaches that build on the lessons learned from these approaches. Pretty much like Sarbanes-Oxley showed us what not to do to avoid future Enrons or Worldcoms.

Just kicking them to the curb as irrelevant is an easy and even cheap trick which is unworthy of an academic heavyweight such as Kaplan. He certainly has a number of points where he makes a case, but he should look at how each of the current frameworks contributes and how it can be adapted, amended or even completely turned around to be used for the better of risk management.

For the record, I am a reformed list-maker. I don’t agree that ISO 31000 is all about making lists. For me, and how I teach it, it is more about an awareness that there are issues we know, issues we are aware of and issues we are completely unaware of. And that communication and consultation, in whichever form is relevant for your organization (cfr. some of Matthews excellent surveys, by the way) is a key factor in truly treating risk.

That said, we still like to use our little checklists to make sure we have not forgotten anything. They are no longer risk models, they are just simple risk checklists. By ‘relegating’ them from model to checklist we aim to clarify to the users they are merely one of a set of tools we use to assist them in thinking about and discussing risk on a regular basis.

[…]

Stakeholder consultation in risk management

One of the elements COSO-ERM does not thoroughly address is stakeholder consultation in risk management. Sure, there is the required communication capping stone on top of the COSO pyramid, but the activities described therein fails to adequately address the needs and complexity of interacting with your stakeholders on a regular basis in the context of risk management.
ISO 31000, born out of the ISO practices of often and frequent consultations, does not fail to address it. Consultatin is a part of the quality cycles. Inspired by AS/NZS 4360, it gives consultation and communication a key position in the entire process. Just look at this visualization.

But how would you go about consulting your stakeholders in the risk management process? And more importantly, what can they contribute to your risk management?

Stakeholders as sources for the unknown unknowns

As Donald Rumsfeld put it, the most challenging elements in any situation are the so called unknown unknowns. The problems we aren’t even aware of we have. The exposure we don’t know exist. It was an unknown unknown that made Challenger explode, that sunk the Titanic … And it’s likely to be an unknown unknown which will result in you failing to reach your objectives. More on that in another post.
However, stakeholders a great sources for unknown unknowns. Because they look at our activities, operations, actions from a different vantage point, because they come to the table with different objectives, they often see issues where we see none.

Any organization which fails to recognize that it needs to comply with or at least listen to and validate concerns of an important stakeholder, fails to understand that this stakeholder, through his actions or inactions, can revoke its license to operate, killing any chance of the organization reaching its objectives. For those familiar with history, the initial “hearts and minds” strategy the United States followed in Vietnam was a recognition of this essential element. Without support from the villages and villagers, the conflict was bound to go against the US. The abandonment of this strategy influenced the outcome, as there was no longer an implicit license to operate. (the matter is mo complex, but this was an important contributing factor)

Gathering the information

Gathering the information is as simple as asking the question. Asking the question is however not the challenge. What is the challenge is creating an initial environment of trust where stakeholders do not feel exploited of used for the greater good of the organization which may adversely affect their lives. So you will need to establish real trust. And establishing real trust takes time. You cannot buy that trust, you need to earn it. Which basically means that you can throw any ideas of window dressing out of the, well, window.
I believe that an important step to building real trust can be achieved by transparent information sharing. Communication needs to precede consultation, as it builds rapport and it shows the intent to share. You want the information, you need to initiate, you need to cross the bridge first.
What I would not share upfront is the risk analysis conducted inside of the organization. Not because you don’t want to share that information, but rather to avoid influencing the risks identified by the stakeholders. After all, just like you, they can be influenced in their view on the subject matter. Better to get their information without prior contamination.

First open, then closed questions

The stakeholder risk identification needs to be as broad as possible. Remember, we’re mainly looking for the unknown unknowns.
I would start off with interviews which aim to identify their objectives with respect to the organization (remember, no risks without objectives) and the threats they see to these objectives, as well as the current confidence they have in the organizations ability to deal with these issues and achieve the objectives.
A number of risks will likely be similar. Another set of risks will new. As in a traditional ISO 31000 approach, you need to not only identify, but analyze and then assess these newly identified risks. D’uring the first or if necessary a second open interview, each of the risks needs to be revisited for further clarification. We try to ensure we clearly understand how the stakeholder perceives the risk. In a second or third interview, or by means of an online voting approach, the risks are then evaluated (current level of risk management, probability of occurrence, consequences).

Visualization, interpretation and treatment

As to visualization, a good visual representation of an analysis, if it is done in an objective manner, provides a good basis for discussion. I would use different colors to look at different scoring of the same risk. This will take some time to develop (although you could probably automate it) but discussing a clean visualization brings a lot more to the conversation than a cluttered whole.

First, you are likely to find risks which score can be compared to the scoring by the organization. This can be interpreted as a validation of the internal risk assessment.
Second, you will find risks which were not identified in the internal assessment. These risks need to be reassessed by the internal responsibles. If they turn out to be considered to be a real risk, they need to be included in the risk assessment (risk update) and treated.
Third, in case their scores are significantly different from the internal assessments, there is at least an interpretation difference, which needs to be managed.

Let’s imagine for a minute a situation in which the organization fails to deal with a risk it considers minor, but the stakeholder considers very important. If the stakeholder is not adequately recognized in his concerns and the time is invested in explaining why the risk treatment is done the way it is, this may lead to stakeholder protests and eventually the revocation of the license to operate.

Throughout the entire risk analysis there needs to be a continuous communication with the relevant stakeholders. Failing to do this properly may create the most significant threat to the achievement of organizational objectives ever.

Let's talk about risk

The importance of consultation and communication in risk management

ISO 31000 refers to consultation and communication with stakeholders as a key activity in a well implemented risk management methodology. Let’s examine why these elements are important.

The elements

ISO talks about consultation and communication with stakeholders. So we need to explain why:

• consultation
• communication
• stakeholders

are important. We’ll start with the whom, then discuss the two interactions.

Stakeholders

“A stakeholder is a person with an interest or a concern in something, especially a business.”

A stakeholder is therefore influenced by the objectives of an organization and whether or not it achieves these objectives. Note I’m not saying that every stakeholder is necessarily aiming for the organization to reach (all of its) objectives. On the contrary, a stakeholder may be defined as a stakeholder because his or her interest runs counter to the objectives of the organization.
Not recaptured in the definition is that stakeholders have many means at their disposal to influence whether or not and how or at what price an organization can reach its objectives. A voter, for example, may have interests aligned with a political party. If that party does not achieve its stated objectives, it’s entirely possible the voter will take his or her vote elsewhere, and impede the party from realizing all its objectives.
A political party and its voters are relevant as an example of the diversity of stakeholder interests in another sense as well. A political party has a programme, often a concensus of the diverse needs of its intended voters and its political objectives. Not every voter is as interested in the party achieving the entirety of its programme. On the contrary, quite often there may well be conflicting interests within a party programme. It all depends on the weight of the stakeholders in the decision making process.
Lastly, note that not all stakeholders are external to an organization. Your employees are stakeholders as well. And believe me that you should not automatically assume that they are aligned with each and every aspect of your strategic intent. Because they are not.
Let’s be clear, stakeholders are a force to be reconned with. I’ll come back to that later.

Consultation

“the action or process of formally consulting or discussing”

When we’re defining consulation, we need to define the verb “to consult”.

“have discussions or confer with (someone), typically before undertaking a course of action”

Consultation is all about exchanging information and ideas with someone, preferrably an expert or a party involved and with a particular view on an aspect of what you’re dealing with, prior to an action.
Lots of issues or problems or elements on the road to achieving objectives benefit from being examined from different angles. I’m not suggesting to adopt an overly committee like approach where decisions are postponed and killed in committee. However, quite often problems are only looked at from an extremely narrow point of view. This ivory tower mentality has led to significant mistakes in decision making because certain aspects of a problem where never recognized as such.
In programming, there is a dictum that states “Given enough eyeballs, all bugs are shallow” (Eric Raymond). The same goes for issue management. If enough people involved in the problem look at it from their particular point of view, bringing together all these elements will result in a best possible view on the issue.
However, there is a difficulty with this approach: sometimes the time between potential risk detection and that risk becoming a reality is too short to allow for a full consultation. It pays to have a consultation group of stakeholders with different points of view at the ready to allow for quick consultation.

At BTC, we established a consultation committee on integrity. Representatives from all divisions of the organisation gather on a regular basis to discuss integrity related issues and advice my team on how to approach certain integrity related issues. As stakeholders, they have an expertise which my team members, acting as the integrity bureau, does not necessarily have. This committee can be called together on short notice to discuss concrete issues.

Through consultation, you bring to bear all competence within the stakeholder group on a specific problem you are being faced with. You recognize the value these stakeholders have to you, and by doing that, you recognize their value.
However, and that is essential, by no means to you transfer responsibility or accountability for the decisions taken to deal with issues, problems or risks. That remains the sole responsibility of the organization.

Communication

“the imparting or exchanging of information or news”

Consultation is not enough. In consultation, you gather additional perceptions and information to make better decisions. Once those decisions are taken you need to communicate to all stakeholders. In essence, you want to communicate:

• What: you decribe what the outcome of the consultations and the integration of the information learned into the decision making process;
• Why: you describe, wherever possible and not counter to any commercial objectives, why you’ve decided to do what you do;
• How: to those impacted, you explain how the what will be realized. What can they expect to happen to them or around them in what timeframe;
• Outcome and corrections: once a decision is implemented, it leads (hopefully) to results. These results need to be communicated as well. Based on the outcomes, certain corrections may be chosen. These and their impact and the what, why and how need to be communicated as well.

Bringing it together

One well placed, misinformed stakeholder can bring an entire strategy down.
When dealing with any time of activity of an organization, enhanced stakeholder involvement is important to gain perspective but also to develop acceptance of actions that need to be taken. Inviting your stakeholders to the dance is an important means of gathering the necessary support for implementation or of timely identifying key blocking factors.
When dealing with risks and risk management, this need is amplified. After all, you are investing time and means in avoiding the occurrence of certain situations. But just as with Y2K, a risk avoided is something that did not happen. Clearly involving your stakeholders to get a realistic view on the issues and gathering ideas to deal with the issues in the most effective way possible is a sound business tactic. Moreover, it shows diligence where diligence is due.
By making communication and consultation with stakeholders one of the first elements of risk management, ISO has clearly stated that no risk management approach can be successful without the proper support of the relevant stakeholders.

User centric risk management design

I’ve been giving the practice and best approach of managing risks a lot of thought lately, and I’m seriously wondering whether or not we’re not trying to solve the wrong problem when trying to install risk management systems in the way we’ve been going about it in the past 20 years.

The wrong problem

Past and current thinking on risk management implementation goes something like this:

1. There are risks out there;
2. Some of these risks may impact my operations;
3. But I don’t know which ones and what their relative importance is;
4. So I need to find a way to identify them;
5. And evaluate them and rank or prioritize them;
6. In order for me to allow for best resource allocation to solve the issues;
7. Or at least as many as my funds available for risk mitigation will allow.

And so we impose a risk identification framework on our organization. There is however, one problem. An organization is a complex structure of people which all have their own, very unique view of reality and the risks this reality entails. Hence, the exercise just became a lot more complicated.

Resistance is futile

As decree up on high, risk management will be implemented. So people go about it just like they go about implementing any other decreed new system. They go through the motions but don’t really “get” the system or its added value. Case in point: most human resource systems are, when considered from a technical point of view, very well thought out and could, if used correctly, really add some value. However, people just go through the motions and don’t really get all the value out of the systems. In addition, systems are used in error and timing or even content is not optimal for its intended purpose. In this way, assessments are not based on pre-discussed metrics or don’t find their way in time to the management table where they could have a significant impact on a promotion decision … Because systems are not used well, their added value does not come to the fore and we end up not using or supporting them to the best extent possible. And the systems die a slow death. It may be the same with risk management implementations. They are issue centric, but not user centric. And given that the real added value comes from making the user realize his or her real exposures, it may be that we’re really approaching this the wrong way.

The alternative: user centric risk management systems design

What a mouth full! But what it really comes down to is this: we need to make sure that the risk management systems we implement are usable from the user perspective instead of solely from the business perspective. This means that we need to assess how the user actually is confronted with risks and allow for obiquitous capture at that moment. This will be the subject of further posts, but I wanted to put the idea out there.

Simplifying risk models

A brief history

The relevance of using risk models as the basis for risk management was disputed in the beginning of this century. It actually remains disputed as an approach by a number of authors. In the early ‘00’s, leading risk management advisory companies did not see the reason to use models. They felt it impeded organizations from assessing the entirety of their risks. In the late 1990’s, Arthur Andersen was the first company to start structuring risk models as a basis for the structural implementation of enterprise risk management. Some of their risk models remain as risk models you can for example find in Protiviti’s Knowledge Leader.

The wider adoption of risk models

Risk models really came to the fore towards the end of the ’00s, when experiments in implementing enterprise risk management or ERM systems showed a significant flaw in the prior reasoning: people did not share a mutual understanding of the term ‘risk’ and even failed to agree on a common definition for the most traditional of risks.

A solution wasthe development of risk models: industry specific structured overviews of potential risks which could occur in companies active in a certain industry, with a clear definition of what the risk means in agreed upon terms. Agreed upon terms would be adapted to company specific terms, in order to limit the risk of misunderstanding and thus mistreatment of a specific risk.

The challenge of today’s risk models

In our quest to increase the transparency and the unified interpretation of risk models, I fear we may have overcomplicated them. Overcomplicating a risk model – or any model for that matter – lowers the adoption rates by users. Therefore, while the move towards a more complex set of risk models was necessary to develop enough detail in the risk models, we now need to make the reverse move. This move should not be towards no risk models, but towards a list, an overview of possible risks.

The added value of risk management

Because what is the actual added value of risk management? It is the optimization of our response to priority, identifiable risks if and when they occur. Risk management should NOT be a central pillar of a management system. It adds to better risk response, and can be added to ways in which an organization is run, but should not be the central element.

In essence, even if no management exists, this would not preclude risk management systems to exist across an entity or a group of entities.

Let me explain: we see the demise of certain (types of) corporations, especially, but not only in the services sector. These are being replaced by decentral, distributed networks of independent contractors which come together on a project-by-project basis. Perhaps more than ever, these decentralized networks need risk management, but they inherently do not have a management structure to, well, structure their risk management.

The trigger list in Getting Things Done

So, how do you manage risk in a distributed, decentralized environment, or in any type of environment for that matter, in an as cost-effective way as possible? You develop a risk trigger list.

Actually, this idea is not new. I borrow the central idea from David Allen, who in his excellent book called Getting Things Done refers to an incompletion trigger list as an essential tool for the brain dump, in essence a way of clearing any issues in your head and getting them on paper, for further processing.

The trigger list is a very powerful tool: it is small enough (David Allen’s trigger list covers at most 2 modest pages) to be used on a regular basis and yet complete enough so all elements you may have forgotten can be dealt with.

The Risk trigger list

In order to enhance adoption of risk management as a tool, in order to make it usable on a regular basis and complete enough to deal with most risks one could forget, I would suggest to develop a risk trigger list per project, process, organization or even industry. This trigger list, which should not be more than 2 pages long, contains trigger words, words that will result in a comprehensive listing of most of the relevant risks which can occur in that process, project, organization or industry.

You may be surprised. At least per industry, I believe at least 50% of the risks will be the same across organizations. The list will partly be generic, and partly specific to the organization, the process or the project. Developing a risk trigger list should be one of the first responsibilities in any new process or project.

The relevance

By simplifying the comprehensive risk models we’ve developed in the past 10 years and condensing them into risk trigger lists, we may reach the critical threshold to wider adoption of risk management principles, which will in turn lead to better managed processes, projects, organizations and industries.

You are already managing risks

How do we start to manage our risks?

It’s an often heard question when talking to organizations about risk management. The honest answer to that is that most organizations already manage risk. It’s often just not called risk management.

Risk management by any other name

Let’s look at a number of examples of risk management which are not necessarily recognized as such: * Any organization that develops processes to optimize its activities is managing risk. It is managing the risks of its operations not running in an effective and efficient manner; * Any organization that has a people retention policy is managing risk. It’s managing the risk that good people will leave because they have no clear view on their future development within the company; * Any organization that has someone who gathers all press articles about it or its sector is managing risk. It is managing the risk that there are opinions or evolutions out there about itself or its market it would not know about.

Integrated risk management occurs enterprise wide

More than starting with risk management, organizations have a need to structure, integrate and optimize risk management. It’s not really about whether or not you manage risk, it’s about how to do it in the most appropriate of manners. And it’s about making the most of risk management.

High level assessment of the appropriateness of current risk management practices

So, if you are hesitant about starting up risk management, don’t be. Chances are you are already managing risk. The question therefore should be whether you are spending the money you spend on risk management in the most appropriate manner. This comes down to asking three basic questions: 1. Are we managing risk in the most optimal integrated manner for our organization? Are we aware of all initiatives being taken and are we integrating them in order to be as cost-effective about risk management as we can be? 2. If we are doing that, do we find optimization opportunities for risk management across functions? Are other functions handling similar issues in different, better ways and do we know about it? 3. Given that, are we exploiting the opportunities to the maximum extent? Risk management is not just about managing the downside. It is also about exploiting the upside, a dimension quite often forgotten.

If you can answer these three questions, you will have a better view on where you are and where you should be going.

Witnessing the Occupy movement in London

An accidental witness

When you're staying as close to St. Paul's Cathedral as we are, it's impossible to not see the 'occupation' of the square in front op the Cathedral's main entrance. When we went out looking for a taxi last night, we passed through a veritable crowd of people. I've posted a picture below.

The opinion of Londoners

Londoners are clearly interested in all of the commotion. While not participating, some of them are willing to join in the debate, which leads to people discussing the "situation" on the Cathedral's steps. However, talking to our cab driver we understood there is quite some apprehension as well. The occupation is bad for business especially for restaurants on and around the square, resulting in lay-offs in some restaurants there. An increase in poverty hardly must have been the idea to begin with.

The purpose of the church

The cathedral, as I learned from an excellent guided tour which I took, has always been a place where Londoners came when they wanted to fight injustice of any kind, whether social or economical. From that point of view, I understand the need to come together right in front of the building. And there's quite some ambition in the crowd. Just look at the sign they put up designating the square ...

Wondering about the future

Some of the points the Occupy movement makes are certainly legitimate. They are in line with social commentary since late 2008. However, I question the execution, both in approach and in relevance. I feel it is again turning into an us, outside society, against them, society and the silent masses. In that opposition there are always victims which did not manage to adequately mitigate their exposures.

The risk management angle

Is this, for the businesses impacted, a Black Swan? Most will think so. While I agree the likelihood of such an event is low, the business impact is huge. That is something that needs to be taken in account, in any type of adequate risk management. Some of the businesses on the square effectively had their license to operate revoked, not by a legitimate authority, but is essence by "mob" rule. I'm not expressing an opinion here, just pointing out that the sheer mass and presence result in this potentially dire consequence for local businesses. While clearly a lot less violent than the riots which rocked London this summer, businesses need to seriously start considering risk mitigation plans for these situations. If not, the next occurrence may turn out to be the straw that broke the camel's back.

Improving risk management through ubiquitous capture

Monday morning quarterbacking

After things have gone wrong, we have a tendency to start Monday morning quarterbacking. “How is it possible that they didn’t see that one coming?” Quickly, the comments turn to lack of organization and lack of information exchange. Remember 9/11? Different assessments all pointed to the same conclusion: the information was available, but was never correctly used or communicated.

Black Swan events

The problem is, this happens every single day in most organizations around the world. Quite often the attention points missed related to sales opportunities or customer satisfaction. While extremely important, these should not threaten the license to operate of said organization. However, once in a while a Black Swan Event will occur which can significantly impact the organization to the point of it no longer being able to operate. Think Enron, for example.

However, most Black Swans are not black swans at all. The information on the event and even on its increased likelihood was out there, but was never adequately captured, qualified and handled. Assuming well working risk management systems (I know this is an assumption) a correct capture of the event would lead to proper mitigation.

The need for simple obiquitous capture

So, what is the issue? All other things remaining equal, appropriate event capture is essential. But why doesn’t it happen? I believe a major contributing factor is the ease of capture of events, the so called obiquitous capture.

Obiquitous capture is a concept I have borrowed from GTD where it refers to ensure the most easy and accessible method of capturing everything you are thinking about for assessment later. This concept is the same for organizations. How can you develop a method, a way of working which will encourage collaborators to invest as little as possible of their time to capture as many as possible event indicators which may related to a certain risk?

An example

Alan reads an article in a magazine during the weekend which refers only slightly to an initiative by a direct competitor in the field of his colleague Bill. It does not concern him directly (it’s not the monkey on his back) and he has no means of direct capture … and he is very likely to forget mentioning it to Bill on Monday. Six months later, the competitor launches a new service or solution in the market which seriously dents the market share of the organization Alan and Bill work for. Alan suddenly realizes, starts feeling nauseous, but doesn’t tell. He will not threaten his own position. During the next earnings call, several commentators refer to the article and ask why the organization was not ready for what was in plain view. Now not only the market share is dented, but confidence and reputation as well …

So, what possible solutions for obiquitous capture are out there?

The impact of simplification on residual risk

Red tape increases risks

Red tape is likely to lead to increases in residual risk profiles of organizations. These organizations are overburdening their external and internal customers with these increases in rules and regulations they need to comply with. Contrary to their expectations, this will not lead to more care. The more rules exist, the more this will lead to less care. Less care will reduce the risk awareness of the customer facing employees because they too are jumping through the hoops. The reduction in risk awareness will result in a higher residual risk profile because the assumptions are not checked nor questioned and may turn out to be false.

Past relevance of red tape

Introducing red tape in organizations was initially done to ensure that operations ran smoothly. A lot of the operations in larger organizations in the industrial era were 'standardized' to reduce costs. This approach was copied in service organizations and public sector entities as well. This led to productivity increases, which were a good thing from a cost side. However, the more you standardize a process, the more difficult it will be to provide deviations to the standard product. As Ford (presumably) has said: "You can have any color of car, as long as it's black." The choice in the Model T was limited. You had the choice of black, black or black. In addition, people on the work floor were discouraged of showing initiative and thus did not take ownership of the process. This part was also mirrored in different organizations.

Assymetrical information availability influences risk

A risk profile of an organization is a view on the risks to which an organization is exposed. A risk profile is specific to a company but heavily influenced by the industry in which is operates as well as the overall business environment in which the organization lives. A lot of different elements can influence a risk profile. First, there are risks external to the company. These risks in the organizations environment will influence its risk profile. The organization can do little about these risks, which can include the business environment, demographical evolutions, weather, disasters such as the Deep Water Horizon ... but they will impact it, and may impact it severely. A risk profile also consists of operational risks. These risks occur in everyday operations of the organization. One of the possible risks which can influence or worsen other risks is the red tape. More on that later. Finally, we see decision making risks. Information out of the external and operational environment is reported to the decision making levels which are not necessarily intimately aware of the situation on the ground. They base themselves on decision information. Any errors in the assembly and presentation of this information can lead to faulty decisions. Therefore, these risks influence the risk profile as well. These risks in turn can be significantly influenced by the red tape risks.

What happens if you leave red tape unchecked?

Imagine a situation in which an organization continues to develop red tape procedures beyond the point of marginal returns, i.e. the point where the procedure stops making sense. Compliance, if reached at all, will be reached with minimal care as the users do not see the relevance or the benefit of the additional requirements. More rules lead to less care.

Now, imagine a situation in which an organization is run based on rules and only rules, with any remarks or dissenting opinion ignored or punished, because its deviant behavior. New hires will very quickly stop caring. This is exactly what is witnessed in this type or organization, often hierarchical organizations. Now, if your collaborators no longer care, they will not be aware of will not mention elements influencing risk profiles. In essence, their risk awareness will be significantly reduced.

And when the risk awareness in an organization reduces, the likelihood that risk exposures are identified, flagged, assessed and managed reduces. What happens is that the real residual risk profile of the organization will become higher. Now, every increase in risk has an associated cost, all other elements remaining equal. So, either the organization accepts the higher cost of the risk management, therefore losing the assumed benefits of red tape increases, or the organization will be exposed to more risk.

The simpler the process, the lesser the risk

Introducing simplification projects which aim to reduce red tape will likely bring terror to the corporate identity. They are not used to these exercises, and they are counter-intuitive to much of what they have learned. However, think about the following: you will introduce more care in the execution of the activities of your organization, which will be appreciated by your customers. The increase in care will lead to an increase in risk awareness, which should lead to a reduction in the residual risk profile of the organization.