Respectful visioning - a facilitated approach

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

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

Context of the facilitation

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

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

My observations

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

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

My challenge

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

The solution

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

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

Result

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

Why respectful visioning?

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

Single Point of Failure

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

Defining a single point of failure

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

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

The butcher's apprentice

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

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

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

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

Detecting single points of failure

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

Alternative or additional actions

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

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

After identification, you need to solve the issue

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

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

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

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

Consultants fear commoditization

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

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

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

Where commoditization occurs

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

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

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

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

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

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

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

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

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

The lesson

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

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

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

Better risk based situational awareness using risk models

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

Top five versus first five issues

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

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

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

Using risk models

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

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

Errors in understanding the use of a risk model

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

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

The relevance of the risk model

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

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

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

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

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

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

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

The challenges of "inherent" risk

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

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

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

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

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

Visualizing risk management effort

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

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

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

Back to the traditional risk matrix

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

'Calculating' inherent risk

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

Risk management effort as a relevant metric

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

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

Introducing the Risk Effort Matrix (REM)

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

Risk Effort Matrix

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

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

Quadrant I – What has gone wrong?

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

Quadrant II – The future effort area

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

Quadrant III – Assurance and potential cost savings

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

Quadrant IV – Monitoring required

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

Regarding unknown unknowns, hindsight is 20/20

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

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

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

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

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

Making an unknown unknown

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

Aspect 1 - Time to onset

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

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

Aspect 2 - Available expertise

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

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

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

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

Aspect 3 - Required width and depth

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

In conclusion

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

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

Chipping away at your mountain

Playing the piano

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

The core of GTD

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

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

Higher altitudes determine task relevance

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

Time is a context

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

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

GTD is not (yet) doing the work

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

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

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

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

Our internal audit reporting workflow

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

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

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

Challenges

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

Showing your work

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

Getting the message across

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

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

Other issues that sidetrack auditors writing audit reports

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

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

Essential aspects

Standardized Structure

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

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

Short and concise

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

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

Tools I use

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

Basecamp

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

Mindnode Pro

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

Scrivener

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

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

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

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

Conclusion

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

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