Cutting out the middle man: moving RSS stuff capture from Google Reader to ... nothing?

Google has announced it is retiring Google Reader on July 1st. An outcry has been heard across the internet. First they take over an ecosystem, then they destroy it ... the Borg could not have done a better job. Assimilation, then destruction.

I was among those who cried out over the loss of a good and accessible RSS feed aggregator. I'm not on the side of those who argue RSS is dead. Being able to read my articles at my leisure, usually on the train to and from work, is something I would be difficult to wean off of.

So I looked around at other alternatives. Feedly was one of the first, and honestly, the service is excellent, and even pleasurable. The iOS and the Mac in-browser apps are very accessible. So I almost did not give it a second thought ... until I started to consider the redundancy and inefficiency in my workflow.

My past RSS workflow

Consider my past RSS related workflow. I would have a Google Reader client, either Reeder (on my Mac) or Mr. Reader (on my iOS devices) which I used to "scan" articles. Rather than reading everything that had come in, these applications allowed me to easily discard 80% of the articles that had come in overnight or during the day and push the other ones to my reading apps, either Pocket or Instapaper.

Whenever I had time to read a couple of articles at ease, usually on the train or during the weekend, I would open up my reading app and go through the articles, reading some and deleting, reference filing in Evernote or pushing to OmniFocus those that needed to be dealt with.

Let's review that again ... I touch every piece of relevant information at least twice, sometimes three times. Google Reader app to trash can or reading app. Reading app to trash can, reference filing app or to do app. Was there no possibility to cut out at least one step?

Turns out there is. Let me tell you what I did.

My current RSS workflow

Enter a wonderful website called IFTTT, which you can find here. IFTTT, for IF This Than That, is a web solution that automatically pipes content from one place to another. That another place can easily be an application, especially a combined web app and iOS app.
I set up IFTTT scenarios for my most popular RSS feeds, which I "liberated" from the Borg, oops, Google, through their Takeout tool. The following is a step-by-step guide to setting up IFTTT for this.

My IFTTT scenario

Step 1 - Selecting the first trigger

IFTTT has a lot of so-called channels. A channel is an entry or an exit point for an IFTTT scenario, or recipe as they aptly call it. If you look at my screen, you can see that there is an RSS feed channel, which we will set up as an entry point.

Step 2 - Choosing a trigger

Each channel needs to have a trigger identified. What will cause IFTTT to act? What does it need to monitor. For the sake of this example, we will select "New Feed Item" as a trigger. Anytime a new item is added to the feed we will be monitoring, the recipe triggers.

Step 3 - Completing the trigger fields

The system now asks to identify a feed. I choose MacTuts+, an excellent website on all things Mac related. I got the exact feed from my Takeout xml which contains all my Google Reader feeds, and copied it to this feed url field.

Step 4 - Choosing an action channel

Once we have defined what needs to trigger the action, we need to define what we want done with the information. This is where our action channel comes in. There are an enormous amount of different things you can do with IFTTT. We will now copy the information the trigger provides to a reading application. For the example I use Pocket, but this can be configured with Instapaper, Pinboard or whatever channels are on the IFTTT list.

Step 5 - Choosing an action

In Pocket, I can actually only choose to save the trigger information for later. It pushes the information captured by the trigger to my destination web application, which is pocket.

Step 6 - Complete the action fields

The "Save for later" action allows me to defined the entry URL, which is pre-populated, and the tags, which I adapted so I can see when which feed provided me with which post. It also makes it easier to search Pocket for a specific date and feed.

Step 7 - Create and activate

And I end up with a recipe that will ensure that my RSS feeds go straight to my Pocket reading app, instead of making a detour through a feed reader app. While it may clutter my reading app, it is just another inbox where I decide what needs to be done with that information. I've effectively cut out the middle man.

Apple's maturity - Ubiquitous and imperceptible interoperability

I am assuming (most) analysts are not stupid

A lot has been said about the markets' reaction to Apple's financial statements for the past quarter. It's quite interesting and even a bit baffling if you take in account that this is one of the most successful companies ever, if not the most successful. And yet, analysts are not really getting excited about the stock. Rather the contrary.

Is this because analysts are stupid? I doubt it. It's too easy an explanation an explanation, and an emotional one to boot. All too easy to open oneself up to being accused of Apple Fanboyism. Some of the analysts can be very pretentious, for sure, but most likely the traditional 20-80 rule applies, as it applies to most of us. 80% of analysts are trying to do the best they can with the information given to them. The other 20% think they are better than they actually are. But then again, what else is new ... and this attitude is not limited to just analysts. There are quite a few journalists that are sick in the same bed.

So let us assume that the analysts are not stupid nor intentionally trying to sink a company. What is then going on? Why don't they understand Apple?

Developing a commodity within a walled garden

This is my 2 cents worth. I may be wrong, but I believe we are seeing an entire industry sector commoditized before our very eyes. And it appears to be happening within a very well defined walled garden.

I have a couple of friends that have Android phones. Most of them have Samsungs. I have a low budget Samsung as well, for my work. I can tell you there is a significant difference between one Samsung phone and another. There is some interoperability, but it is not ubiquitous, and it is not imperceptible either. The Samsung Galaxy S4 can do plenty things, but they are fundamentally and in terms of experience quite different from the Galaxy Note, or the generic Samsung Android phone.

Ubiquitous and imperceptible interoperability

Not so with Apple. I write on the train on my iPad, I continue while walking to work on my iPhone. I open an application, often the same, on my Mac, and continue where I left off. I switch machines, and iCloud or Dropbox allow me to continue.

Now, none of this is different with Android. There are Dropbox clients for Android as well. But the experience really is different.

Using iOS and OSX, there is no fundamental user end difference in environment, I do not need to relearn anything. And with the exception of the hosting services, be it Dropbox, or Amazon Cloud, or whatever, it happens within the walled garden Apple tends to. And tending to it they do, if you look at the malware comparison between for example Android and iOS.

But it is not just about that. Samsung cannot provide me with a fully integrated system. Neither can Google. And it's not that especially that last one has not tried. Let's not forget about those Chromebooks, hyped to the hilt. Sadly, they were very expensive and really went nowhere. Pretty much like Google Glass, right?

Let's be clear, to date, the only company that can actually provide this type of full integration across devices is Apple. But that level of interoperability comes at a cost.

Any compatible tool will do

If it no longer matters which exact tool I use, any (compatible) tool will do, as long as the tool fits within the context I am currently in. The actual tool switching effort is as minimal as possible. Even specs don't really matter that much any more.

An iPhone 4S or an Iphone 5 really does not matter. One may be a bit faster than the other, but both can do the work. For most 90% of the applications I use on a regular basis, it does not matter whether I use my Macbook Air or my iMac, or for that matter my iPad. As long as the specs allow my to use a system that has most if not all of the functionality of the latest release, I can work with those tools. I have no urgent need to upgrade to the latest and greatest, because it does not really matter.

And that business model is significantly different from Google and from Samsung, who do not appear to be interested in the longer term support for their tools. Rather, they want you to buy a new tool every time you are due for an upgrade. Quite interesting, really, and in line with the Android operating system update cycle (or lack thereof) for existing phones and tablets.

Emphasizing the identity of solutions

And where Samsung is looking to promote the identity of its products, Apple focuses more on emphasizing the identity of its solutions. This is who you will be (Samsung) versus this is what you can do with our tools (Apple.) While Apple offers tools for each occasion, often it does not matter which specific tool you use, as long as you consider it to be the right tool for your specific context. Apple tools are compatible with one another, and therefore the tool does not matter, but the overarching infrastructure does.

Personally, I am heavily invested in tools for my trade, tools that serve a purpose, but these tools exist for more than 90% only within Apple's walled garden. I have no need to go beyond that wall.

Safe and protected in that walled garden

And while the tool may not be the most exciting when compared to the technical specs of the latest Samsung, the solutions and their cross tool utilization most certainly are. Samsung to date has nothing like it to make my tool switch imperceptible across phones, tablets, laptops and desktops where I spend most of my waking hours. Rather, I currently feel safe and protected in Apple's walled garden that has built its reputation on understanding and serving the needs of its customers, even if those customers where not really aware of those needs.

At the end of the day, Apple is turning phones into pencils, pens, crayons and paper. And they are currently the only ones to offer an integrated set of tools to meet all of my needs. Even Microsoft never got there.

There are no distinct markets

Apple appears to be close to achieving that ubiquitous and imperceptible interoperability. No matter how successful they are in the smartphone and tablet markets, to us users these are not distinct markets. There is just us, looking for an integrated experience or at least an experience as well tuned as possible to our context. And that context may be a train, a plane, an operating theater. It may be a small village in the middle of Africa. And Apple currently is the only organization capable of delivering it.

This is why the this quote by Bill Campbell who serves on Apple's Board is so interesting and perhaps even irrelevant at the same time. Apple may bring its interface to intimate objects ... but to me and millions of other users, they already have.

My OmniFocus work perspectives

The investment pays off

OmniFocus is my particular GTD tool. While it has a significant and steep learning curve, I like what the tool can do for you once you get it configured right. Granted, it does take a while to figure out how it best functions for you. On the other hand, there is quite a lot of support available nowadays, from the blogs of Sven Fechner and David Sparks to the book of Kourosh Dini. So even if you feel apprehensive, you should not. You just need to be willing to invest the time in the appropriate configuration.

Defining "perspectives"

One of OmniFocus' key functionalities is its ability to define so-called "perspectives". A perspective is a set of selected contexts with defined conditions in several dimensions (only available actions, or all remaining actions for example) which allow you to focus on what you want to focus on.

To be a bit more concrete, if I want to focus on only work-related stuff and not be distracted by other things I need to do, I can define a perspective that shows me only work related "things". I purposely refer to "things" as it could be an action to be defined, a next action, an element with respect to which I am waiting for input from someone ... it could be anything, because that's how flexible a perspective is.

While a bit intimidating at first, perspectives are actually quite easy to define. One very important remark: you will need OmniFocus for Mac in order to define perspectives. Once you have defined a new perspective and synced your database, you can use defined perspectives on any OmniFocus application, be it on your Mac, your iPad or your iPhone. The definition, however, is only possible on the Mac.

On the shoulders of giants

As I said before, you cannot read this without referring to the work done by Kourosh Dini, who by my standards is a demi-god, or David Sparks or Sven Fechner. These guys have published a lot on OmniFocus and how to use it. You can find these interesting approaches back on their blogs, and on the Omni Group website. Do visit these sites, as they will give you a lot of background information on how to configure OmniFocus to your particular liking. Pretty much all of my ideas on using OmniFocus can be traced back to them, or even further back, to Merlin Mann. They are the giants that are standing there, I just got on their shoulders to reach the cookie jar. That being said, and without further ado, let's look at my perspectives for work.

My work perspective structure

I actually use three distinct work perspectives, as follows:

• to do @work
• today @work
• next actions @work

Let's examine each of them in more detail

My daily planning perspective: "to do @work"

This perspective is the last one I open every work day, and I try to open it only once every work day, and once each weekend. This perspective is the core of my daily planning, as it should contain everything that needs to be done in all my work related contexts. All remaining actions, whether are next actions, available actions and blocked actions, but not closed actions, are visible in this perspective which is organized by project.

My to do @work perspective

Once every day, usually in the evening on my way back from work, when I have about an hour of downtime on the train, usually after I cleaned out my OmniFocus Inbox, I go through this perspective and work through the remaining actions per project. It is pretty much a daily review* activity. I review whether all my actions I expect to find per project are there, I validate, assign or reassign start dates, which pushes forward my actions to a realistic time to start executing, and I review and assign due dates. My due dates are hard due dates. These do not reflect intents rather than obligations. If a task is not done by that date, I'm in big trouble. For more on that, I refer to David sparks excellent article.

This review really clears my head of all the stuff I have built up over the course of the day. It's a cleansing ritual, almost. It gives me reasonable assurance that when I open my today at work perspective the following morning, it will be an accurate reflection of commitments and obligations I have to deal with that specific day.

The morning perspective: today @work

When I wake up, I usually take the time to go through the RSS feeds I try to follow. These give rise to a number of to do's which find their way into my OmniFocus Inbox. I've written about that approach [here] [1]. Once I get on the train, I usually reserve about 5 to 10 minutes to go through my today @work context in conjunction with my agenda. Long live the iPad for that.

My today @work perspective

This is more a sanity check than anything else. Any meetings which I need to attend have been planned in my agenda. Anything I have engaged myself to doing during the day that is not a meeting I find back on my today @work perspective. Like to do @work, this perspective is organized by project. In combination with my calendar, the perspective shows me whether I have been overly ambitious.

However, and this is an important step in my process, I also define two big rocks which I will flag in addition to possible due dates. Depending on their nature, I may even plan them into my agenda for execution, but that really depends on the nature of the actions. These so-called big rocks are the two (usually significant) tasks that I want to get done today. These are the tasks I commit to doing once I get to the office and right after lunch. This is why I avoid meetings before 10 AM if I can help it. It allows me 90 minutes of focus time before I get into activities such as meetings which usually lead to task collection, not task execution.

The focus perspective: next action @work

This is my true pedal to the metal perspective. In this perspective, which is organized by due date and context, I only see the next actions across all of my work.

My Next Action @work perspective

It is a real focus perspective. There are no distractions. There are at most three tasks on there, that's it. Anything else has been cleaned off my current to do plate. I liken it to having a clean desk before breaching a new task, a true OCD trait. I need to have a clean workspace before I can get to work on another task. I need that space as much in my physical environment as on my desktop and in my applications.

Having a to do list of concrete next actions in front of me which allows me to really only focus on what I need to focus on, based on well thought out process that gives me a reasonable assurance on the completeness and timeliness of my next actions gives me the necessary peace of mind to focus without anything yelling for my attention in the background.

In conclusion

Combining these three perspectives allows me to have the best of all worlds. I have a regular moment where I check complenetess across all my projects (to do @work), a regular time for checking feasibility and determining the big rocks (today @work) and a narrow focus perspective as well. It helps me staying focused on what needs to be done without losing track of everything around me.

About muscle memory and luck

Admiration and jealousy

We admire people who appear to be able to perform certain feats as if with no considerable effort. And where there is admiration, there is often jealousy. We tend to get jealous of people whose life is apparently without effort.

We look at these people, and we compare their baseline competenties to our own. We feel we are similar, and often even better than they are. We are more intelligent, we have more strength, we have more talent ... yet they have, and we have not. It is not fair.

It is not about fairness

The point is that fairness has little to do with it. Because what we often fail to see is what went before. The entire evolution these people went through. The countless hours of effort, of failure, of doing it again, and again, and again. The hardship of the apprentice.The difference between them and us is often that they have done the work.

The fact that there are so few of them is not by definition an issue of scarcity of opportunity. It is more a witness to the fact that few of us have it in us to actually do the effort. We crave the results but are afraid of the pain.

Almost everyone you admire has done the work

Ascribing Picasso's success as just luck is a failure to understand the entire evolution of Picasso as a painter. Einstein did not just happen to discover the theory of relativity. It was not just something someone had left lying around.

We fail to recognize the effort that went before. Before a dancer can intuitively dance a piece, and put his or her heart into it, it takes weeks, months and years of diligent practice, in front of a mirror, with only few people seeing it. It takes getting up at ungodly hours of the morning, working, sweating, for little to no direct payback.

It's about the journey

Which brings us to another point. Few of these "gifted" people do it for the payback. Just as stated in this excellent IBM Linux commercial of 2003, which still sends shivers down my spine, "there is not much glory in poetry, only achievement." And that goes for pretty much anything. These people do it for the achievement, out of love for the game, or love for the journey.

GTD has never been about the shortcut

Which brings us to GTD. I truly believe GTD is more about diligent practice, about the creation of muscle memory of dealing with the myriad of things that get thrown our way, with stuff, in order to make it look easy. GTD is a system, and approach, which allows us to lead a better life.

But whether you use GTD or not, you should never forget that there are no shortcuts. Not really. There are practices which help you instill a commitment to a certain activity with no direct or visible payback. But there are no shortcuts.

Getting good at life

You want to get good at your life? Practice and perform at the same time. You do know what that is called, right? I believe it is called living.

How our failure to fail impedes our success

Sven is onto something

I just read this post by Sven Fechner. Sven, for those who do not know of him, is one of the most prolific and relevant bloggers on personal productivity. He also has a day job working for a large multinational. I admire this guy, because he achieves what most of us only have the ambition to do. Working a full time job and still blogging on a regular basis.

In his post, which is excellent in its entirety, he speaks with insight and humility about failure. I would like to quote the whole post, but this phrase resonated the most with me ...

it feels more credible now that the option of failure has become an actual result.

He touches on an aspect that I know to be true. Most of us have truly forgotten how to fail. Because we are afraid to fail. There is no longer any merit in failure. And this is different from how things used to be.

We can no longer recognize the merit in our failures

There used to be real merit in failure. While achieving the outcome was important for any project, the road to that outcome was important as well, perhaps even more important than the ultimate outcome. It was an integral part of learning, very much essential to it. And while failure still constitutes an important part of learning, public failure is no longer acceptable. It has become something to avoid.

Let me illustrate failure has become culturally unacceptable in Belgium. Fewer and fewer middle and high school students are receiving non passing grades. Even if they have not done the work and have not learned what there is to be learned, they are not necessarily being held back because it is considered to be bad for the self image of the child. Instead, rather than failing, they are being offered alternative educational choices. They end up failing and not even being aware of it. Or rather, they do not fail, but we change the intended outcome without allowing them to understand what they are not good at. The road is no longer relevant for them. It's just something they need to go through.

A pressure to perform

It does not change once these people get into the job market. The pressure to perform, to show results, to achieve outcomes, any outcomes on young people is enormous. The pressure to keep delivering outcomes on older people is even bigger, because there is the stress of being rendered irrelevant. In such environment, the acceptance of failure is low to non-existent.

We fail to provide an adequate proving ground for people. We fail to allow them to learn. We fail to allow them to actually learn to understand life. And that might just be our biggest failure.

The pressure to perform and to remain so is ever present. And what we fail to understand is that we deny ourselves the opportunity to learn. And denied the opportunity to learn, we will not get better at anything. We risk to get significantly worse.

Outcome creep

We need to actually to do the work, not avoid it be redefining our outcomes - outcome creep - along the way for no other reason than our inability to achieve them and our fear of looking bad. Not failing is easy, especially if your are not doing what you should have been doing.

This is why I salute Sven, who bears the mark of a true professional: someone who commits wholeheartedly even if failure is a possibility, because it is required, because it will teach us.

I'm an internal auditor. Looking for failures is my job. But I can tell you there is a real difference for me as an internal auditor between people who have truly tried and failed and those who never have. If you go in to a project or a challenge, understanding full well that it can go wrong, but committed to do the work, I consider you to be a professional, because you know the learning is for 99% in the journey, and only for 1% in the result. The learning is in the hard but objective assessment of what happened and how to improve it.

In development aid, we have a name for that. We call it capitalization.

However, if you go in just to get lauded for the results, without a willingness to learn anything about the process, about the work and yourself, you will remain merely an amateur.

Solving the problem

A correct application of GTD provides a starting point for solving this problem: whenever you approach a project, you need to look beyond the concrete actions at what the ultimate objective of the project is, even before you start working on it.

Defining clear and measureable outcomes will help you in being accountable as to the ultimate outcome and as to your learning in the process.

Let me rephrase that: be wary of projects without clearly defined outcomes that are measureable. Be wary of people who structurally avoid committing to them. Rather, go with professionals like Sven, who are willing to admit their failures. I'm sure he learned more than others not willing to admit their defeat in a project. I know I did every time I failed. And I learned a lot and continue to learn every day.

In closing - Acumen's Manifesto

The Acumen Fund recently published this Manifesto. I've taken the liberty to copy what I consider to be one of the most essential parts of it. It defines how they look at their mission, a mission close to my heart, as I work in development aid. Here it is:

It thrives on moral imagination: the humility to see the world as it is, and the audacity to imagine the world as it could be. It’s having the ambition to learn at the edge, the wisdom to admit failure, and the courage to start again.

An assessment of my morning information gathering and capture mechanisms

Information is all around us

I've likened it to wifi or mobile network radiation. It's there, but you are not really aware of it most of the time. Most of it will be completely irrelevant to your activities of that given day, or even your life. Some of it will be indispensable. But how to know which is which?

It gets even more complicated. We live in a day and age where we have the luxury, the opportunity, to tune into the stream of consciousness of the planet at will.

Think about this for a minute: at any one time you can gain access to what's top of mind for a lot of people you admire, as long as they are online.

A Catch-22?

There is a very big risk in that it may be the only thing you do, all day long. It can be an excellent excuse not to actually do some real work. But, on the other hand, if you don't tune into the right information flows from time to time, you may miss some very interesting ideas that are being born and shared. Again, how do you know when you need to do what?

So is this a catch-22? The answer may not please you, in that it is not a resounding "no." Rather, the answer is, as those are, more complicated. Let me illustrate by going through my daily information gathering and the capture mechanisms I employ to deal with that info. Be aware that I do not have the best possible solution to these problems, but I try my best to be both in tune with the planet (right) and in charge of my life and work. A delicate balance, sometimes.

My daily morning routine

Waking up

When I get up in the morning, around 6.15 AM, I usually need about 30 minutes to really wake up. There is no better way to do it than with a cup of coffee and Reeder, which I use as my RSS feed aggregator on both my iPad and my Mac. I scan through what the blogs decided to deposit on my little stretch of mental beach.

So what now Google has announced the killing of of Google Reader, I hear you ask. I have a vivid imagination. The short of it is "Feedly", the long of it is I am waiting for Reeder to come up with a viable solutions. Tick Tock ...

Some of the information I pass without even looking, some of the information I think may be relevant but not really urgent gets pushed to either Instapaper for reading or Pocket, which I use for videos I want to look at later. Most of these are, in Steven Covey's parlance, PC or production capability related.

Some information is likely to be relevant for me during the day, either to share with colleagues (ODI articles or any blog article by Chris Blattman) or related to my own production during that day. These get pushed to Evernote. They all get pushed to my Evernote "Today" folder, which is another inbox but one that gets visited every single day.

Going through the today folder, which I do at work, mainly involves tagging in Evernote. Feasible from my laptop but also from any of my i-devices. I recently started to use a good trick which I blogged about earlier. I've set up my home iMac (online all the time) to run an AppleScript on an 15 minute basis using Python. Marking the article with a review tag in Evernote generates an Omnifocus entry with a link to the Evernote clipping. The information finds its way into my todo list with limited intervention from my side.

Overall, I achieve this initial phase of gathering stuff into inbox items with a minimum of friction and resistance. And it wakes me up.

On my way to work

I shower, kiss my wife and kids goodbye, and I'm off to work. My podcast feeds have been synchronized the prior evening using Downcast's excellent location based updates so in my commute between home and the train station I'm listening to some of the podcasts I try to stay up to date with. Depending on the nature of the podcast, the podcast information either gets pushed to Instapaper or to Evernote. I consciously switch off the podcasts on the train. The train is for reading or writing. I use Notability in a workflow I described earlier. I switch back to the podcasts once we pull into the station, as I have a 10 minute walk to the office. In case there is some interesting stuff on the podcast, I can forward it easily to my OmniFocus Maildrop and deal with it when I get to that inbox.

In the office

When I get into the office, I usually try to get one big rock done before I open my email program. During my weekly review I try to assign one to two big rocks, activities that take one or two 45 minute segments, to each of my days of the week, and plan accordingly. This is not cast in stone, but I try to get something concrete done before I deal with the nitty gritty of my inboxes. It may seem trivial, but to me it is anything but. Getting at least one thing done that aligns with a higher altitude GTD goal really helps me in focusing on the doing. I keep that quote on Zuckerberg's desk, "Keep focused and keep shipping" in the back of my mind. Wish someone would build a nice wallpaper for my iPhone 4 for it ... I'll keep looking.

After the first big rock, I deal with the inboxes. Typically these are business mail (physical and email), Evernote and OmniFocus, in that order. It takes me about 45 minutes to an hour to go through that stack, on a daily basis. This is what happens, closely following David Allen's prescriptions:

• Physical mail gets thrashed or scanned and thrashed. Scans are sent to Evernote, to my Today box.
• Email gets deleted, dealt with (2 minute rule) or sent to OmniFocus. I change to subject line to a concrete next action or a PR + a title, indicating I need to create a project.
• Evernote Today files get deleted, filed for reference or sent to Omnifocus for further processing. I change the title to something appropriate, again either a concrete next action or a PR + a relevant title if I need to create a project.

Note that while I try to apply a "Touch every bit of information once" approach, this does not always work. When it interferes with my routine, I chose to not comply with the canonical GTD approach and adapt to what works for me. Once I realized I could do this (and so can you) it made my life a whole lot easier!

• OmniFocus next actions get treated last, but not least. Here I prune mercilessly. If I assign it to a project, it needs to add value by leading to the achievement of the clearly defined outcome of that project. If it does not, I kill the task. This activity also allows me to ensure appropriate phrasing of either next actions or projects. I simply built two textexpander snippets based on the correct verbs to define next actions and projects. This way, I ensure I create relevant next actions and relevant project descriptions. For your information, I check on a weekly basis whether new projects have the appropriate outcomes defined. If not, I think hard about what I want the end-state of the project to be. I also question whether or not I can realistically achieve this end-state with the means at my disposal. If I cannot, the project gets terminated.

This way, I have learned to say "no" to a lot of things. They do allow me to say yes to those things that matter, such as my family, and time with some wonderful people I have had the pleasure of encountering.

Using programme and project management systems in development aid

Please note this post talks about an aspect closely related to the work I do on a daily basis. The ideas below are my personal opinion on a specific opportunity in the context of development aid in general, and do not specifically relate to any organisation I am associated with or working for. These ideas are a reflection on what I see as a very important opportunity in our field of work, coming from a programme and project management background.

In a reality of reducing development aid budgets, proper due diligence becomes even more of a necessity than it was before

Western governmental aid budgets are becoming more and more tight. Traditional bilateral development aid is slowly but surely being replaced by multilateral and privately sourced aid. A well known example is the “Bill and Melinda Gates Foundation” that has means which dwarfen the development aid means of many a nation. In this changing reality, development aid agencies are transitioning from a state of monopoly to a state of competition among peers. While they are - often even by law - the sole responsible for delivering bilateral aid, they are in sometimes dire competition for access to multilateral and privately sourced aid. As this aid often goes to the “best” party, for a certain set of conditions underlying best, they compete to be the best in certain sectors and/or geographical areas, or a combination thereof.

In development aid context, “best” has most often been defined as most competent. And development aid competency is a function of the expert profiles you can attract as development agency. Certain agencies have a tradition of a presence and hence a competency in certain geographical areas and certain sectors. But now more and more, the reign of the sole, Western, embedded expert appears to be over. Not because the perceived value of the expert has gone down, but because the need for “business” management in projects is growing. Especially private sector funds, as part of foundations or as part of large Corporate Social Responsibility programs of multinationals, asks for timely, complete and accurate due diligence, and will hold the incumbent “manager” responsible, whether or not he feels responsible.

In other words, the accountability requirements regarding development aid have significantly increased in the past years. Is the development community ready, willing and able to answer this call?

Managers and experts on a collision course?

Even since before the early 1960’s we have become aware that the ultimate goal of development aid, realizing impacts, is notoriously difficult to measure. After all, quite often a development project is only one piece of a larger puzzle that eventually will lead to a certain aimed for impact on the beneficiaries. Approaches such as the logical framework have allowed us to link effort (input) with outputs, outcomes and impacts. Practitioners however are very conscious that this effort at quantification has its inherent limitations. New initiatives at the fringes of the logical framework, such as M&E (measurement and evaluation) or the more aggressive Value for Money initiatives try to embed a more quantitative approach into the traditionally qualitative environment that development aid is. We are just barely starting to understand how such initiatives and measurements can contribute to the ultimate goal of development projects, which is creating a better situation for the beneficiaries than the initial baseline.

I am convinced development aid expertise and management need not be on a collision course. Rather, traditional concepts of project and program management can actually aid an expert in both delivering better managed results and have more time to dedicate to the project content. And this is why these experts were engaged to do in the first place.

In essence, if properly applied, rather than making life for a development expert more difficult, project management methods and tools can lighten their administrative burden to the minimum amount required, in effect freeing their hands to work on the content.

Programme and project management at the crossroads of management and expertise

But how can project management contribute to increasing the quality of a typical development project? In order to determine that, we need to first understand what project management brings to the table. After that, we can examine where it can add value in a development project.

Let’s look at Wikipedia’s definition of a project:

A project is a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value.

Taken this definition, most of what we consider to be (bilateral) development aid are projects. Of course, this does not tell us anything about how you execute a project. This is where project management comes in. Again, according to Wikipedia:

Project management is the discipline of planning, organizing, motivating, and controlling resources to achieve specific goals.

This gives us a bit more information on what we need to focus on when “doing” a project. There are a number of known project management methodologies out there that each have their take on how to “do” a project. While they are not fundamentally different, the language used can become rather technical and hence confusing.

PRINCE2, one of the better known methodologies, uses themes as a description of aspects of a project that need to be taken in account throughout the project. In other words, throughout the different activities, as listed in the definition, the themes provide approaches to answering the key questions which need to be addressed by a project. The PRINCE2 themes, which I merely use as an example, answer the following questions with respect to a project.

• Key aspects or themes in PRINCE2:
  • ”Why?” do we engage in this project? This question is usually answered in the project brief which we find in pretty much all development projects;
  • ”Who?” will be executing the work? Again, a question that is traditionally answered in the project definition phase of a development project. The advantage of the project management theme is that it continuously questions the relevance of the profiles currently in play;
  • ”What?” will be achieved in the project? While the what is almost always defined in development aid, project management stresses the need for common understanding of the final end state by all parties. It also focuses on how the project manager is to aim for the delivery of those requirements. What is fundamentally about understanding and about attributing responsibilities.
  • ”How?”, “How much?” and “When?” Establishing the what will not amount to much if the concrete way forward is not clear. It’s my experience that apart from a broad budgetary assessment, this phase is often underdeveloped in development projects. This is where project management can really make a difference between a nice concept and a succesful project result. I do need to point out that even if we tend to properly define how and how much, and do a good guess at when, the when factor is a very challenging factor, as most development projects need to deal with important and very influential external factors, such as weather (in agricultural projects) and process aspects, such as appropriate management of public tender procedures in partner countries.
  • ”What if?” things are different than we anticipated them to be? Even if the how is clear, the assumptions underlying the how may not hold. Again, this is especially true in less controlled environments, such as fragile states in which development aid is being delivered. Assessing the risks in a broad, structured and timely manner as they may impact the ultimate objectives of the development project will result in a higher likelihood of projects being delivered in scope, budget and with the required quality.
  • ”What is the impact?” of any changes in underlying assumptions? If risks manifest themselves, they will impact the projects. Within a context of limited available budgets, if we need to resolve issues, other aspects will need to be adapted as well. Assessing the impact, planning for change and appropriately communicating this to the relevant stakeholders, especially the partner, is not only a sign of good project management, but of respect as well.
  • ”Where are we now?”, “Where are we going?” and “Should we carry on?” is all about using hard and soft information to assess the continued relevance of the project. Monitoring and status reporting should not only focus on the ultimate goal to be achieved, but on clearly established milestones across the different project dimensions of scope, budget and quality as well.

An opportunity rather than an issue

Now, rather than falling into a trap of criticism and assessing development projects through a project management lens, let us consider these questions and who would be best placed to answer them. In my mind, this would best be the content expert, especially if he works closely together with his team of local and international collaborators. Hence, even if these questions are often not fully answered in a comprehensive manner at the beginning of a development project, I believe this to be more related to the need of adding on a structured project management methodology to our traditional the logical framework rather than to the lack of competence of the people being put in play.

Integrating traditional programme and project management techniques into frameworks such as the logical framework could actually enhance development projects to become best practices in any project management context, by optimally leveraging what is already present.

In conclusion

The need for a strict but efficient project and programme management framework in development aid grows. The increased accountability requirements of public money well spent is a key driver, but certainly not the only one. Both multilateral and private sector investment in development aid is on the rise, and with these investments comes a significant experience with and expectation of traditional project and programme management.

Rather than seeing this as a threat to the development aid community, I believe good project management can increase the quality and the relevance of the current development projects, especially if integrated with tried and tested concepts we know very well. The chasm that is being perceived by some is not really a chasm at all, but more of a small fissure that can easily be bridged by appropriate training and the right tools put in the right places.

And ultimately, I firmly believe that rather than increasing the administrative burden for an often already overburdened expert, it may actually reduce them, especially if aid agencies and their donors, learn to optimally use the information that is generated in traditional project and programme management systems.

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.

Compliance with rules and regulations depends on the perceived fairness of those rules and regulations

The challenge of compliance

Compliance is a traditional challenge that has associated costs. Quite a few rules and regulations, whether internal to an organization or nation-wide as imposed by a government, are notoriously difficult or costly to ensure compliance with. Having a rule translated into a procedure somewhere in an ISO manual or a law is one thing. Getting it applied is another.

Take speed limits for example. Few people will, when confronted with an empty or almost empty road, stick to the speed limits as indicated and 'enforced'. And unless you are unlucky or not aware of where fixed and mobile cameras are placed, the likelihood of getting caught is quite small.

Compliance as a function of perceived fairness

Why do people speed when given the opportunity under what they deem to be the right conditions? Because they believe it to be fair to do so in case:

• the opportunity presents itself;
• the risk is limited;
• the risk is mainly to themselves

Their concept of "fairness", however personal or flawed it may be, is taken into account when making the decision not to obey to rules.

Let's look at another example. What about taxes? The compliance situation appears to be comparable. As long as we pay an amount equal to or, depending on the variables, in line with people within our peer group, we will pay, or not. This, by the way, accounts for a higher degree of perceived compliance issues in certain geographical locations, especially in those with a consistent demographic character. And for total clarity, lower income does not align with lower compliance.

Increasing the perception of fairness

The challenge to government or any organisation for that matter: if people or collaborators are willing to comply with a rule or a regulation if they perceive such a rule or regulation as fair, how can you, as a governing organisation, increase this perception of fairness?

I would like to propose three distinct but interrelated elements, which I believe to be a necessary part of the solution:

• The rule should be easy to understand, not only in terms of the content itself, but also in terms of why compliance with this rule is so important. This means that prior to asking for compliance, you need to clearly understand the very concrete consequences of the rule to those subjected to it;
• The rule and they way how we want compliance to work needs to be clearly and regularly communicated, in an understandable language with very concrete examples. What is very important when communicating is that the rule should be put in a wider context ... If we are subjected to compliance, we should not be treated as children, but we need to be informed on what and why of a rule;
• Without ignoring the need for continuity, rules and regulations need to be limited in period of applicability. A so-called sunset clause with a required consultation of implicated parties prior to renewal of a rule is an approach that can further increase perceived fairness. If all implicated parties can make suggestions on improving the efficiency of a rule we recognize their input and can increase direct capitalisation on the lessons learned. And let's be clear, there is a lot of learning in first applications, which can lead to significant improvements in the way in which a rule is defined, which can improve compliance.

Adopting these simple elements may increase compliance without significantly increasing the monitoring and follow-up costs. An upfront investment will more than pay-off in increased compliance in the long run.

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.