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.