Killing our local heroes

From extraordinary to commonplace

The evolution in which we are caught, for lack of a better word, has brought us many an advantage ... I, for example, grew up in a day and age that computers were not widely available nor used in the household. I remember being awed by them.

But if I now look at my own home, there are at least four apparent computers, work and personal ... not counting what is embedded in systems. They have become normal ... commonplace.

And it does not end there. No sir. Movement of people has become a lot easier across the globe, both technically and politically. We have planes to get there, and political agreements to go somewhere once we are there ... And when we get there, we often find people similar to us, but better, to look up to and to simulate and assimilate the behaviors of. And that is great. That is so wonderful.

The cost of our current progress

However, it has also cost us. We have killed our local heroes. We have killed them, because we have failed to honor them. They have gone the way of the computer. From extraordinary to commonplace.

It used to be that each community had someone to look up to. Someone who had made it, even if having made it was just leaving the small town to find his or her way to the big city. Often, they were closer and remained close. A teacher, perhaps, or a business man. Even of the business was, in the wider context, just a cut above the rest.

A hero's death is not death ... it's being forgotten

These heroes no longer exist. No, I'm lying. They still do exist, but they are no longer regarded as our heroes. They have been replaced by the rock stars of today. People such as Steve Jobs, Jony Ive, or Barack Obama, or Warren Buffet. And those are just the good ones on the list. Don't get me wrong, I have a strong admiration for such people. I just wonder how to get from here to there. And why I should do that.

Virtual deity

And that's a real problem, although we may not consider it as such. The gap between our new heroes and us is just too wide. They can be admired, but only at a distance. Rather than the late 1800's and early 1900's evolution, where heroes were close to everyday life and ultimately approachable, where the gap that existed could ultimately be bridged, we are now moving in a direction in which what we want to achieve amounts to virtual deity. Which is, for all intents and purposes, almost impossible to realize.

Global heros do not scale down so well

It ultimately comes down to incrementalism. You do not reach large goals all in one go. You achieve small feats every day which bring you closer and closer to an achievable goal. You put your sights at an ambitious but realistic level, and you actually achieve that well within a fraction of your lifetime. Once you are there, you recalibrate your goals yet a bit higher, to a new role model, to a new achievable, adequately ambitious but still close enough goal. And so it goes. Or actually, so it went.

Cargo cult heroes

The current gap between what we are and what we often aim to be is so large that people revert to imitating the externalities of what they want to achieve. Feynman's cargo cult, applied to humans. This leads to young traders on the floors of banks to use their (often significant, yet small when compared to those they imitate) assets to do what their idols do, without understanding that the only real way to achieve structural growth is through hard work. And there are so many other, sad examples.

Becoming a hero requires you to do the work

I believe strongly that if we want to continue to prosper, as a species, we will need to relearn that progress comes at the cost of small steps, of doing the work.

And if we want our young people to understand that, we are obliged to start becoming the heroes we want them to follow. And in order to become those heroes, we need to start showing behavior which is consistent with those values.

If we fail that, we will not only have killed our own heroes, but those of the generations that follow as well. As did the generation before us appears to have done, even though they started so well, in the late 1960's. let us not make the same mistake again.

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.

Some further thoughts on professional service (de)commoditization

This is more than likely the last I will write about the challenge for consultants in differentiating their offerings from other offerings, but I wanted to share a couple more lines on the subject. This is again a revisit of an article I wrote a couple of years ago, with some ideas I developed further. Here goes.

When does a service or product appear to be a commodity?

When two companies are offering the same products or services, they will appear to be commodities. As Bill Caskey notes in 'Same Game, New Rules', commoditization occurs in the mind of the client, not necessarily at the product level. I referred to this in the prior post on the subject.

To be more precise, even if the products or solutions are exactly the same, diffentiation is possible in the way they are offered, presented, executed. Some companies manage to differentiate their products and ask for a higher price because of it. Think McKinsey. Think Apple.

Differentiation in services

In my earlier post I stated that even services which are commoditized can be differentiated by their delivery. And we all know examples where a commoditized solution is distinguished by its implementation.

Why consulting is like plumbing

That is not an intro to a joke, although it could well be. In the past, I have seen my share of plumbers: same tools, same products, but there is a monumental difference between a good and a great plumber. And while most consultants may contest this, professional services are really not that different from plumbing, at least in this area: even if the methodologies are the same, the differentiation will be in the use and the execution.

Consulting organizations continuously undermine their own effort

True differentiation becomes difficult if past achievements for a project are claimed by multiple parties. How do you believe we, as clients, would currently be able to distinguish between the achievement of a company and the achievements of the individuals working for that company at the time of the project? If you really want to know: we can't. And that is to your detriment. And a bit to ours, when we select the wrong consultant.

When a consulting firm claims credentials which have been achieved by a person or a team of people no long working for that firm, because the project was executed under the flag of that firm, I would dare to state they are misleading me as a client.

To put it bluntly: we once had a good plumber in our team. He's no longer there, but newbie over here is using his wrench, so that should be fine, no? No.

By continuing to claim credentials achieved by personnel no longer employed by your company, you are in effect commoditizing own services, because you are separating the achievement from the team. Remember in my first post I referred to the higher relevance of the individual in comparison with or in contrast to the relevance of your "methodology"? This is exactly where that starts to play a very, very big role.

Be truthful

The solution is very simple: as contractors we should require consulting firms to separate their credentials in three categories:

• credentials for which the executing team is no longer present in the firm;
• credentials for which the executing team is still present but will not be used on the project and finally,
• credentials which relate to achievements of the proposed team.

This way, the individual resume will become significantly more important.

I think this is a first important step towards decommoditization of services.

Respectful visioning - a facilitated approach

As auditor, I have often been asked to facilitate between different groups. I believe the below may therefore be relevant for us auditors, although the subject is not core audit.

I was recently invited to facilitate a group of experts in preparing for a significant likely change in their environment. As the agenda's were not yet fully in line, I used a combination of a number of facilitation concepts to develop what I now call "respectful visioning." What it is, how you can use it and what the outcomes will be I describe below.

Context of the facilitation

Imagine a group of experts, each with their own, strongly held opinions, each of them with a good basis for having that opinion. But, ultimately, some of these opinions are incompatible. They cannot jointly lead to one shared vision. Yet the goal was to arrive as closely as possible to some shared ideas on what the future should look like.

After having spent one and a half day talking to each other, listening to different experts bringing their interesting ideas and visions to the table, and identifying implicit and explicit friction points, the group had about three hours left to try to get as close as possible to a common vision for the future.

My observations

I had been able to identify a number of potential friction points throughout the facilitation I had been providing for one and a half day. These were:

• A disconnect between people concerned about the day-to-day operational feasibility and people aiming to deliver an overall longer term vision;
• A strong need in most of the participants to be able to express themselves and to contribute to the ultimate vision;
• A strong need in all of the participants to be respected in their vision.

My challenge

On the other hand, I wanted to have a clear vision emerging at the end. A clear vision is not the sum of about 20 individual visions added together. In addition, some of the subject matter was either highly technical or organization specific, hence as a facilitator I needed to stay away from getting to caught up in the subject matter itself.

The solution

I used the following approach, heavily borrowing from some of my more favorite facilitation techniques:

1. Phase 0 - Preparation: I decided not to go for one vision, but for a vision for the short term (ideas in there needed to be realized between now and 1 year), the medium term (with ideas to be realized between 1 and 3 years) and the long term (with ideas to be realized beyond the 3 year threshold). I prepared three flipcharts with on these the term (short, medium, long), the numbers 1 through 5, below that a line and the term "ideas" and below that the term "wildcards". In addition, I had provided each partipant with three stacks of two post-it notes, in the colors red, orange and yellow.
2. Phase 1 - Briefing: I told the participants the sequence of activities which we were to embark upon. I had asked the group of participants to be split in three for the latter part of the exercise. The visioning exercise owner had proposed three groups. Each participant knew which group he or she belonged to.
3. Phase 2 - Individual ideation: the participants were told to generate ideas about what they felt they considered the most relevant achievable objective or result over the short, the medium and the long term. They had 10 minutes to think it over and put their top 2 ideas for the short term on the red post-its, their ideas for the medium term on the orange post-its and their ideas for the long term on the yellow post-its.
4. Phase 3 - Collection: the participants were asked to put their ideas, depending on the colors, on the correct flip chart. This way we had ideas from each participant for the short, the medium and the long term.
5. Phase 4 - Clustering and prioritization: the participants were then asked to split into the three preassigned groups. Each group had been assigned a flip chart. They were asked to determine the top five of ideas for the term (the flipchart) they were assigned to. They could use the input and most of the groups started to cluster and try to represent the ideas as best as possible in the top five. After 20 minutes they were asked to come up with a top five. The inputs gathered during the collection phase remained on the flipchart, in the ideas area, under the top 5.
6. Phase 5 - Presentation: Each of the groups presented and defended their choices for top 5.
7. Phase 6 - Clarification: I took over from the presenters/spokespersons of each of the groups and facilitated through a sometimes very intense and interesting discussion. At this point, most of the cards were on the table, or rather on the flipcharts. We ended up with at most seven ideas for each of the terms.
8. Phase 7 - Wildcards: all participants had the time to select one of their initial 6 post-its (or those of someone else) which were still on the flipcharts and put the them in the wildcard area. Ideas in the wildcard area would be taken into account in the reporting of the vision as wildcards, whether or not they were supported or even discussed with the group. Note that the number of wildcards for us was also an indication, albeit it a very rough one, of the level of support for the ideas in each of the terms.

Result

After about 2 and 1/2 hours, we ended up with, as I stated above, at most seven ideas per term, not counting the wildcards. At most, we saw four wildcards on one flipchart, but no more than that. Given we had about 20 participants, hence 120 ideas (40 per term), the number of wildcards is indicative of the fact at least some common ground was reached.

Why respectful visioning?

Introducing the wildcards really helped people in letting go of resistances and inhibitions that otherwise would have been present although not necessarily shown. Knowing that they would be able to voice their views which could be different from the consensus was extremely important. At the end, few actually did, which either shows they were more in line than they thought or that the approach really reduces certain blockages that may sink another facilitation.

Single Point of Failure

I keep revisiting old articles, not necessarily because I've run out of things to say, but because I often feel I did not state my case well enough. This mainly happened because I did not have enough practical experience outside of consulting to be able to be relevant. Here's for a second go at my article on process redundancies and why they can make sense.

Defining a single point of failure

A single point of failure is a point in a system (such as a (manual) process) which, if it fails, will bring the whole system down. Not all redundancies were created because people felt they could afford to add an additional, non value added layer. Rather, redundancy in systems were created to avoid single point of failure.

Of course, during crisis times, process efficiency reviews such as Process Impact Analyses (PIA's) are likely to identify redundant activities. The subsequent reengineering will lead to significant optimizations in process efficiency. However, while aiming to reduce the unnecessary redudancy in systems there are a lot of reengineering projects which overshoot.

The butcher's apprentice

Large scale reengineering projects sometimes cut indiscriminately through processes and systems. In my experience, especially projects which originate out of a dire need to reduce expenditure will have overall expenditure reduction targets that are most easily applied across the board. That this approach often makes no sense at all is never considered. These projects result in the creation of single points of failure in processes where prior to the reengineering effort a necessary redundancy existed. Indiscriminate cutting into a process is a bit like being a butcher's apprentice ... mistakes by cutting the wrong piece of the meat can be quite costly.

And let's face the hard truth we failed to face so often in the past: our people (who are responsible for doing the process work) are expensive to make mistakes with. Especially, but not only if these people are good in what they do.

It gets worse. Given these reengineering exercises are most often executed by external parties, those mistakes are mostly made by young, ambitious but necessarily inexperienced consultants with little to no real life process background.

Is there a way to avoid this? Can you detect and fix a single point of failure?

Detecting single points of failure

To detect a single point of failure, it's important to take the time and talk to the people that execute the process every single day. They're pretty much the only ones that are aware how the process actually functions. And talking, preceeded by gaining the trust of those people and earning that trust is essential. Not only because you may be surprised about the amount of process knowledge that was not captured in the process documentation. No, quite often these people are the only ones that are aware of the existence of the single point of failure and all possible implications that brings with it. Even better, they can quite likely help you avoid it. There are other ways, which I list below, but none as powerful as talking to people.

Alternative or additional actions

The following alternative but most often additional actions can help you in your search for single points of failure. Note that these require a significant investment in time and means to properly execute. In my opinion, only coupled with in depth discussion with process owners and operators will they yield the most relevant results. You can:

1. Map the process: understanding the process and the interactions in the process is a powerful way to understand what is actually going on. Again, do not base yourself on procedural descriptions. Rather, interview people, monitor process execution and look at what's really there. You may be able to identify your single points of failure in the process itself;
2. Identify choke points during a walk-through or based on process indicators: quite often, a choke point where backlog piles up is a good indicator of a single point of failure. Process indicators which are often indicative of a problem in a process will be a relevant factor as well.

After identification, you need to solve the issue

As I stated above, a significant number of reengineering projects stripped operations to the bare bones, only to find out that because of the existence of single points of failure the process completeness, timeliness and accuracy were largely jeopardized.

That's why I dare you to create or maintain the necessary redundancy in the process. This is often a cost benefit decision. In case the single point of failure risks risks collapsing or significantly disturbing the process, creating a redundancy in your process is not overspending. Rather, it makes good business sense if the cost of failure is significantly higher than the cost of the redundancy, over time.

From the other side of the table - the (de)commoditization of consultant's services

About one and a half years ago, I made the transition from being a consultant to being a consultant's client. I effectively moved to the other side of the table. I have written before about decommoditization of consulting services. This is a revisiting of some of that earlier work from my new vantage point.

Consultants fear commoditization

Believe it or not, but underneath that power seller across the table from you is a person afraid of not making their sometimes very high revenue targets. Being confronted with a client which plays one provider against another raises the very real spectre of service commoditization. Consultants all fear commoditization of their services.

And they are right in doing so. Commoditization of traditional consulting services, from reengineering to strategy development, has led to a price competition in which all competitors have lost. Now, you'd think that we, as clients, would have reaped the benefit. But it turned into an aggressive race to the bottom. Those are never pretty, not even for clients which appear to benefit.

Why? I note a significant decline in the quality of service as the pressure to sell more and more catches up with the quality of service delivery.

Where commoditization occurs

I'm convinced quality decline of this nature should not occur and can be avoided. From where I'm looking at it, most consultants fail to understand the mechanism of commoditization, or at least see it differently from their clients.

How? Well, consultants believe service commoditization occurs at the level of the solution they provide. Now, it is true that most consulting organizations offer similar services. But what consultants fail to understand is that to a client these are rarely a commodity. If they are relevant to the need that exists in the market, they are an answer to a problem. While they may seem similar, the people delivering them have their own experience, expertise and approach, which will either be a unique fit to the my needs or no fit at all.

So what consultants erroneously consider to be a commodity is in the best case not a commodity at all because of the way in which individual consultants combine their understanding of the problems the client faces with the standardized services of their organization. If we get what we pay for, they will develop a unique solution for me. Unique, hence not commoditized.

I believe the added value of the individual is more important than the relevance of the solution the company provides from its solution framework. Sadly, rather than attention to the expertise of the individual, most proposals focus on generic methodologies which I can read in any management book.

Knowledgeable sales approaches are the basis for removing the commodity status of services

Let's start from the assumption that the biggest challenge for a consultant is not finding the market, but truly understanding the market's needs. Even better would be if they would understand the needs of individual clients in this market. The only way a consultant will ever understand the market's needs is through its people.

Therefore, consultant collaborators need to be trained in attentive listening skills and in respectful probing of issues. But before that is possible, they really need to learn how to bring a current or potential future client in a position where he or shee feels safe enough to speak to them about his fears and uncertainties.

Let's be clear, the highly assertive sales pitch by the smooth and slick consultant will not do it. The big car in front of the door does not give me assurances you know what you are doing. It only confirms that I may be paying too much.

No, you will need to invest in building that trust relationship over the longer term. You will need to make it clear that it's worth working with you.

The lesson

As a client, I am convinced that even this crisis hit market with significant budget reductions, especially in public services, is plenty full of commercial opportunity for consultants. Now, the market is abundant enough, but it needs to be thoroughly understood and respected. In order to see how plentiful it really is, companies will need to let go of their aggressive stance to the market and abandon the hard selling method.

Why, because as a consultant you may not understand this, but hard selling profiles a business as a commodity. And as stated above, whereas the services may seem similar, the people delivering the services make all the difference. They are not purely intellectual assets which are replaceable, they are people with skills in talking to people.

The organization or the individual consultant which will come out on top in the next five to ten years will not be the firm with the best or most innovative solutions. It will be the firm with the best listeners, the firm will to invest in developing long term relationships with clients on a basis of equality.

Better risk based situational awareness using risk models

This is a rewrite of an article I wrote in 2010. I'm revisiting some of my earlier writings to update them to my current ideas.

Top five versus first five issues

Ask people for their top five issues in any area of concern other than an area they are personally and closely involved with, and they are more than likely to give you the first five important issues that come to their mind. Of course, these are not necessarily the top five issues, they are their top five issues at that moment.

This problem, by the way, is a typical challenge of idea generation which you try to counter with brainstorming. Ideally, you would ask them to tell you their top 50 issues, and then prioritize. However, quite often they don't have the time and you don't have the budget. And that is a critical problem. Why?

Getting an as complete as possible view on risks is essential in a risk management exercise. After all, risks not identified cannot be managed, and will come to the fore at the most inopportune of times.

Using risk models

This is where risk models come into the picture. A risk model aims to take a lot of the preparatory risk identification work out of your hands. There are certain advantages to using a predefined set of potential risks for an organization. Three of the most important ones are:

• it allows you to focus on the relevance of the proposed potential risks, thus reducing the actual effort invested in thinking about completeness;
• it allows you the time required to better and more clearly defined the risks which are considered as relevant;
• it allows you to identify those risks not already present in the risk model.

Errors in understanding the use of a risk model

People opposed to the use of risk models will make the case that the tool has limited value because you can never integrate all relevant risks in one framework.

It is indeed practically impossible to integrate all relevant risks in one overarching framework. However, rather than making a risk model a tool with limited value, the simple fact that the risk model has already defined a lot of potential risks and thus takes away the effort of performing the same analysis again and again, makes it a tool which saves you time and effort. Rather than reinventing the wheel again and again, the risk model allows for true value creation in defining new risks which you otherwise would have never thought about because you were so focused on the top 5 risks.

The relevance of the risk model

A risk model allows you to focus on the essential risks both present in and lacking from the model. This leads to a better degree of concrete, situational risk awareness in a risk assessment exercise.

Not waiting for Godot ... waiting for Mailbox.app

Mmm ... look at that ... less than 260.000 people in front of me in the queue. At an activation rate of one per 4 seconds that amounts to about 12 days wait. Let's call it 14 days to be on the safe side ...

That's going to be one long wait for an application that is apparently very much worth it. In the mean time, I'll just reread Lex Friedman's excellent Macworld article on the app. If you want to read it, you can find it here.

14 days. What a wait ... but I am quite convinced it just might be worth it ...

(Re)introducing the Risk Effort Matrix – another way of presenting and interpreting risk

This post expands on an article I wrote in 2010 for a blog called Risk 101 - Complexity risk management. The reason I got this from under the dust and decided to revisit it, was a discussion during a class I taught this week. Some of the concepts have been adapted to align with my current thinking.

The challenges of "inherent" risk

Although I have tried for years, it remains difficult to thoroughy explain inherent risk to someone who is new to risk management. The theoretical aspects are easy, but once you get into the nitty-gritty of how to actually determine "inherent" risk, most conceptual explanations leave you hanging.

The crux of the matter is whether we consider it possible or feasible to let people determine their exposure to risk without taking in account the current level of controls present in the processes they manage or are involved in. The problem? This is actually a lot harder than it seems. The assessors need to be able to ignore everything they know about the existing controls in their current process.

To illustrate, this would be equal to someone asking you to assess the safety level of your car while ignoring all the traditional, existing safety measures such as power brakes, airbags, power steering ...

The more I work in risk management, the more I teach risk management and the more I interact with people charged with implementing risk management, the more I wonder whether we should not forget about the theoretical aspect of inherent risk and focus on what our risk management responsibles know best: their actual situation. I am convinced good risk management needs to start from the actual situation in terms of risk management measures or controls, without necessarily questioning everything that has gone before.

Presenting risk in a matrix with residual risk on one axis actually makes a lot of sense, for a number of reasons. Let's consider the presentation of such a matrix with residual risk.

Visualizing risk management effort

A traditional risk control matrix visualizes the current level of inherent risk, a function of impact and probability of occurrence during a certain time interval without taking into account the existing controls, on one axis, often the vertical one. The current level of risk management (sometimes also referred to as the current level of internal control, although that ignores risk mitigation other than internal controls) is then shown on the other, most often horizontal axis. The result is a matrix where inherent risk and current level of control are two independent variables which provide a presentation of the risk profile of an organization.
However, as stated above, while theoretically enticing, in reality it is not that easy to assess inherent risk levels. Risk management, and especially qualitative risk assessments, are by nature subjective. Asking people to make abstraction of aspects that are inherent to their experience of a process may introduce a subjective bias that is likely to skew the entire exercise to the point of making it unusable or irrelevant.

But what happens if we were to assess not inherent, but residual risk. What if we ask the participants to assess the level of risk (as a function of impact and probability) as they currently see and experience it.

Mapping the current level of risk management or the current level of internal control becomes irrelevant, because it's already been taken into account. That is exactly where the difference between inherent and residual risk lies. What can we do next? I believe there are a number of possibilities, of which two are irrelevant or not feasible, and one is interesting to examine further. Let me take you through the first two first.

Back to the traditional risk matrix

Given we don't really 'need' the current level of control axis, we could consider going back to the traditional risk matrix, presenting impact and probability of occurrence on two axes. However, if we were to do that, we would again get caught in all the problems that pushed us to leaving this traditional presentation in the first place. Longitudinal presentation of risk profile evolutions would become a mess very fast. We would create the illusion that impact and probability are equally important in all circumstances, and we would fail to show that tolerances are individual to each risk (or, more correctly, to each objective and hence to each risk influencing this objective.)

'Calculating' inherent risk

We could try to calculate the inherent risk level based on the information about residual risk and the current level of risk management. The problem there is that you are performing calculations with figures determined in assessments which are not equally calibrated. You will use 'quantitative' data, such as numbers representing a level of impact, likelihood and current risk level which are based on differently calibrated scales, which therefore cannot be used in calculations together. In essence, you are comparing apples and pears.

Risk management effort as a relevant metric

We could determine, even in a rather objective manner, the 'investment' done in dealing with a risk. I like to refer to this as risk management effort or internal control effort.

It is a function of the means, in terms people, processes and technology which an organization has invested in order to bring a risk under control. Now, we will not assess the effect of this investment, which is pretty much what we did when mapping current level of risk management. We map the actual or perceived effort, either based on hard, tangible information as provided by the organization under assessment, or as assessed by the people performing the assessment. Of course I have a marked preference for the first method. If completeness of the direct cost information can be assured and a reasonable approximation of indirect cost elements can be agreed upon, this is a reasonably objective measure.

Introducing the Risk Effort Matrix (REM)

And what does the REM look like? It looks like the matrix below.

Risk Effort Matrix

Let's examine this matrix in a bit more detail:

Just like the risk control matrix (RCM), we still retain the quadrants, but the content and thus the roles and responsibilities have fundamentally changed.

Quadrant I – What has gone wrong?

Quadrant I shows a high residual risk despite a high level of effort. What does that tell us? We invested a lot in order to reduce a risk exposure, but apparently it's not making much difference. This is an area where the existing management plans which gave rise to the investment need to be thoroughly examined. Internal audit can contribute by executing effectiveness audits, in order to determine whether the effectiveness issue is an external one or an internal one. In the former situation, no matter what would be done, the residual risk would remain high. In the latter, the investment in risk reduction was likely not the most optimal, and money was lost in suboptimal developments. This could for example be the case if the analysis lacked the necessary cost/benefit analyses?

Quadrant II – The future effort area

Quadrant II is the area where the residual risk is high, but in which to date little effort has been made to manage this risk. This is an area where new management action plans need to be developed, based on a good cost/benefit analyses, in order to determine and ideally implement the most optimal manner of managing the risk.

Quadrant III – Assurance and potential cost savings

Quadrant III is the area where the residual risk is low, aided by a significant effort in people, processes and technology. Management has invested, and it appears to pay off. The question remains whether it truly has. In this area, internal audit needs to execute its assurance task, giving comfort to management that the risk has indeed been reduced to its optimal level. In a number of cases, internal audit may decide too much effort was put into the risk management, and that a reduction of that effort will not significantly influence the risk in a negative way. This area of potential risk management overkill may become an area of significant cost savings for the organization.

Quadrant IV – Monitoring required

Low residual risk in an area of low effort requires watching and monitoring. It may well be no problems will occur here … but it is entirely possible there are risks waiting to explode on the risk scene of quadrant II here. Management needs to ensure monitoring, and internal audit can provide assessment of monitoring quality and relevance.

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.

Chipping away at your mountain

Playing the piano

When being asked what GTD is all about, I'm often reminded by what I see every day when I'm watching my kids practicing the piano. I remember the day they started their first practice as if it was yesterday. Their fingers clumsy on the keyboards, not really knowing what to do, but quite determined hammering down on the ivory. They started practicing, just like they start practicing every single day. Sometimes there has been some resistance, but for the past four years since they started to practice, they really started practicing again every single day. Not too long, not too short, but very focused, with kind but firm guidance from their mother. While each individual practice, certainly at the beginning, did not appear to amount to much, it's amazing how good they have gotten in those past four years. They each have been diligently chipping away at their mountain.

The core of GTD

You may wonder what this has to do with GTD? I think it touches the core of what GTD is all about. Let me explain. GTD to me is essentially a self-management system which allows us to focus on deliberate practice of our essential to do's every single day, again, and again, and again. Consistently using a system such as GTD helps you to avoid just practicing and focuses you on practicing towards one or more specific goals.

My children could be practicing the piano by just hammering down any key. It just would not take them very far. In the same vein, it wouldn't make sense for you to just execute tasks as they occur to you. Rather, task optimization and optimal task execution can only occur if and when you put some thought into planning if, when and how you will be doing these specific tasks.

Higher altitudes determine task relevance

The first and most relevant question is of course whether doing something with the input that triggers your action response is relevant at all? Do you really need to do this? Is this a task for you? Is it a relevant task at all? If you're clear on your higher altitudes it will become far easier for you to determine whether or not you need to do something. For clarity on your higher dimensions, try journaling.

Time is a context

Once you have determined whether or not you need to do a certain task, activity or action, you need to judge when it needs to be done. Now, later or someday when conditions are right?

Seasoned GTD practitioners recognize the critical aspects of time bound constraints and contextual constraints. The conditions you need to be present in order to be able to successfully execute a task are referred to as contexts. Never really discussed in GTD as such, time is as much a context as tool presence or location. We just have a tried and tested tool for time bound planning, which we call agenda. The essence of contextual task execution is to execute tasks with a minimum of context or tool changes. That practice improves efficiency in task execution.

GTD is not (yet) doing the work

But even with optimal planning, you still have to do the work. Doing the work is the point where you start chipping away at your mountain. al the rest is pure preparation.

If you spend an inordinate time planning and preparing or tweaking your GTD system you'll never start chipping away at your mountain. On the contrary, if you failed to plan adequately, you'll start chipping away at a piece of rock here using this tool and a little bit there using that other tool, but you'll never get anywhere. Your effort will never be focused enough.

However, If you strike the right balance between using the appropriate time for planning and review while keeping a lot of time for actual execution and you do this day in day out, you may actually be surprised if you look back after for example a year on what you have achieved. It is amazing how far you can travel towards an intended goal if you focus and structure your task execution.

This, to me, is what makes GTD so powerful. It is a tool that allows you to laser focus your attention on your primary goal which is chipping away at your very own mountain.

Our internal audit reporting workflow

I have been meaning to write an extended article on how we develop our internal audit reports for a long time. Given that I'm out with a quite heavy flu and my voice is completely gone, this is as good a time as any to write this post. I will describe some of the key challenges we faced in developing our reports, the structure we created to answer these challenges and the tools we currently use. In other words, I will be describing our current process flow.

Now, you need to take in account that this process flow is not enitrely optimized yet. I'm still striving for the ideal situation where we can achieve the key objectives of our audit reporting with the least possible re-hashing of information. I'm hoping to incorporate this later in a markdown-LaTex based workflow. We're not there yet, and for now, this is how we function.

I also need to point out we used some of the currently available audit management tools. While they may be highly relevant for traditional internal audit functions, we need to be able to trust our systems in environments where internet access is something which is not guaranteed. In addition, I'm not too wild about the limitations in terms of process flows each of these tools imposes on the internal audit one way or the other.

Challenges

First, let's be very clear. Writing an internal audit report is probably one of the most difficult challenges an internal auditor has to face. Even if your audit execution went flawlessly, and you have everything documented in your workpapers, it still takes a lot of hard work.

Showing your work

Reporting is essential to our trade because for most of the "beneficiaries" of internal audit activities, the internal audit report is the only deliverable they will ever see of our work. In my past, I've done quite a few peer reviews, and one thing I noted was a tendency to over-report. To provide too much information on the work done, rather than on the conclusions reached. I think this is the subconsciousness of the internal audit report writer at work who aims to show the work done. Of course, that is not the purpose of the report.

Getting the message across

A good report should be about getting the key findings of the audit across to a rather diverse field of audit report audiences. If you want to get the message across, you need to be able to address multiple audiences with the same report. That is a significant order.
Let's examine some of the audiences we need to report to:

• The first and foremost audience of the internal auditor is the audit committee. In a lot of the discussions on adding value as internal audit this key audience appears to be forgotten. For true internal auditors, the members of the audit committee are and remain the main audience. They each have specific strengths in their individual fields of expertise. However, they are not necessarily versed in the finer nuances of everyday operations in your organisation. That's logical, they are not part of the day-to-day activities. However, this has a significant impact on the internal audit report. It means that the internal auditor, in order to make his reporting relevant, needs to pay particular attention to the readability. Facts and findings need to be stated in such a way that they are understandable for each member of the audit committee.
• The second audience is the group of auditees, in itself often quite a diverse group. Contrary to audit committee members, these are very well versed in the language and the practices of your environment. They may consider a simplification of their reality an entirely inappropriate way of presenting their challenges. As an internal auditor, you also need to cater to their needs. Even though the reporting requirements may be completely opposed to the reporting requirements the members of the audit committee have.
• The challenge of good audit reporting does not end there. A good audit report contains recommendations that may be useful beyond the limited scope of the area under audit. It's very important that the audit report, if it contains recommendations, describes these recommendations in a way that makes them usable outside of the limited area of the initial audit.

Other issues that sidetrack auditors writing audit reports

Auditors are quite often sidetracked by aspects of report writing that should not be relevant at all, such as layout, formatting etc. This may well distract them from paying appropriate attention to the content, to the story.

A good workflow does not distract the auditor from the content, but allows him to focus on it. We've developed a workflow which helps us in achieving this focus.

Essential aspects

Standardized Structure

To make a report relevant, the reader should be able to find his way in it. The best way to achieve that is to make it as recognizable as possible. We've been working hard on a stardardized structure for our audit reports. Note I write standardized and not standard.

An audit report needs to be recognizable, but not to the point that the form obliviates the content. To me, as Chief Audit Executive, an audit report works if it suits the purpose for which it was written. This means it needs to respond to the requirements of all audiences, which we briefly discussed above. Using a template with a structure which is recognizable, with specific minimal requirements in terms of what at least should be present without limiting more in-depth descriptions of the findings and their context works for us.

Short and concise

A second requirement is that the report needs to be as short and concise as possible, but not shorter. Of course, that's easier said than done, but we always keep in the back of our minds that it takes more effort to write a shorter letter. We actually ask ourselves two questions for every phrase in the audit report:

• The first question is "Says who?" This question queries whether we are very clear on the source as well as the trustworthiness of the information that we are sharing. This helps us ensure that the information that finds its way into the audit report is correct. If we cannot source a finding or a clarification of a finding correctly, we need to reexamine the finding and perhaps take it out of the report.
• the second question is "So what?" By asking this question, we make sure that this information really matters to our readers. If the point does not contribute to either the evidence, the finding itself or a related recommendation, we remove it.

Tools I use

All that is of course quite ambitious. If we had to keep this in mind in an entirely manual process, I'm not sure we would be able to do it, given our small size. Luckily, we have a number of tools that allow us to do this in what we consider to be the most efficient way possible.

Basecamp

The first tool we use on a daily basis is 37 signals Basecamp. While its use is not directly related to our audit reporting, it is one of the cornerstones in our workflow. Basecamp is our auditing hub where we develop, share and execute work programs, upload documentation such as files and scans, write dispositions of internal audit on audit tests executed, and exchange any type of information. Its very simplicity allows us to focus on the work at hand. And the fact it is so simple makes it easy to export for example work programs into a simple text file and carry it with us wherever we go. We've developed a standard work program template which is very easy to copy and adapt for the purposes of the specific audit, without forgetting all the traditional to-do's that are required in every audit.
The way we're working means that at the end of the audit field work, prior to reporting, all to-do have been documented out and checked off from their respective to do lists. The audit conclusions, which are audit findings, remain in a to do list for easy transport to the next step in the process. We also maintain a separate to do list per project for all the recommendations. Hence, anything that needs to find its way into the audit report will be present in the to do list in Basecamp.
Throughout the audit, documented in Basecamp, we identify the threads of our report. But even a bunch of threads a report do not make. So we need to do something with these threads.

Mindnode Pro

Even with a good work program in place, we often find that findings are sets of disparate statements, lose threads, about issues raised during the audit. And disparate findings need to be connected to make a comprehensible whole for the audience. A consistent story needs to be woven. But in order to weave, you need a pattern.
Mind mapping software, such as Mindnode Pro, is an excellent tool to put all those distinct pieces together into one whole. We weave our initial pattern with this excellent mind mapping tool. Once the initial pattern is established, we use OPML to transfer this to our next tool.

Scrivener

Which brings us to the core of our report writing process: Scrivener. If our findings are the threads, and Mindnode Pro allowed us to develop a pattern, Scrivener can be considered to be the weaving machine that allows us to bring those threads together according to that pattern to make a comprehensible story.

Scrivener allows you to focus in-depth on a specific paragraph or set of paragraphs to make them sound correct, while allowing you to keep the overall view at the very same time. I most often use the "index card view" which allows you to bring those disparate threads together into a story. The process goes like this:

• We export the pattern from Mindnode Pro via OPML.
• The OPML export is opened in our existing Scrivener reporting template. This template allows us to maintain the standardized structure without sacrificing the flexibility to weave a story. The pattern which we developed becomes part or a larger, well known and well understood pattern.
• All the information required to write out each of the findings is available to us through the OPML import. This information is the baseline based on which we write the individual paragraphs of the report. The tool allows us to focus on content and content only. We do not need to worry about lay-out or format.
• We use the index card view to look at the flow of the story. If the findings are not structured well, the pattern will make no sense, and the structure of the story needs to be reviewed. The index card view makes this easy. You can easily rearrange entire parts of the story without having to rewrite them.
• Once I'm happy with the overall flow, we export the whole to a Microsoft Word file for formatting purposes.

Given we need to have this draft report reviewed by multiple auditees before we can make it a final report, we still need to go through Microsoft Word. I hope one day to be able to replace this entirely with a combination of Markdown and LaTex to generate a PDF which complies with all aspects of our visual identity. As I am only starting to discover LaTex, we're clearly not there yet. It will likely take me some evenings on a mission in Africa to make some breakthrough there.

Conclusion

Combining Basecamp, Mindnode Pro and Scrivener as tools for documenting identified threads, developing a pattern and weaving the story according to that pattern has led to a workflow which allows us to focus on the content rather than on the sometimes highly inefficient externalities of the audit reporting process. While I wish I could do away with Microsoft Word entirely (not because it is a bad tool, rather because it is an inefficient tool), we are not there yet.