Regarding unknown unknowns, hindsight is 20/20

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

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

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

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

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

Making an unknown unknown

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

Aspect 1 - Time to onset

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

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

Aspect 2 - Available expertise

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

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

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

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

Aspect 3 - Required width and depth

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

In conclusion

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

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

Chipping away at your mountain

Playing the piano

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

The core of GTD

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

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

Higher altitudes determine task relevance

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

Time is a context

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

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

GTD is not (yet) doing the work

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

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

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

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

Our internal audit reporting workflow

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

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

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

Challenges

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

Showing your work

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

Getting the message across

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

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

Other issues that sidetrack auditors writing audit reports

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

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

Essential aspects

Standardized Structure

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

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

Short and concise

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

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

Tools I use

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

Basecamp

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

Mindnode Pro

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

Scrivener

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

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

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

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

Conclusion

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

Is goal management in a public sector environment relevant?

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

Defining a goal

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

Managing goals

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

What management entails

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

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

Goals of a public sector organisation are not dynamic

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

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

The relevance of the strategic cells

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

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

Ego

After watching the blockbuster movie "Margin Call" a couple of days ago.

In our almost continuous quest for yet even more money and still more fame, or in some cases notoriety, we should, no we need to ask ourselves "to what end?" on a regular basis.

If the answer has structurally become "to satisfy my ego" or anything remotely similar, perhaps we need to consider the potential impact on those around us.

Quickly send task-related emails from your mail.app inbox to Omnifocus with the help of indev's Mail Act-On, MailTags and Omnifocus' MailDrop

Yes, I cannot think of adequately short titles for blog posts. The quick hack I cobbled together during lunch today is no doubt not extremely up there in hacking terms, but I'm quite proud of it myself. Which is why I can't wait to blog about it.

The itch I'm trying to scratch

I have mail incoming in my mail.app which I need to do something with. So I should send it to Omnifocus' inbox for further treatment. Since the OmniGroup released their MailDrop feature (I believe still in public beta) for Omnifocus and they've been kind enough to include me, I've been able to send mails with attachments to Omnifocus (OF), putting all the relevant documents inside my OF database. The itch was that this was not automatic at all. I needed to forward each individual message to my Maildrop email account. Of course I started to "forget" to send stuff to my Omnifocus inbox, so I had stuff at different places, which made my weekly review that much harder. Not frictionless at all.

Enter indev's Mail Act-On and MailTags

I had tried to solve the issue by working with Mail.app's rules, using flags to forward mails to my Maildrop account. However, as I found out, you cannot use flags to trigger a rule in Mail.app (as far as I know). So I needed another solution.

A couple of months ago, I had invested in indev's Mail Act-On and MailTags applications which enhance Apple's Mail.app functionality in order to optimize some of my email related productivity, but I still had to get to the bottom of the usefulness of these applications.

I played around with the settings a bit during lunch, and suddenly realized that these applications enhanced the rules available to me in Mail.app, even the "inbox" rules, the traditional rules in Mail.app. While I still could not work with the flags, the combination of MailTags and Mail Act-On allowed me to tag a message which would then, based on that tag, be forwarded to my Maildrop.

Problem solved.

The short hack in-depth

1. I installed Mail Act-On and MailTags (note these applications are not free nor cheap, but you can on occasion find them in bundles, which make them affordable);
2. In Mail.app preferences, I make a new Inbox rule, called @Action to Omnifocus;
3. The rule is simple: if the rule detects a message with a MailTags keyword which is "@Action", easily assigned via MailTags, it forwards the message to my Maildrop account, moves the message to my archive, and stops further processing.

It takes at most a couple of minutes, but I then find the message, with attachments, in my Omnifocus inbox, only to rename (see an earlier post on good next actions), assign a context and a project, and deal with ... later.

You can find a screenshot of the rule below.

The @Action to Omnifocus rule

What defines a risk model?

This post is a repost of a short article I wrote in 2009, on my then riskguy blog. I've rewritten it to more appropriately reflect my ideas on this, as of course over the past years this has evolved. I've revisited this article because it has become actual again in the ongoing discussion on whether or not to use a risk model.

In a lot of the articles on this blog about internal audit or risk management, I refer to the Risk Model or the Risk Identification Model, or Risk Model, but what defines a risk model to me?

The following are to me the two defining elements of the Risk (Identification) Model, with some explanation:

It’s a Model

It is a structured representation of a reality. It is important to realize that the map, or the model in this case, is but an abstraction of, and therefore not the territory. It is a representation, a ‘simplification’ for easier use or access. And as any simplification, it does not contain all dimensions or aspects of the real thing. We use a model to make it easier to deal with or to handle a complex reality.

So whatever way you look at it, you cannot ever blame the model for its inadequacies or its incompleteness. As a risk manager, you have the responsibility to make sure the risk model you use is adequate across all the dimensions you are using it for. In effect, having a subject matter expert looking at the model for each of the dimensions you will be using it for (operational, financial, strategic, human resources ...) is highly relevant and can only add to the relevance and the pertinence of the model.

It serves a purpose and only that purpose: identifying risks

The model is to be developed for and aims at supporting the user in identifying risks which are relevant to him or her. The structured representation of a model reduces the reality to a set of risks (the concepts) out of a risk universe (a set of all possible risk events which could occur) with respect to the objectives of the area in scope such as an organization, a division, a set of processes, a process, a sub process or a set of activities.

So, if you want to use the model for another purpose, it cannot serve as such. Much like you cannot use a map of London which is useful for a car as a means of finding public transportation. Other purposes, other tools.

A definition for a risk model

Thus, in short, a Risk Identification Model or Risk Model is a simplified representation of the risks to the objectives of the in scope area, for the purpose of identifying those risks.

What is the problem you are here to solve?

This short(ish) post is a follow-up to my last post on GTD and the higher levels of altitude David Allen speaks about.

What I have learned, through journaling, is that there is a common background melody to my life. Whatever I am involved in, and if you look at my LinkedIn profile you can see I have been involved in quite a number of activities, both professional and personal, I find that melody back.

Now, the interesting thing is that I never even considered the existence of this melody, this common theme to all my endeavours, until I started journaling. There was an occasional glimpse of that theme, but my consistent failure to identify it has actually led to quite a few instances where I was actively working against that theme, thinking I was doing a good thing.

Self-reflection, while it should never be taken too far, is a great means to identify that very soft but always present melody. That melody which some call your inner voice and some find in meditation practice, something I consistently fail at, is at the core of who you are and provides you, day in and day out, with an answer to the question: "What problem are you here to solve?"

A word of warning. You may be surprised about what you can hear yourself saying when you really listen. It may actually be an answer you were not expecting. It may certainly not be about following your bliss, about achieving riches and becoming famous. It may even not be about being 'happy' Then again, happy is a fleeting emotion and may well be seriously overstated.

However, what I have found and believe to be true is that ultimately identifying your melody, what makes you tick, your inner voice, and then going on that voice to try and live consistently with that voice will lead to achievement, and meaning.

Enjoy your search and your travels. I do. You see a reflection of it whenever I write a blog post.

A journaling workflow for better GTD higher altitude focus

The challenge of journaling

For those of you who ever tried their hand at journaling, you probably found out it is hard, especially after a while. It takes time and it takes effort. It requires commitment. Not unlike blogging or any other writing activity. And like GTD, it's a wagon you can very easily fall off. So why bother?

The relevance of journaling

Journaling is a wonderful practice if you want to get to know yourself. By taking the time to understand what drives you, you may discover you are not what everyone else ever told you you were. If you get to that very realization, by the way, you are already further in your quest for self-understanding than most people will ever get. Knowing that you don't know "you" is a very sobering realization. It should also put you on the road to finding a trustworthy way of meeting yourself.

Now, and that's the good part, you are the only "you" around, and thus you are ideally placed to determine what "you" are about. No one else can get to know you better than you. Pretty much because you are going to be the one who will be spending the most time with you. And that's quite a lot of you's in a single paragraph.

A whole new you

In order to get to know yourself, you need to take the time to listen to yourself. To listen to yourself, you could try meditation. Again, not an easy practice. Journaling is another excellent way to get to know yourself. And you may actually surprise you. Isn't it wonderful that there is someone so close to you you now can get to know?

But remember I said journaling was not easy? There are ways to make it easier.

Day One as the first step

For me, the first step was to start using good journaling software. Now, in a pitch, a text editor will do, but I really like the Day One application. It provides you with multiple ways of getting your information into the system.

Now, most of what you will read below is thanks to the following excellent post by Sven Fechner (SimplicityBliss) in which he refers to this post by Rob Trew. Bear with me while I explain how I use what they built:

My journaling set-up

Let me take you through my setup. I use Day One in combination with two “customizations”. The first is about getting what I have done that day into the Day One application. As my GTD system is built on OmniFocus, I needed a way to get completed OmniFocus tasks into Day One. Combining Hazel, Day One's CLI (Command Line Interface) and Rob Trew's excellent shell script which loads an overview of my done Omnifocus tasks into Day One. Read Sven's blog post and Rob's detailed explaination on how to set it up.

My journaling workflow

Now, based on this script, I get a markdown formatted entry in Day One for every done task I checked off in OmniFocus during the day. And every evening, usually on the train back home, I go through this list of completed tasks and I add some information on the relevance and my personal appreciation of the task. This is very important: it is not about the task, but about how I felt about it. To be complex about it, it's meta reflection time. And a train ride is often the best moment for meta reflection. But the workflow does not end there.

Each evening, or sometimes early the next morning, I launch a textexpander snippet in Day One. The snippet is based on this Lifehack article by Paul Sloane. The article provides you with a set of five questions to ask yourself each day. What I do is I try to go through these questions and answer them totally honestly. Honest answers to these questions allow you to get to know your deep drivers.

The relevance of journaling for GTD: better understanding of 50K and 40K levels through better understanding yourself

What really pays is to revisit what you have written during your weekly review. It may take some time, but it allows you to get to a point where you really better understand yourself and why you do the things you do. Understanding your own motivation to me is an important road into defining what really matters to you, and refocusing yourself.

And after all, if GTD has any value, it should not only make us more effective, but it should help us achieve what is truly close to us.

Just managing your risk impacts is rarely a good idea

Risk impact management complements risk exposure management

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

Managing impacts is often easier than predicting occurrences

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

The erroneous assumption of risk impact management

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

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

Risks are the consequences of the assumptions we make

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

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

Conclusion

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

Conducting a multi-location risk analysis for audit planning purposes in a small audit shop

The baseline

As CAE of a small audit shop in a complex environment, I have to comply with the IIA standards like any other CAE. The performance standard for planning purposes is of course "2010 - Planning", which states that "The chief audit executive must establish risk-based plans to determine the priorities of the internal audit activity, consistent with the organization's goals."

The context

Now, our internal audit department of two people is responsible for an audit universe consisting of an main office, country offices in 18 different countries and about 200 active projects per year, with give or take about 250 million euro in spend in these projects on a yearly basis. These projects are very wide ranging, from building roads to assisting foreign governments in developing strategic plans in certain sectors. As we work mainly in fragile states, the risk profile of our projects is often quite high. This is a signficant challenge for planning the slightly more than 400 mandays per year I have available to me.

So we had to come up with an efficient as well as effective way of complying with the IIA standard 2010 and ensuring our assessment was as relevant as possible as well, to make sure our focus is where it should be.

This is what we did ...

Phase I - Open online questionnaire

While my initial intention was to ask both project managers, country responsibles (equivalent to middle management) and headquarters based middle management for their opinion, we quickly determined this was not feasible from a practical point of view. Why? I decided to work with open questions, allowing all participants to voice their opinion on top five risks ahead of them in the coming two years. If we had to integrate all these open questions for more than 200 participants, it would have been too time consuming. In the end, we queried about 50 people in total, using the forms function of Google Docs as our system.

For each of the five most important risks, we asked the participants to evaluate the following three elements:

• the likelihood of the risk occurring in the next two years
• the impact the risk would have on the area under their responsibility if it were to occur
• the current level of risk mitigation based on existing procedures and controls with respect to the risk

We provided only limited guidance on the quantification of these evaluations, but the evaluation was done on a qualitative, not a purely quantitative basis, but using statements such as 'very high', 'very likely', rather than numerical values.

As was to be expected, the results were quite varied. Some respondents looked at risks from a very high level, with a significant focus on external threats, while others approached it from a very detailed position.

Lessons learned from phase I

We learned the following two important lessons from phase I:

• Although difficult to reconcile, this exercise brought us a lot of different points of view which were highly complementary. This information has become an important input in customizing the risk model which we will be using next year for the risk based audit planning.
• We shied away from using a comprehensive risk model as the basis for questioning in our initial open online questionnaire. However, in order to involve more people in this initial assessment, we will be using a structured, closed questionnaire next year.

Phase II - Team meetings per department

After processing the information gathered in phase I, we followed up with meetings in which all middle managers were invited to participate. Some of them declined because they had already shared their considerations in the open online questionnaire. Others felt they wanted to further detail their considerations.

In the meetings, we steered the discussion towards the following three elements:

• We started discussing risks related to processes in their area of responsibility;
• we then moved to discussing the risks related to people;
• and finally we discussed systems at their disposal and risks related to these.

Based on these meetings, which we conducted with each of the departments of our organization, we arrived at an enhanced list of 'risks' related to each of the departments.

Lessons learned from phase II

We learned the following important lessons from phase II:

• We again used an open format. While this is valuable in the context of such meetings, providing the participants with some information on the structure we intended to follow may have focused the discussion more.
• It remains a trade-off to be made between focusing the group and perhaps losing essential information on less clearly perceived risks and getting the group to be as broad in its scope and discussion as possible and perhaps losing focus on some key challenges to them.

Phase III - Delphi analysis within the internal audit department

Based on phase I and II, we now had quite some information on risk exposures of our departements. Now we needed to translate this to a comprehensive, internal audit owned risk analysis.

We developed a spreadsheet in which, for each of the departments and functions in our audit universe, we were to assess independently, as internal audit experts, based on the information gathered, the impact and likelihood of the risk and the perceived current risk management level. With respect to impact, we defined different types of impact, i.e. impact on finances, impact on reputation ...

We compared the results of our independent assessments, focusing mainly on those assessments that were significantly different, looking at the underlying scores we each attributed to the different departments and functions. In a very open exchange, we agreed on a final score for each of the departments and functions.

Lessons learned from phase III

The results were quite nuanced. The independent internal audit risk assessment is but one input in the overall planning, which we will detail in a later post. We will continue to own the final assessment ourselves, as this is required if we want to remain entirely independent and objective.

Overall conclusions

In short, we will be using a more structured approach for the first two phases, in order to both involve more people in the exercise in phase I and provide better guidance for the discussions in phase II. However, the two step approach will remain in force.

Using the informatiion gathered to develop an independent audit centric risk analysis, in which we use a Delphi technique, has proven to work very well. It aligned with the risk profile the external auditors estimated for our organization, which was an additional validation for us.

About the iPad Mini's lack of retina display

I really don't see what all the fuss is about.

True, the screen is not mind boggling beautiful as the retina iPad or, for that matter, the retina MacBook Pro. That is not the point. The point is the following.

It. Does not. Matter.

Unless you are a visual professional doing most of your creative work on the iPad mini, you will not need a retina iPad Mini.

As a mobile professional, like me, you will especially not need a retina iPad Mini if the trade off is weight or battery longevity. And let's be clear: barring a major technological breakthrough in either displays (Sharp?) or batteries, it will be either heavier or have a limited battery life.

I'm writing this on a train on its way into Brussels. I'm writing it on an iPad with LTE and no retina display. It just works.

This morning, I read my daily RSS newspaper on a retina iPad. And at work, I will be looking at my non retina MacBook Air docked to Samsung 21 inch monitor.

Since when has the discussion become one of specifications, rather than one of relevant features and benefits that do make a difference?

On Apple versus Microsoft - A user perspective

An IT department's consistent preference for Microsoft Windows over Apple's OS X and, as a result, of any PC over a Mac is to me, the ultimate illustration of their lack of understanding of their users.

I've recently played around with Windows 8, and was a Windows 7 user. This is the key difference, to me:

• An IT department want features, control and access to the system to tweak and play around with. Technology is central to their objectives. Windows offers this level of control to them;

• users just want tools that function out of the box and allow them to do a better job in the same or less time. Technology should be unobtrusive and get out of the way of production. Mac OS X offers this to them.

Making an abstraction of the differences, with all respect for each side which has his or her arguments all lined up, business should ask themselves the question: are we an IT business or are we a user business?

Are we about achieving results or about being a fertile playing ground for IT?

Improving your 'next action' and 'project' descriptions

As GTD-ers, we are intimately aware of the challenge posed in consistently formulating well defined next actions and project descriptions. Making sure a next action is actually actionable or writing a project definition you still understand two days after, when you are processing your inbox, requires diligence and attention.

Like most of us, I presume,I find myself falling into the trap of non-executable next actions or not adequately defined projects over and over again. Luckily, by no real creative work of my own, using what Merlin Mann wrote on 43Folders combined with a text expansion snippet based on the work of Chris Holscher, I found a way to "force" me to consider the quality of the inputs in my action lists. Here goes ...

Project and action verbs according to Merlin Mann and GTD

Merlin Mann's post I link to below is the key starting point. In this excellent blog post over on his 43Folders blog, he describes the difference between project verbs and action verbs. It is of course based on canonical GTD, but it is highly accessible.

It's a great explanation and a very usable list of verbs I found myself coming back to again and again ... and again and again and again.

For experienced GTD-ers, the tool switch issue inherent in needing to look away from an activity to consult a blog article is apparent.

It costs time and effort that is better spent elsewhere. Every time I wanted to create a good next action or a well defined project, I went back to the blog post just to consult the list. Yes, I had it captured in my reference files (for which I use Evernote). But still I failed to either learn the list by heart or create some kind of mnemotechnic technique to remember ... And this is where the magic of text expansion comes in.

Note that what I am about to describe is specific to Mac. However, I am quite convinced this is easily replicable on a Windows machine as well. I am just not familiar with Windows software.

Something borrowed ...

I borrowed the Textexpander snippet Chris Holscher described in this post and adapted it for my purposes ... I now have two Textexpander snippets which I invoke with either ';pr' or ';nxa' to indicate my intent to Textexpander to formulate either a project or a next action. You can find screenshots of both snippets below, but the basic idea is this:

I use the text expansion software to offer me a dropdown list of next action or project verbs as well as a fill-in form to document the rest of the next action or the project description. My text expansion software shows me a dialog box where I can select the project or next action verb (depending on the snippet invoked, of course).

I consistently use this when I am generating my next actions or projects. I can pretty much generate them anywhere, as I will describe below, but the idea is that I only allow myself to input in my 'to do'-list (in my case, my Omnifocus inbox) using this approach where available.

Mac specific basic entry and extra credit

Now, I usually invoke this Textexpander snippet when I am in the quick entry dialog of Omnifocus, which is a very easy way to work. That's just basic operation.

For extra credit, when I am writing in a text editor(for Windows people: Word is not a text editor), I will invoke the snippet in the editor and after I have defined the project or the next action, I will move it to Omnifocus using Popclip and the Omnifocus Popclip extension.

How relevant is this?

Now, if you look at it from a distance it is only a snippet invoked from a text expansion software. However, if you consistently apply this approach when entering new next actions or new project descriptions, you force yourself into a constrained situation in terms of input requirements and you find that you actively start thinking about what it actually is that you will be tasking yourself to do in the future. It eliminates unclear next actions and unclear projects to a significant extent.

May I suggest you try it?

Next action snippet

Project formulation snippet

Tools I use – Drafts for simultanuous input capture

My simultanuous capture use case

As the head of a small internal audit shop, I deal with a lot of inputs. These can be operational, such as notes of interviews or testing remarks. They can also be administrative in nature, such as meeting notes or notes I take during training. All in all, quite a few different inputs.

How I used to manage these inputs

Pen and paper. Really, I've always liked the feel of a pen on a piece of paper. For some purposes, such as writing longer articles, I still pretend to do just that, with my bamboo stylus. If you are interested in that workflow, read this article.

However, turnaround on other inputs became too long. I wrote, then I wrote the notes on my computer ... because in a small audit shop, you don't have the luxury of handing your notes off to a secretary. You do it yourself.

The intermediate scenario

There are a lot of text editors out there, both on Mac ans iOS. I tried quite a few of them, but they never were truly ubiquitous like pen and paper can be. I was too involved in the tool to be fully engaged in the content I was trying to capture. That, of course, is a problem.

What I needed was a tool that allowed me to capture without thinking about layout and other aspects, and with an easy way to export to any of my other tools.

I ended up with a combination of a language and a tool.

My solution: Drafts and Markdown

Agile Tortoise has developed an iOS app called Drafts. It has become my go-to application on my iOS devices for taking notes on anything and everything I'm hearing and thinking about. Let me illustrate:

Last week, I was attending an IIA course in Brussels (the IIA, for non auditors, is the Institute for Internal Auditors, a brother- and sisterhood of internal auditors. We even have jokes.) on auditing project management. The course was taught by two excellent teachers. As always, I was working at a couple of levels. I was listening and taking notes on the content of the course. I was at the same time listening and taking notes on the impact of what was said on an audit we are currently executing ... and I was on occasion thinking about to do's which had nothing to do with the class.

Now, let's take a couple of steps backwards. There I am sitting, thinking about multiple things at the same time. I believe I'm not an outlier. Thinking multiple thoughts, following multiple threads in our heads at the same time is rather human.

However, I used to let a good deal of this thinking go to waste. I thought good, sometimes even great thoughts, I tried to remember to remember them ... and I lost them. When I started noting stuff down on paper, I lost the papers. When I started using Moleskines, I was afraid to write in them, because of the cost and because of the nice-ness, and when I started using iOS tools I could not combine and note taking on a training or an interview with note taking on other thoughts and putting to do's on my to do list.

Enter Drafts

Drafts is a note taking tool which allows me to send notes to multiple applications on my iOS device. Its export facilities are amazing, and growing with every release. Luckily, you can reduce the number of export possibilities visible, to configure the app to work just as you like it. If you look at the screenshot below, you will see I can 'share', export to Twitter or app.net, put something in my agenda, write an SMS, write a formatted email ... and this is a curated list, adapted to my specific needs.

Drafts' most important export functions to me are however, its possibility to append text to a running file on dropbox called Journal.txt and its export facility to Omnifocus, my task management software. Let's visit my use case again:

I'm in the course, listening to what is being told by the lecturer. I follow the slide presentation on the handouts. I started my note taking session by entering the Textexpander Touch shortcuts for date and time, so the running file I'll be exporting to on dropbox has a record of when I started entering information. Whenever I feel I have finished a thought, I send the text to the file in dropbox it's appended from. Journal.txt, which resides in my Dropbox Drafts folder, which resides under the App folder, holds a record of all the thoughts I feel I still need to put somewhere. They are 'stuff', but 'stuff' in the GTD manner of speaking, which is already somewhere where I will visit it later.

All of a sudden, I think of something I need to discuss with my team. I enter the thought and send it to Omnifocus. In 2 seconds the quick entry box is filled with the idea I wrote down in Drafts, with the second and third line of my entry filling in the notes section. This sits in my Omnifocus inbox, waiting for me to process it.

Then, based on what the lecturer said, I suddenly think of a test to add to the workprogram we are developing. I start writing out the thought in Drafts, I use Draft's extended iOS keyboard to put (Workprogram) between brackets, and send it to the Journal.txt document. I could have sent it to another application I have installed, such as Byword, but that would open Byword and I don't have the time to write a full set of workprogram instructions right now.

Using Markdown

Drafts supports Markdown, providing you with one of the best extended iOS keyboards I've seen for this purpose. This allows me to write formatted documents as well, for example if I want to write an email with some formatting. It also allows me to send texts with basic markdown formats to the journal.txt file from where I can go and find it to work on it in Sublime Text.

Conclusion

If capturing multiple inputs at the same time is your challenge, and you are interested in working with plain text applications or are capable of working in Markdown, Drafts is the best solution available to you today.

Drafts export options

The responsibility of living on the edge of the abyss

Umair Haque got me thinking. Again. It's getting to be very disconcerting.

I seriously need to either stop reading his stuff or start writing more in response to his articles. I'm not out of the woods on that one yet. The trigger article this time? His article on how to fix your soul. It dates from May 2011 but I had failed to read it before.

Read it here. Then come back, if you'd be so kind. You and I, we need to talk about our obligations.

The end of the affair

As some of you know, I am quite a positive thinker. So let's try a little thought experiment. Here goes:

Imagine the world being hit by an asteroid today. A real extinction level event. Earth gone, or at least all of humanity gone. Everything you cared about, anyone ever cared about, gone.

Care to consider how important that would be?

The relevance of our irrelevance

In the whole of the universe, it would be as important and as relevant as the bursting of one little tiny air bubble in the enormity of Niagara Falls. Not just Niagara Falls right at this moment. No, Niagara Falls over its entire existence.

We are irrelevant. We are nothing. We don't matter at all. All the beauty we have ever created, all the knowledge we have discovered does not mean a thing. It does not matter. Not really. Or does it?

The humanity of the taxi driver

On occasion, I get to go to Paris. To attend a meeting at the OECD. I usually get a taxi to go there. It's quite probably the slowest means of transport available in Paris, but I like to talk to the taxi drivers. They ground you. They are like most people. They are really like you and me.

Every day, most people struggle to make something, to create something. It may be because they want to leave something behind. It may be because they have to, to feed their loved ones. It may be because they cannot but create, sing, dance, act, write, ... We do care, despite its ultimate irrelevance.

A taxi driver takes pride in what his children have achieved, or are achieving. A daughter going to medical school. A son in the armed forces. A wife dearly loved, achieving greatness every single day, either at home or in a menial job. Struggling but alive, working towards something. Working for something.

I admire the enormous strength it takes to do this everyday simple yet essential act of creation, despite the realization it only matters for a very short time. That is courage.

The betrayal of our inheritance

Most of us are taxi drivers, or are at most two or three generations away from being a taxi driver. My grandfather was a blue collar public servant. My grandmother ironed shirts for a living. Both of them did their work with enormous pride. They achieved sustainability for their grandchildren.

The consumerist generation has betrayed that inheritance. They choose opulence instead of eudaimonia, as Haque refers to it.

I despise the acts of selfless egoism of some people, most often those who deem themselves better than others, because of their skin, their beliefs or lack thereof, their sexual orientation,the amount of money on their bank account ...

Their acts are not acts of intentional creation. Their acts are acts of destruction. They do not respect their ancestors.

A duty to oppose opulence

Even if in the end their betrayal is as irrelevant as the quiet acts of heroism we see around us every day, it should be part of our duty, our obligation to fight them. Every. single. day.

Because if we do not fight them, we are no better than they are. A failure to fight intentional, short sighted destruction is a refusal to create long term identity, lasting value ...it is as if on the road to oblivion, we are no longer bound by what makes us human and humane. Our values.

Redemption

If there is any redemption to be found for a race that is to die, all alone, far from any other intelligence and unbeknownst to them, on the outskirts of a lesser Milky Way, it is that we took the opportunity to create on the edge of the abyss, filled with endless depths of nothingness.

It should be the testament of our generation and those that come after us that we looked into the abyss, saw the monsters, recognized them as some of our own, yet never became monsters ourselves.

Umair Haque believes we are on our way to just that. I want to believe him, and deep in my heart I know we are heading there. Because sometimes, as Steven Johnson put it in his book "Future Perfect", all of a sudden people moving together in the same direction will become a wave.

Outcomes and the problem you are trying to solve

A project is defined, in part, by its outcomes. They describe us what it looks like at our intended project destination, in terms of where we are but also in terms of what we have learned, gained, developed. By defining good outcomes, we actually develop a great way to regularly check whether we are still on course. You typically do this at regular intervals, for example when you are performing a (weekly) review.

But sometimes formulating these outcomes is difficult, not to say almost impossible. I want to take a quick look at this type of situation, what may be a cause and how we can attempt to solve it.

What defines a good outcome?

A good outcome should be SMART. If your outcome is specific, measurable, attainable, realistic and time bound, it becomes adequately concrete to be followed up. There is a reference, an adequately concrete basis for developing a baseline. I've written about this before here.

what can go wrong? A concrete example

Now, theoretically I'm very much aware of what a good outcome should be. I mean, I've even adapted some text expander snippets for that exact purpose. However, the following happened to me only a couple of days ago.

In the course of my weekly review I bumped into the following inbox item (duly captured in my GTD process) "learn python". The source of this idea was an interesting post on MacStories by Federico Viticci on Pythonista for iOS. I'm a real pushover for this kind of excellent articles.

I knew this was not a simple next action. After all, you cannot 'do' learn python. So, it's a project. A project has both a defined 'why' and an outcome. The why was easy. Because I am curious about python. Okay, now the outcome. What does it look like when I get to the other side? Mmm ... Well, I know python. But what does that mean? Knowing is not adequately concrete. I cannot measure knowledge of python unless I define an objective benchmark. But I don't know enough about python to be able to define such a bench mark. ...

It turns out I never really considered what relevance python has or can have for me. I actually did not have enough information on python to assess its use for me. I simply did not have enough basis yet to motivate my (significant) investment in learning this language.

So I converted the project into "research relevance of programming languages for BTC, casmo and personal activities." In Covey speak, I did not have the end in mind. My project now has a number of steps aimed at identifying languages, understanding what I can do with them and matching or approximating this to a need I have or may have in the future.

Now, The answer may be that I have no need for learning a programming language. Perhaps I need to focus on bettering my CSS skills first. But at least I will not be off squandering my time on a no doubt interesting topic that will not contribute to my development or efficiency.

Don't get me wrong. I may still find arguments to learn python, even if it will not yield direct and measurable benefits. But, and that is a highly relevant difference, it will be a considered choice. That choice may mean I need to give up a number of other projects. But it will be considered.

what happened?

I failed to properly formulate a smart outcome for a project. While I was very motivated to learn python, I did not have a good enough reason for committing to it yet. There was no project, only enthusiasm about a potentially interesting subject matter I could get lost in.

While sometimes it may be your subconscious resistance to work that is pushing you in that direction, this was just an inadequately considered idea. Which is why doing the necessary research is a smart sub project to execute.

what has this taught me?

Well, first it taught me there are quite a few potential projects in my inbox or equivalent that are significant time sinks that I have yet to define a good outcome for. As long as the outcome is not clear, as long as they don't qualify as a real problem or issue I am trying to solve, I do not engage with them other than doing some research to clarify my thinking about the end I have in mind.

It also taught that that the SMART framework, heavy as it may be, has a marked advantage: if you fail the SMART test, you have an outcome issue. You are not clear enough. So you need to go back and think it over, again.

For those of you interested in the outcome of this specific issue, you may be interested to know that post my research I decided not to study python yet, and 'learn AppleScript first, as it allows me to automate more on my Mac. This will more directly impact my productivity.

Perfectly put

Once in a while, just once in a long while you come across a blog post so to the point, so well written, that it stops you in your tracks and you hear yourself thinking, almost aloud: "They're talking about me!"

I had that experience with Stephen P. Anderson's "What is User Experience?". It says everything, and it says it well.

Now, I'm not a User Experience Designer, as Stephen is. I am an auditor. But just read the following quote:

"At the end of the day, there are those people who will go quietly about their jobs, perhaps grumbling about not having a “seat at the table.” These people may have also been taught the right way to do things. Then, there are others who–regardless of their titles or position–will stand up and say, “Wait a minute, why are we doing it this way?”"

Yep, that last sentence, right there, is why I became an internal auditor. I could go on to quote the entire wonderful post. I won't. Go and read it. Now. You won't regret it, in whatever business you are. Because this is about us.

Assessing real risk appetite

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

A reflection of stated risk appetites

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

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

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

Real risk appetite is reflected by exhibited risk appetite

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

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

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

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

Using the results

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

We can perform the following analyses:

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

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

Tools I use - Reeder for RSS based information capture

A lot of the information I deal with, either for my day job or for my teaching or blogging, I get from different web published sources, be it blogs or websites. As I really don't have the time to visit each of these sites every single day, I make use of the RSS feeds where these sites provide them. I gather all that information in a so-called RSS reader.

What is Reeder?

Well, Reeder is my preferred multi-platform (iOS and OS X) RSS feed reader. The tool syncs with my Google Reader account to bring me all the information in a well designed format when I want it, or as long as I am within reach of a good 3G/4G or trusted WIFI network.
There are other RSS readers with a good reputation, both on iOS and OS X, but Reeder has an aesthetic that I have to date failed to find in other RSS readers. It provides a truly pleasant scanning/reading experience.

How I use Reeder

Those of you who have read my post on Instapaper know that I do not read in my RSS reader. I actually use it to scan through the articles. In my scanning, I follow a basic GTD approach:

• An article I don't particularly care about gets passed. As I don't do anything with it, Reeder marks it as read and will remove it from my reading queue.
• An article I must read or do something with for my day job gets send to Evernote and tagged as 'review'. This way, it ends up in a workflow I will write about later.
• An article I want to read, but with no direct urgency, gets send to Instapaper, where I follow the process I described in this post.
• In exceptional cases where I want someone to take direct action on an article, I will forward it through mail, but this happens seldom. I avoid it because this implies a delegated task, which I would rather manage through OmniFocus. Reeder does not allow for OmniFocus sharing as Instapaper or, with some effort, Evernote does.

Of course, as GTD adepts may be quick and correct to point out, I do not comply with the basic premise of GTD that I should touch every piece of stuff only once. I actually 'process' it twice, both in capture and in review. Well, it's not a perfect world. This is the best I can get my process now.

Which platforms can you find Reeder on?

Well, this is what I really like. There is an Reeder iPad application, a dedicated Reeder iPhone/iPod Touch application, and an OS X application. I can pretty much scan through my feeds whenever I have a couple of minutes of downtime, or during morning breakfast when I leave early and no one else is awake yet.

What are disadvantages and how do I deal with them?

Now, Reeder is a great but not a perfect application. I currently have two gripes about it:

• The first one is a big one. I cannot directly add feeds in the iOS app. For this, I have a different Google Reader client call Mr. Reader. I have this app on my iOS devices for no other reason. Why not switch to Mr. Reader completely? Well, aesthetics mostly.
• The second one is a truly nerdish one: as I don't trust Google for the full 100% never to suddenly kill Google Reader, I have set up a separate RSS aggregation solution called Fever. While not as fast or as complete as Google Reader, it works for my purposes of having a back-up solution available. Sadly, only my Reeder iPhone client works with Fever. Neither the iPad nor the OS X application support Fever.

In conclusion

Reeder is an excellent application that provides me with access to my RSS feeds when I want it. It allows me to perform good capture of that inflow of information into my workflows.

Reeder's main screen, with all my RSS feeds

A view of my unread articles stack for this evening

Reeder's sharing interface. I've configured it to show only those services I use or am experimenting with