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.

Stakeholder perception as a third risk dimension

The limitations of current risk management approaches

Risk management is most usually limited to the organization whose risks are being analyzed. Stakeholders are considered in most frameworks, but often only in the context of information and communication. They are seldom considered an active, contributing party in the context of risk assessment. Adding a third dimension to risk management by identifying, analyzing and prioritizing the risks as seen by stakeholders, will yield important insights and assist in saving the organization's license to operate.

Why stakeholder perception matters

Your organization does not operate in a void. Risks are certain to threaten it, and some of these risks will also significantly impact your environment and other stakeholders active in this environment. And of course your stakeholders will react to the exposures they experience. Exposures caused directly or indirectly by your organization. In a worst case situation, their perception of an issue where you are convinced no real risks exist may create an issue where you expected none. If this catches you unaware, you have a real, additional exposure on your hands, an exposure you will have to manage.

Just imagine the following situation … your company operates a production site which treats certain types of contaminated materials. In order to process these materials, you need the authorization of the local authorities. No matter how safe your operation actually is, if you cannot convince the stakeholders present in that environment of that very simple and to you more than obvious fact, they may convince the local authorities not to extend the license to operate for your authorization. Do you have a plan B? Can your organization carry the costs of moving your clean-up activities elsewhere? Can you deal with the possibility of having to move your entire operation? In less than a year?

Stakeholder analysis

How do you know what is bothering the relevant stakeholders? I may be reaching here, but perhaps you should ask them. It may be a rather novel or even a revolutionary idea, but approaching your stakeholders with questions on what they deem to be important, ideally introducing them to the exercises you have been running internally to assess your risks and even clearly showing them your current risk mitigation is not always a bad idea. In some cases, it may actually be a first step in establishing a true relationship or at least a regular communication with these stakeholders. In essence, you are applying the 'First seek to understand' principle Stephen Covey promoted. Doing this will increase your understanding of their concerns. Be aware that these are real risks to you if they can threaten any aspect of your business.

So, you could imagine yourself, in some future, querying your stakeholders on their concerns, checking whether their concerns map to your internal risk model and add the risks you did not take in account. Let them go through an exercise similar to the exercise your collaborators go through. Let them evaluate their perception of the current level of residual risk (impact and likelihood from their perspective) and their assessment of the current level of control or current level of effort.

We all have a natural resistance to bothering other people with our questions, ignoring that just asking the question can be considered to be a sign of appreciation, of relevance and may lead to the initiation of relationship.

An illustration

Now imagine the following scenario, which I will call scenario 1: You spend a lot of time communicating on your corporate social responsibility, and note this message comes across really well. There is no significant difference between the perception of your stakeholders and the internal perception of the risk in your organization. You will not need to spend a higher effort in managing the perception of your stakeholders in terms of your CSR activities.

However, in scenario 2 you have spent a significant effort in securing your waste transportation activities. Your engineers confirm there is little to no exposure to the environment nor to the stakeholders active in this environment. You failed to communicate this appropriately, focusing on the technical aspects only. The stakeholders are not convinced and consider the actual risk to be significantly higher than you engineers lead you to believe. You have an issue, even if your processes are in fact under control.

Even if you haven't seen it, it is still there

In conclusion, You need to be continuously aware that the risk as perceived by your stakeholders can evolve into a very real risk to you.

How? The stakeholders can influence or even determine the validity of your license to operate. In the case of the example scenario 2 above the stakeholders can organize themselves and become a pressure group challenging your license at the local government level. In turn, the local government can decide to raise your taxes or even deny an extension to your current license. Each of these possibilities will cost you money.

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.

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.

Assessing real risk appetite

Attending an IIA training in Brussels today on Corporate Governance audits, an excellent training by the way, we (the participants) started discussing risk appetite. The discussion got me thinking about the way we establish or validate risk appetite and the issues that come with that. Let me take you through my thoughts ...

A reflection of stated risk appetites

Let's look at a traditional process of establishing risk appetites.
Following COSO-ERM, the board has established some kind of risk appetite. In order to translate this to an operational reality, we start with a risk analysis, often based on risk maps specific to your industry. Management and process owners assess impact, probability of occurrence within a certain time interval and current risk coverage. They follow this with an assessment of the adequacy of that coverage in order to determine their "appetite" for the specific identified risks ...

Well, there is a bit of a problem with that approach. This approach gives us a reflection of the stated or expressed risk appetite, the stated preferences of the participants with respect to these risks.
What we don't know is whether this is a truly accurate reflection of the risk appetite, or whether it is a subjective response reflecting what management believes it should answer as a truthful interpretation of the expressed preferences of the board.

In other words, is this a reflection of how they really would behave with respect to these risks, or of how they believe they should behave.

Real risk appetite is reflected by exhibited risk appetite

There is one good way of finding out real risk related behaviour. For risks which occur with some frequency, we can observe the behaviour of management and process owners.

How? Well, any actual behaviour towards risks is reflected in the day-to-day decision making and action taking. In other words, our operational behaviour is an accurate reflection of risk related behaviour. From a risk management point of view, we can look at evidence of this behaviour, such as:

• publications which exhibit our opinion on certain key issues in our industry which may be related to one or more risks, hence giving some information on our real risk appetite;
• project choices and priorities give information on our preferences in terms of organisational strategies that we want to focus on as we deem them relevant;
• meeting minutes of and reports presented to the board and exco give us information on which decisions are being taken as to where the organisation should focus.

In essence, these real life rather than stated set of choices reflect our actual attitude as an organisation, a management team, a division with respect to risks and our exposures to these risks: in other words, our risk appetite.

Using the results

Okay, what can we do with the information we gathered? Recapping, we have information on the stated, expressed behaviour of management and process owners towards risk and we have information as to the actual behaviour exhibited by the management and the owners regarding these risks.

We can perform the following analyses:

1. Internal interpretation of the board's risk appetite: When we compare the board's risk appetite with the stated management and process owner risk preferences;
2. Actual versus stated risk appetite: When we compare the stated management and process owner preferences with the exhibited preferences.

For any discrepancies, I would ask management or process owners to come up with a good explanation which motivates the deviations. They may be relevant and valid, but they need to be in line with the board's choices.