"Workflow" reviewed part III - Invisibility & trusted returns

A quick aside: About my review

As you may have noticed by now, I'm not really reviewing Kourosh Dini's most recent book "Workflow: Beyond Productivity" in a traditional manner. As a book, it appears to have an epic objective, which is to provide a deep background to our thinking about productivity and more. It tries to provide an explanation for things we intuitively feel and believe are true, but don't necessarily understand how they work.

Like you, I am very curious about the result of this undertaking. I am writing as I go along reading, and so far, about 1/8th into the book, often so difficult to say with iBooks, I really like how the basement of this mansion of a book is shaping up.

To my review: I am trying to link some of the ideas which Kourosh puts forward to my own professional experience, as an auditor in a larger environment. My reference framework is all the organizations I have worked for, as an employee or contractor, and all the organizations I have worked with, as a consultant.

Achieving prime objectives depends on a number of factors

In his chapter "Organization", Kourosh describes a number of factors influencing the realization of your most important, overarching objective, or your primary intention. He defines as key organizational pillars availability, accessibility and avoidability.

In order to have a well functioning system in support of your primary intention, you need to make sure that relevant objects are available when needed, accessible when relevant and avoidable when irrelevant. Now, in personal productivity these criteria, these pillars are just what a well configured GTD system will allow you to achieve.

Organizational details ensure that the three pillars function as they should

Further on in that chapter on organization, he describes what he refers to as organizational details, those aspects that ensure that those pillars function how they should function. And among these organizational details, we find one I find especially interesting in a corporate productivity context, which is invisibility and trusted return.

Quoting Kourosh:

"Invisibility is not necessarily an object's absence from sight, as much as it is absence from mind. Objects resting in the periphery, unaddressed and often unacknowledged, create turbulence, consciously and unconsciously."

Let me translate that to a corporate structure setting (my words, interpreting this in a corporate structure):

"Any information in the periphery of a management team, unaddressed, will create turbulence in that team."

and its inverse:

"Good information flow to a management team at whatever level in the organization consists of Just Enough Relevant Information."

Just enough relevant information

The idea of just enough relevant information is not mine, but I first heard it from a friend of mine, Hans Van Heghe, the CEO of ICMS group. He used the term Just Enough Relevant Information, or JERI, in a book and a paper on knowledge management. You can find that paper here.

But let's examine Kourosh's statement, and my translation in a bit more detail. I'll use an example.

The sufferings of a CEO in a start-up in transition

Imagine you are the CEO of a midsized organization. You have been lucky to see significant growth in the past years, and now you are, as is often the case after a number of years of growth, platooing out. This is not bad, as it gives you the time to bring your house in order. You have moved from being a small start-up, where everything was well understood and key information was transmitted in face to face meetings, often at the water cooler, to a structure where you are no longer sure where the information comes from, what its accuracy is and whether or not it is complete and timely.

Aiming for key internal control objectives

Internal auditors among you may recognize some control objectives hidden in the last sentence:

• Existence and occurrence: is this information related to something real in our business reality (indicative of the trustworthiness of the information source)?
• Completeness: is all the information available, has every relevant aspect of the information been communicated to me or my team?
• Accuracy: is the information provided correct information? Is the information factually correct, or are there errors in it?
• Timeliness: do I get this information at the right moment, or does this reach me at a point in time when there is nothing I can do about it anymore?

A key failure in many growth paths

It's rather obvious that any CEO that cannot trust his management system and hierarchical structure to provide him and his team with this type of information under these conditions has a problem. And yet, this is exactly the point where I have seen many organizations fail to make the correct transition, at a high cost.

As Kourosh states, there are actually two dimensions to this problem:

First, the object, in this case relevant information for management, should not be there when it is not relevant or not needed. That's the invisibility. Or, to quote him directly:

"How will this be off my mind when irrelevant?"

But there is another dimension to that ... because we need to trust the object will return to our attention when needed. Kourosh again:

"How may I place this object so I may trust it will return to my attention when relevant?"

If this functions well, it indicates both the object's reliability and our own. In my example, it is indicative of the reliability of the information but also of the system ensure that the information gets to where it should, on time.

The implications of a failure to provide invisibility and trusted return are more important than may first seem

If this does not function well, you have a CEO and a management team that will become concerned with everything, even those aspects which are not relevant to them at that time. This has a two effects, both of which are desastrous for a growing organization in the transition from a start-up to a young organization:

• First, it disenfranchises the management tier just below the management team: as the management team takes away all problems because they feel they need to be on top of them all the time, because they do not trust the system (the information flow) to be complete, timely, accurate and trustworthy, they no longer allow their "middle" management to function, often leading to frustation in those ranks;
• It overburdens the management team with to them irrelevant decisions, which leads to a situation in which their available time, which is limited, is not used in the most optimal manner. Rather than being able to think and discuss those aspects that should be under their attention, and only those, they lose their precious time in decisions which may well have been taken by their middle management.

Hence, the development of support systems and structures that allow for just enough relevant information to be transmitted to the right people at the right time in an organization is a precondition for good functioning. It is too bad that establishing these systems is almost never in the top priority of management teams ... until it goes wrong.

Remediation of this situation is usually costly ... not necessarily because the systems cost that much money to set up, but mainly because trust has to be regained in these organizations.

"Workflow" reviewed part II - Organizational decay

In his excellent new book "Workflow: Beyond Productivity", Kourosh Dini states the following:

"Any aspect of organization, be it task, checklist, container, memorized concepts, or otherwise decays in time as it relates to an intention."

If you think a bit about it, it is very true. Your organizational "tool" serves its purpose, after which it could, in principle, be discarded. We check off a task we executed, we discard a container which we carried food in, we forget what was foremost in our memory when taking an exam ... because it has served its specific usefulness.

Decay in organizations

But discarding a small aspect, such as a task from a task list, is easy. What if the superstructure you built for the achievement of your objectives is much, much larger? Can it still be as easily discarded? Does it decay over time?

In other words, the question I'm actually putting forward is whether and how this concept applies to organizations themselves, as the ultimate large organizational solution to solve a certain larger scale problem?

Structural decay in organizations is not a natural phenomenon

Well, the interesting and perhaps slightly disquieting part of it is that is does not ... or not enough. Let me explain, while linking to the basic idea that Kourosh desribed. I would also like to refer you to this post by Clay Shirky in which he provides a summary of some of the ideas Joseph Tainter described in his 1988 book titled "The Collapse of Complex Societies".

An example

Let's imagine an organization is started for a specific purpose, let's say the development of a new piece of revolutionary software, an operating system for example. This operating system is new and revolutionary in that it will eventually change the entire industry, bringing computers into the homes of people because of the relative ease of interacting with what was before a machine only accessible to the high priesthood of hackers.

This organization succeeds beyond belief. It achieves market dominance at adoption rates in excess of 90% of worldwide market share. They continue to develop software which plays well with the operating system. Mistakes are made, but overall, the software aims to solve very specific problems and achieves that clear and identifiable goal. The "cost" of the additional complexity of using the software is significantly lower than the additional value to be gained from its use.

Iteration upon iteration of both the operating system and the accompanying software takes place. The organization and its developers go virtually unchallenged in the markets they are active in, because they are closest to the operating system and can integrate the best.

The iterations become more and more complex, with a higher associated complexity cost. The cost of complexity is the additional time and effort you need to put in to learn how to work with the system. Even with a very clearly stated purpose of the development, there will be a point where the cost of complexity becomes higher than the added value. It will take users more effort to learn to use a tool than they derive from its use.

Now we come into slightly murkier water. Some users have grown up with these tools, and incrementally learned to use them. Their cost of complexity for the prior iteration of the software is already sunk. They have already made the investment to learn the use ... and can more easily, at a low additional cost, adapt to the new functionalities. However, there is a group of new users for who do not have sunk costs. The higher the complexity cost, the lower the likelihood these people will invest in this software if there is an alterative available. Hence, due to its increasing complexity, the adoption will diminish and the market share will, slowly at first, start slipping.

Meanwhile, in order to be able to deal with being an organization, the organization has built a support structure, geared towards fullfilling its objective of developing this software. Imagine a finance department, a logistics department, a human resources department. Once established, the support structure will consolidate itself, becoming at the same time more effective and less flexible, because often the two are trade-offs.

Let's take stock for a minute, where are we? We have an organization which has reached a point where the complexity cost of its core products is higher than their added value and with a significant superstructure optimized for efficiency, but not very flexible. Oh yeah, they do have a virtual monopoly, which appears to be slowly decreasing.

There is a very real "emotional" pressure working here: if we have a monopoly, why change our underlying product which is such a success? We can make some visual changes, but the underlying system should remain the same, because we do not want to change a winning formula. That pressure is organizational fear.

Thinking outside of the example for a minute, this is not dissimilar from people afraid of letting go of their personal productivity practices even if they know they have become too unwieldy

What then may happen, in order to appease the 'new' crowd that has not yet invested in the use of its product, is for example a significant revamp of its interface. This often makes matters worse. Users with an initial complexity 'investment', trained to use the old system, suddenly find themselves in unfamiliar territory, because they do not understand the interface anymore. They may abandon ship, if they see that possibility.

Now imagine one agile, disruptive player entering that specific market. Neither the core products or the support structure of the initial organization can adapt quickly enough to deal with this challenge. They may have the market, but they do not have the efficiency to react to that market if its taste start turning ... and turn they will if the complexity cost of the alternative is lower.

The ultimate end result will decline, failure and collapse of the initial organization.

The lack of organizational decay illustrates its lack of flexibility

But why? Referring to Kourosh, where an individual can easily adapt its organizational support structures, or adopt them, use them for a purpose and then discard them, organizations have a natural tendency to try to give themselves purpose above and beyond their initial purpose. Most often because the consist of people looking for longevity in their professional activities. They sacrify flexibility for efficiency and are ultimately confronted with a situation in which their internal and external complexity makes them a sitting duck for any viable alternative that enters the marketplace.

Organizational decay introduces uncertainty, but adds value in the long term

What I learned from Kourosh is that the support structure, the system, needs to be optimized but we should never become solely dependent on the system. An organization is the ultimate example of a system we depend on for our paycheck and our bread and butter (and chocolat on the weekends, certainly here in Belgium) ... we should dare to let organizations and their support structures decay, or at least link them to an end of life that is realistic and after which their usefulness should be revaluated from the ground up. That is the type of change that will bring added value to structures, instead of structures extracting value from their environments.

Just an aside, had this approach been adopted in the mid 1980's and maintained, the world wide banking industry would have looked significantly different and a lot more relevant.

The impact of decay on people

However, for the people working within such an organization, it introduces uncertainty they often have a hard time dealing with. This is why any organization willing and brave enough to go the route of intentional regular organizational decay needs to ensure its people are trained to be functional and functioning in multiple settings and structures. Call it employability or whatever, but make sure you train your people to be flexible as well, and to retain their value beyond the function they were initially assigned.

This of course requires organizations to let go of the paradigm of the factory worker we have held dear so long, and to look at people as an intangible asset to be developed and invested in, over the long term.

"Workflow" reviewed part I - Thresholds of organization

Introduction

Going through my mailbox a couple of weeks ago, I was surprised (and very thrilled) to find an email from Kourosh Dini, the author of "Creating flow with OmniFocus", which is the unofficial reference book on how to set up your OmniFocus configuration and process. He thanked me for a reference to his book in a post. He recently wrote another book, titled "Workflow, Beyond Productivity", a book I highly appreciate.
In the short email exchange we had, he mentioned it would be interesting to see how his ideas and concepts applied to a larger organization. And I happen to be an internal auditor of a larger organization, and have worked for larger organizations for most of my professional life.

So, rather than just reviewing the book, I will take some of the ideas and concepts from the book and apply them to the reference model of organizations which I carry around in my head. This reference model is a compound of all organizations I ever worked for or with.

I do hope these articles entice you to start reading Kourosh's book(s). I like to think about him as the Neil Stephenson of non-fiction. The first paragraphs are kind of hard to get into, it does take an effort because of his beautiful but very intense writing style. Then, all of a sudden, he hits you with an idea so clear and so relevant that it blows you out of the water and leaves you on the shore, wondering how it is possible that something so clear and obvious never occurred to you. That, my friends, is genius.

So, I will work my way through the book, and try to write an article a week on it, touching some of his ideas and bringing them into a context I am familiar with. Again, get the book and read it. If you are even slightly interested in the dynamics of process and workflow, this is a great place to start.

Thresholds of organization

Quoting Kourosh, "the availability of some objects may not appear until a threshold of organization is reach for one or several other objects", which he rephrases as "much of mastery is mastery of the basics."

He offers a number of examples, among which "Certain uses of a program or application do not come to mind as possibilities until reaching a deftness with the program's associated commands."

What Kourosh says is "learn the keys", "learn the language" and then you will be able to achieve a deeper, more relevant and longer lasting result because you will be able to do things, to execute certain actions you were not able to execute before.

While this is essential to people, it is essential to organizations as well. Let me explain how this works.

The magical black box

Many organizations believe there is a one size fits all solution for their - often administrative - challenges out there. It used to be ERP, the much touted Enterprise Resource Planning systems such as SAP or Oracle.

I remember an ERP implementation in the late 1990's, early 2000's with a client in which millions of euros were invested in getting the system implemented in the most speedy way possible. And while configurations of these types of systems require a lot of work and are prone to parametrization failures, this one project actually turned out pretty good. At least on the technical side.

There was, however, one key problem. In their enthousiasm to get the system working, they failed to adequately train the people responsible for all the administrative coding of data - an essential part of any system - in how to use it. The end result: lots of garbage went in, and even more garbage came out. The people who had to use the system, and were never trained to do so, were initially held responsible for the failure. They, in turn, rebelled against the system, and started to structurally refuse to use it. Alternative systems were developed, in obscurity at first, but more and more openly as they saw the support for the system from the highers-up was waning. After all, they were not getting the information they needed. In the end, the entire effort was abandoned, and the organization moved to a lighter, more agile and less cumbersome system.

But was it the fault of the system? No, the organzation failed to provide its collaborators the opportunity to master the basics. Hence, real mastery was impossible.

Quick and dirty risk management

I have another example for you. Risk management is a true management fad right now. Implementations of GRC (Governance, Risk & Compliance) systems are earning quite a few consultancy organizations a huge amount of money.

Now, I've been involved in developing risk management approaches from the early 2000's, writing a COSO ERM based methodology before COSO ERM was even released in draft. Together with my co-author, we received the 2009 European Risk Management award for best public sector risk management approach in Europe. Bear with me, I'm going somewhere with this.

In the process of developing the risk management methodology, we realized that one of the key contributing factors of high quality risk management is completeness and relevance or proximity of the identified risks. In short, you want to make sure you are as complete as possible in your risk identification, and you want to make these risks as recognizable as possible for the people that need to deal with them. You want to identify Donald Rumsfeld's "known knowns" and "known unknowns".

However, we are noticing that completeness and proximity are becoming less and less important in current day risk management. Rather than identifying all the risks, let's focus on the top 5 risks. And let's make these as abstract as possible, in order to make them accessible to all, and not specific to one.

In addition to identifying not the top, but the first 5 risks, the abstraction will not make the risks more, but actually less accessible. A generic description tends to be more theoretical and less personal, less engaging. In other words, current day risk management practices tend to create a false sense of security, because we do not adequately take the time to master the basics of the application of good risk management.

A failure to engage

I've referred to Patrick Rhone's article "The Farmer" more than once in the past. My interpretation of the article is that you need to do what you do for the love of what you do, and that you need to have the patience to go at it again, and again, and again, even if you do not see a concrete, tangible progress every single day. You are mastering the subject, and mastery comes with setbacks. But once a certain level of proficiency is reached, new avenues open up.

However, both individuals and organizations focus more on the tools than on the key mastery of the basics. They want to go too fast, want to show results now (quarterly earnings, anyone?) and fail to realize that the key factor is at the same time the weakest link: it is the human in the system who needs to take his or her time to truly assimilate what is going on in order to extract the maximum (human) value. Which actually also tends to be the highest long term value.

Structured play and its GTD relevance

With all my OCD like behavior in terms of the proper application of GTD and my relatively rigid adherence to its workflows, do I actually get to be creative at all? When discussing aspects such as the GTD workflows with people and explaining how I implement GTD, it's a question that often comes up.

A controlled freedom to be creative

The question is quite valid. After all, in adopting such a structured approach to both my professional and personal life, where is the freedom? Well, the freedom is there, but it exists in a relatively "controlled" manner.

Funny as it may seem, I actually block time for being creative and free. And that creativity, being really well defined in terms of when it should occur, actually does occur. Not always as good, not always at the same time, but it happens. It is a case of "If you build it, they will come."

Now, I fully understand that this sounds extremely counterintuitive to any creative people reading this. The point is, this is not my idea. Not at all. It actually comes from the mouth and the mind of one of the most creative people of the 20th century, and probably some part of the 21st as well. It comes out of the mind of John Cleese. In this excellent speech which dates back to 1991, he explains a number of key ideas on creativity. The video is amazing, inspiring, touching and funny at the same time. As to what I want to put forward here, the following ideas are key:

• Creativity is not a talent, it is not something you were born with - Everyone has access to creativity;
• Creativity is not related to IQ - There are not really people that are more creative than others, just people that allow themselves to be more creative than others;
• Creativity requires childlike play, it requires an 'open' mode, relaxed, expansive, contemplative, more playful. There is no pressure to get something done - Creativity is in approach and content fundamentally different from what we normally do.

He then went on to describe a closed, focused mode as the opposite of the open mode and a need and the challenge of switching between the two.

• Execution requires a closed, focused mode;
• We need to be able to switch between the modes, in an eternal feedback loop ... but we tend to get stuck in the closed mode.

Creativity and GTD

When I'm executing concrete and clear next actions related to projects, I am very much in the closed mode, focused on execution. I discard all non essentials and focus on the deliverable of the next action, on the end result, either for the next action or for the envisioned project outcome.

However, in a closed mode, I am significantly less likely to define those breakthrough projects that will make a real difference to my business. Hence, when I am thinking about what to do and how to do it, I am very much in an open mode.

We create in the open mode, and execute in the closed mode. To me, collection requires at least part of the time spent collecting in an open mode.

Conditions to make play likely to occur

Now, all this is easier said than done. Because becoming creative is something that appears not that easy. Or is it? Getting into the open mode can be facilitated, according to John Cleese, by the following conditions.

1. Space: seal yourself off from the world, so you can play undisturbed;
2. Time: there needs to be a specific moment for space to start and stop: you need this to allow yourself to seal yourself away from the world. If there is no time limit, you will be taking care of business prior to being creative. But given business never stops, you may never actually get to the point where you have time to be creative;
3. Time: the time alloted needs to be adequate (Cleese states about 1.30 hrs) but limited: it allows you to think about multiple solutions to the problems, but without an eternity to ponder. However, as Cleese stresses, you need to stick with your challenge, with your play, with your ideas, longer than you would. You need to consciously refuse to cave to the pressure your entire being is putting on you to avoid the uncomfortable feeling you have when you have "found your keys". Creativity is about sticking with it for longer. It's quite interesting that this is almost the same as the point made by Richard Feynman as the main reason why he was always getting into adventures: he had the ability to wait and stick with a problem. Read his excellent biography if you have the option.
4. Confidence: Don't be afraid to make mistakes. This is interesting in a GTD context, because capture actually allows you to make mistakes. During processing, a rather closed mode activity, you can discard those ideas that are illogical or wrong. However, while you are being creative, as Cleese states, nothing is wrong;
5. Humor: It gets us from closed to open quicker than anything else. Again, the fact we often feel we need to be very serious and solemn about something may actually impede us from finding creative, breakthrough solutions.

Creativity and GTD collection

A Linked-In group member asked me in one of the comments to a recent blog post how I actually do collection. Well, I do collection partly in a structured, relatively closed mode, using a trigger list and reviewing a number of feeds I track on a daily basis. But I also use some time during lunch and in the evening to allow myself to play, in a totally open mode.

Practically, I have two lists, two projectsreally , in OmniFocus. One is a list with play ideas for home, one is a list with play ideas for work. I note them down as they occur and park them there for the next session, where I pick and choose if I feel like it. None of the items on there qualify as urgent or required. They are just ideas, and these two lists are really the only exception to my rule to process everything in the inbox.

Whenever I have play time, I just kick back, relax and see what triggers me. It may be one of the lists. It may be something else. But it actually makes for some of the most exciting and relevant project ideas I have developed over the years. And on occasion this free thinking has allowed me to think my way out of a problem. And that, dear reader, is pretty neat.

Time tracking

An offhand remark in one of the comments posted by one of the participants in the Linked-In group "Getting Things Done - Network of GTD enthusiasts" triggered this post.

In his comment, the reader refers to a tool called "Toggl" which allows you to measure and track your time usage. I've used quite a few different time tracking tools myself. I'm currently using a tool called OfficeTime, but there are quite a few good options out there, some more costly than others. What I liked about OfficeTime is that there was a one time fee which gave me access to all the features in the application.

As stated before, I'm an internal auditor. So basically, keeping track of my time and ensuring that my time usage is the most optimal possible is pretty much second nature to me. Yet, and this is slightly disconcerting, I find myself losing focus when I am not tracking my time. Which is why, professionally speaking at least, I track my time usage pretty much all the time. It may be I'm in a meeting, at which point I will log my time using a dedicated iPhone application. And when I'm at my computer, I have a number of visual cues offered to me by the time tracking application I currently use, which remind me that I need to make sure and log my time appropriately.

Let me quickly take you through my setup and how I go about tracking my time. I'm going to try to do this as application agnostic as possible, but it may be referring to function specific to the OfficeTime application. I'm quite certain that while certain aspects of the application may not explicitly exist in other applications, the functionalities of the good time tracking applications are comparable.

Setting up the time tracking application

One of the first things I did was to make sure that I had a place to put the relevant information about my actual task execution. In short, I had to be able to log my time to specific projects as defined in my GTD project list. And there's a very simple way to go about that, you just copy your GTD project list into the time tracking application. Which is exactly what I did.

As to maintenance, I go through my project list once a week during the weekly review. If projects need to be added, I will add them to the application at that time.

After gathering data for a couple of days, I noticed that this approach did not allow me to accumulate data specific to my areas of responsibility. I knew what I was working on, but failed to see how it related to my higher sets of objectives. There was no link to the higher GTD horizons of focus.

Let's be very concrete. It's important that I know how much time we dedicate to compliance auditing and how much time to forensic work and the management of our integrity desk. I need to know how much time we spend doing pure administration, such as answering email, and how much time we invested in training development and delivery as well as following training to ensure we fulfill our Continued Professional Education requirements.

None of these dimensions fit the bill of what we would consider projects in GTD parlance, usually found at the 10.000 ft level. These are rather clusters of projects which are labeled as areas of responsibility, and which we find at the 20.000 ft level in GTD's Horizons of Focus. The application allows me to use and name an additional level which is "categories" and I use those categories to integrate these areas of responsibility. I'm quite probably losing a reporting dimension using the tool in such a way but the approach provides me with a lot of clarity on where I'm actually spending my time at a level higher than projects.

So, I have all my professional projects coded into my system, and I have a 20.000 ft area of responsibilities dimension coded as well.

Tracking the time

Now time tracking becomes easy. Whenever I'm working on a specific project, which is automatically associated with an area of responsibility, I just click on the application, select the project and it starts tracking my time on that project.

If I get interrupted, which does happen on occasion, I just pause the timer, put away the documents I was working on and dedicate my time to the people visiting my office. Believe it or not, I actually have a project just for that type of interruptions. My initial reticence to activate this project in the presence of other people has disappeared a lot quicker than I actually imagined it would. Whenever they leave, I return to the task at hand, I stop their timer, take out or open my documents again and start tracking my ongoing project.

This of course does not solve the issue on how to track individual next actions. The point is, I really don't. What I do is once I finish working on a certain project, I will log a reference to the next actions executed in the comments. During actual execution it is too cumbersome to hop into the application, making comments, and back out. That would require just too many tool switches, rendering the whole exercise too labor intensive and hence likely to be abandoned. And I actually have a detailed good track of which next actions I have handled by ticking off my next actions in OmniFocus. Providing too much detail in my time tracking software would create redundant information with an additional challenge of reconciling this information between OfficeTime and OmniFocus. And that's just not worth it. There is no direct added value of coding that information twice.

Reporting

I keep a daily, weekly and monthly track of where we spend time in our projects. As internal auditors, we do have a requirement to be accountable. Accountable for the quality of our work, but also accountable for the time we spent. And in my case, heading the internal audit of a publicly funded organization, the Belgian Development Agency, this becomes even more important.

The data gathered by means of time tracking allows us to analyze in a lot more detail what we are doing and how we are doing it. That goes beyond the mere requirements of reporting to our stakeholders. It allows us to analyze with a fine tooth comb where we put our attention and our effort given our limited resources. Does it align with our yearly planning? Does it make sense? Are we, in other words, doing the right things? And are we doing those right things in the best possible, read most efficient manner?

And if not, what is the purpose? Did we fail to adequately prepare? Are the resources dedicated to the audit the right ones? Has the auditee properly prepared for the audit? And most importantly, we go and dig deep into the reaons to ensure better performance in the future.

GTD as a measure of performance

By combining basic GTD principles with the principles of time tracking, and by being consistent in their application, we can now with reasonable certainty say that we are working on what we should be working on, that we are not distracted by other things. And whenever we get distracted, by people coming to visit us, discussing things, offering ideas, we know how much time we spend on that. And whenever I feel that that gets too much we just close the door. And we focus on what matters most.

Task list contamination

Timing myself

I've recently been spending a lot of time timing myself, using tools such as OfficeTime and Timing. As internal auditor it is very important to keep detailed logs of our time usage. We want to make sure that we spent adequate time on the right activities and as limited time as possible on activities with lower added value. It really doesn't make us internal auditors that different from ordinary people, now does it?

Lots of time spent planning

One of the things that I noticed when looking at my detailed time logs, is that I spend a lot of time planning my activities. For anyone who's had some experience with internal auditors, that seems obvious. Most auditors want to make sure that they understand very well what they will be doing next before they actually do it. And there's a very simple reason for this. We want to avoid wasting your time and our own. Still, it struck me how much time I spend in analyzing what my concrete and very specific next actions will be.

Avoiding task list contamination

And by analyzing needs a little bit more in detail, spending even more time in looking into this specific aspect of my planning cycle, I started to understand that I try to avoid is task list contamination.

What is task list contamination? It is a situation in which the concrete next actions have not been adequately and uniquely defined. Rather than a set of specific next actions, linked to a context and in clear relation to an envisioned outcome, you are confronted with a confusing jumble of information that you still need to think about when you're trying to execute.
In other words, you have gathered a lot of information in your system and processed it but failed to adequately clarify what it actually means to you and what is expected of you. Your task list, which should be geared towards executing very concrete next actions, contains "stuff". You cannot get to processing because your task list is completely and totally unclear. And that is a problem. Because if I do not know what I need to concretely "do" next, I have no way of actually finding out whether it is relevant and whether I did it the right way.

Outcomes influence next actions

But how come that we quite often have a lot of difficulty clearly determining what the next concrete action should be? One of the key contributing factors in lower quality task lists is the lack of a clear outcome of the individual projects that the tasks relate to.

Now, do not get me wrong. I am not saying that every project should have an outcome defined in such a manner that the result is fully clear at the outset of the project. That is not possble. Not all projects can be defined that easily in terms of outcome. Quite often because the outcome is not clear yet. What I do mean is that we need to be clear on why we do the project in the first place and what we hope to achieve with it ... hence, the outcome, to a certain extent.

An illustration

Let's consider a very simple example. Imagine that I'm doing some research on the Internet and I happen upon a potentially interesting piece of software. It's not directly related to what I'm currently researching, so I make a note that I need to go and look into this later.

What I have now is a situation in which I have an undefined activity in my inbox that states "look into this interesting piece of software", ideally with a reference. I think most of us will agree that it is extremely tempting to try to move this out of the inbox and into a "research" project and linked to a context which may be "@online", "@computer" or wherever I am most likely to conduct my research. But do you feel the problem?

"Look into" is perhaps an interesting activity, but it is not a well-defined next action. I do not you know whether it is a next action to begin with.

Why? Well because I do not yet know what "look into" actually entails. If I take a couple of steps back it seems obvious that "look into" is not restricted to just one very specific and concrete action. It's very likely that "look into" is the first to a number of very specific steps that I need to take in order to understand whether or not this piece of software actually has any further relevance for me. So just leaving "look into" out there and moving it into my task list is simply not enough.

It complicates my life. It takes me away from what I should be doing when I touch my task list, which is execution. Rather, it requires me to go back and think about this problem yet again. And that is of course a very big no-no in canonical GTD. And rightly so.

Trust is everything

This is fundamental. If I fail to correctly identify everything that goes out of my inbox and into my GTD to do lists, I created a situation in which I jeopardize the quality, and even more importantly the trustworthiness of my task management system. If I can no longer trust that my system will serve me only those next actions that are relevant to me in the context or specific situation in which I find myself, the system is of no use to me at all.

Separate your GTD activities

In conclusion, spending the time to clarify both my projects and my next actions allows me to be more effective later. When I see something interesting during research or during audit preparation it is not up to me to decide then and there whether or not it is relevant. However, before it leaves my inbox I should. To be most effective GTD you need to clearly separate the different GTD activities. Processing and execution should never be mingled together because then you create a muck which will not allow you to be both effective and efficient.

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

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

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

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

My past RSS workflow

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

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

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

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

My current RSS workflow

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

My IFTTT scenario

Step 1 - Selecting the first trigger

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

Step 2 - Choosing a trigger

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

Step 3 - Completing the trigger fields

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

Step 4 - Choosing an action channel

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

Step 5 - Choosing an action

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

Step 6 - Complete the action fields

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

Step 7 - Create and activate

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

Apple's maturity - Ubiquitous and imperceptible interoperability

I am assuming (most) analysts are not stupid

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

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

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

Developing a commodity within a walled garden

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

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

Ubiquitous and imperceptible interoperability

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

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

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

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

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

Any compatible tool will do

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

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

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

Emphasizing the identity of solutions

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

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

Safe and protected in that walled garden

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

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

There are no distinct markets

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

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

My OmniFocus work perspectives

The investment pays off

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

Defining "perspectives"

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

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

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

On the shoulders of giants

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

My work perspective structure

I actually use three distinct work perspectives, as follows:

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

Let's examine each of them in more detail

My daily planning perspective: "to do @work"

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

My to do @work perspective

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

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

The morning perspective: today @work

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

My today @work perspective

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

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

The focus perspective: next action @work

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

My Next Action @work perspective

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

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

In conclusion

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

About muscle memory and luck

Admiration and jealousy

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

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

It is not about fairness

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

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

Almost everyone you admire has done the work

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

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

It's about the journey

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

GTD has never been about the shortcut

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

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

Getting good at life

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

How our failure to fail impedes our success

Sven is onto something

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

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

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

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

We can no longer recognize the merit in our failures

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

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

A pressure to perform

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

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

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

Outcome creep

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

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

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

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

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

Solving the problem

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

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

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

In closing - Acumen's Manifesto

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

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

An assessment of my morning information gathering and capture mechanisms

Information is all around us

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

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

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

A Catch-22?

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

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

My daily morning routine

Waking up

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

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

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

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

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

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

On my way to work

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

In the office

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

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

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

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

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

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

Using programme and project management systems in development aid

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

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

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

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

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

Managers and experts on a collision course?

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

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

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

Programme and project management at the crossroads of management and expertise

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

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

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

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

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

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

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

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

An opportunity rather than an issue

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

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

In conclusion

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

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

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

Adequate risk management requires responsibility and response-ability

The other side of the coin

A couple of days ago, I wrote an article on risk acceptance and how it actually requires a lot of work in terms of contingency planning. Of course, there is another side to that coin.

The curse of middle management

What is the scope of your responsibility? How able are you to respond to challenges that come your way? If you are an average middle manager in an average organisation, my guess is: not that wide. Our traditional, hierarchically built, production oriented organisations seldom give any real delegated authority to middle management.

This, by the way, is not the "fault" of senior management. It's likely to be a combination of three key factors:

• The traditional structure of organisations, which are built for industrial production optimization. Industrial production entailed making a lot of the same things at an as low a cost as possible. Hence, the need for middle management (shop floor management) decisions was likely limited to hiring and firing what in the production mentality were replaceable assets (i.e. workers) and how to "organize" the daily work. There was no real need for middle management to be able to respond outside of the framework of a very limited set of parameters. In short, our traditional organisational structures do not promote middle management taking broad responsibilities.
• the traditional training and schooling of our middle management, which, especially in larger organisations, waits and sees before acting. By waiting and seeing, you are limiting your own ability to respond, of course. I'm with Sir Ken Robinson when he states that our current schooling does not respond to the needs of our current environment, but that's another blog post, or perhaps even a book. In short, middle management has not been trained to be assertive in taking responsibility.
• the hierarchical structure itself, which traditionally does not promote (both literally and figuratively) people who take too much initiative and come and ask for formal authorisation later. Traditional hierarchies promote like-minded, hence predictable people. This makes "renewal" less evident. It's interesting to see that this holds even in organisations that proclaim their own innovative approaches, such as major consulting organisations. In short, even if middle management would take the initiative, it would not necessarily be appreciated in most organisations.

Back to risk management

With risk "management" becoming more and more embedded in organisations, it does not pay to make risk management only about risk identification at the middle management layer, with decisions to be taken only at the top management level. If that were to be the purpose, I would propose to automate middle management to the maximum extent possible, as the cost to benefit ratio would never be positive enough to actually keep real people in play.

Middle management, ideally the management layer closest to day-to-day operations, is the management layer which is the most intimately aware of what can go wrong in day-to-day activities. Rather than establishing an elaborate reporting system where all information needs to go to top management for decisions, it would pay to make the middle management responsible and hence able to respond to certain types of risks, without the need to consult (hence bother and pull away from other, more strategic responsibillities) top management.

How to?

This of course all remains rather conceptual. What do we need to do in order to make sure that our middle management has adequate means and abilities to deal with the risks they are being faced with? The solution I propose here is not new. About 10 years ago, Josiane Van Waesberghe and I wrote what would eventually become the MobiRisk methodology, which went on to win the European strategic risk management award in 2009.

In this methodology, we were thinking about how to solve these issues as well. When the main reasons we started to look at this problem is because we noted that quite a few middle managers were unable or unwilling to go beyond the very restrictive scope of their authority in order to deal with problems.

In other words, because they did not feel responsible they were not able to provide an adequate response. And sadly, this has become more the rule rather than the exception. The fear of making a mistake leads people to no longer decide at all. The responsibility for all issues, including operational ones, is being put on the shoulders off top management. But we should never forget that top management was not necessarily selected for its operational competencies. Rather, they are responsible for managing a strategy.
Of course, this digression does not bring us closer to a solution. So let me offer my five cents worth.

One of the solutions that we came up with is to have top management agree on the principles of risk management, and leave actual execution to middle management. That of course requires adequate monitoring. This simple but in my experience rather effective approach gives the ability to response to middle management, while asking top management to make the initial decision on how to deal with this type of problem. This approach recognizes the issues raised above, and deals with them appropriately, but not in an aggressive manner. It is important to recognize that certain sensitivities remain and need to be correctly addressed. It would be an illusion to believe that these deeply embedded, structural issues can be resolved in a couple of days.

Practically

A middle manager discovers a risk, or a real issue, in one of the activities under his responsibility. This risk has never been dealt with before in the organization. He or she knows this because he has consulted the risk reference framework for his organization. The risk reference framework is nothing but a structured repository of answers the organization has developed for risks it has encountered before.

The manager consults with his operational experts and these A proposed solution for the problem. He proposes this solution to top management, which considers not only the solution but the overall impact On the other responsibilities. In case the solution is deemed acceptable, the middle manager gets a go. In case it is not, the remarks are communicated to the middle manager, who goes back to the drawing board.

All accepted solutions are captured in the risk reference framework, where they will remain available for the entire organization.

Consequences

The consequences of this approach are interesting. First it actively involves top management in the decision on how to deal with a specific risk. However, they're not alone in this. They use the experience available in the organization to solve the problem.

On the other hand it enables middle management to take more and more responsibility in the actual day-to-day management of the risk. This is important because it moves them beyond the traditional risk identification towards an approach in which they take real responsibility in order to deal with the problems that they're facing.

This approach recognizes the important role of top management while at the same time ensuring that middle-management plays its core role in the day-to-day management of risks. In order to do that they need to be recognized by top management as being authorized and relevant to do that work.

Risk acceptance requires hard work

Rereading the title of this post, my first reaction is that this is stating the blindingly obvious. The problem is, in reality this is far from that obvious. More than once I've been confronted with situations in which risk acceptance by a manager turned out to become risk ignorance. And risk ignorance is just another way of saying that someone no longer feels responsible for dealing with the risk.

This may come as a shock: any identified risk in your area of responsibility falls under your responsibility, whatever your preferred risk treatment will be. Sadly, that is quite often not the case.

Accepting a risk is not the end of management responsibility

Some managers believe that accepting risks, whether related to issues raised in an internal audit report or identified based on appropriate risk management, is the end of it. By accepting risks, they often feel they can make the demon of having to solve a problem go away. They feel they can sleep soundly ... at least for a while.

Of course, nothing is further from the truth. As I stated above, all identified risks needs to be properly managed. Risk acceptance is a risk management option, but choosing to accept a risk does not imply that risk has gone away or no longer matters to you.

On the contrary, it puts the burden of making sure the organization is adequately prepared to deal with that risk plainly with the responsible manager. After all, as a manager, if you have been informed of an issue and you have accepted the risks related to the issue, you need to be ready to deal with that risk if and when it occurs. That's called contingency planning, and it may actually involve quite a lot more work that you believe it does. Let's examine why this is so very important.

Accepting the risk is not ignoring its potential consequences

Let's illustrate the issue with a concrete example most of us can associate with:

Imagine you are driving a car faster than you are allowed to drive it. Your risk of having an accident will increase. You accept that risk by making the decision to drive faster as well as by the actual act of driving faster. Hence, you have accepted that risk.

Now, does that attitude of risk acceptance allow you to ignore any required contingencies you would normally take, such as having a fire extinguisher in the car and making sure your airbags are functioning correctly? Let's be clear ... it does not.

Whether we are talking about driving a car or managing an organisation, the same principles apply. The fact that you consciously decide to accept an exposure does not free you from the burden of managing the organisation, the entity or the process you are responsible for. To make it crystal clear, risk acceptance assumes that the responsible manager is fully aware of the potential yet very concrete consequences a risk occurrence may have as well as what needs to be done to deal with that contingency. You cannot avoid that responsibility. At all.

In essence, each manager is responsible for exercising the due diligent behavior with respect to the responsibilities that have been delegated to him or her. Correct behavior is then not ignoring a risk you have "accepted", but preparing your organisation for the eventual possibility that the risk may occur. Rather than working on reducing the likelihood of occurrence of a risk, you focus on reducing the impact if it were to occur.

Let's revisit our speeding example. Your car is, or should be, equipped with minimum safety measures, such as a fire extinguisher or airbags. If the risk of an accident were to occur, you will be bruised, but hopefully safer than you would have been without those measures. You will still face a loss, in this case the car or the convenience of driving your own car for a while, but the loss will ideally not be of a completely disruptive nature.

Lack of due diligent behavior requires removal

In the same vein, all managers should regularly review the risks they have accepted and assess whether or not there are measures in place to deal with the potential impact of a mishap. If these measures do not exist, I firmly state that the manager has not shown due diligent behavior. In that case, the board should take all appropriate actions to remove this manager from his or her position.

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

The challenge of compliance

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

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

Compliance as a function of perceived fairness

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

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

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

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

Increasing the perception of fairness

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

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

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

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

Killing our local heroes

From extraordinary to commonplace

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

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

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

The cost of our current progress

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

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

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

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

Virtual deity

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

Global heros do not scale down so well

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

Cargo cult heroes

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

Becoming a hero requires you to do the work

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

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

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

Practical steps to wider adoption of risk management: simplifying risk models for more frequent use

What went before ...

In the early '00s, the relevance of using risk models was very much disputed. A number of leading companies in the risk management field did not see the reason to use models, as they felt that practice impeded organizations from assessing the entirety of their risks. In the late '90's of the past century, Arthur Andersen was one of the first companies to start structuring risk models as a basis for the structural implementation of enterprise (wide) risk management.

The wider adoption of risk models

Risk models really came to the fore towards the end of the '00s, when experiments in implementing enterprise risk management or ERM systems showed a significant flaw in the prior reasoning: people did not share a mutual understanding of the term 'risk', much less individual risks. They even failed to agree on a common definition for the most traditional of risks.

This was broadly solved by the development of risk models: industry specific structured overviews of potential risks which could occur in companies active in a certain industry, with a clear definition of what the risk means in agreed upon terms. Agreed upon terms would be adapted to company specific terms, in order to limit the risk of misunderstanding and thus mistreatment of a specific risk.

The challenge of today's risk models

But in our quest to increase the transparency and the unified interpretation of risk models, I fear we may have overcomplicated matters. We actually overcomplicated risk models themselves.

Overcomplicating a risk model – or any model for that matter – lowers the adoption rates by its potential users. It's pretty much like using formula in a book, or in a blog post for that matter. It is 'understood' that each formula halves your audience. Risk models are not necessarily different. The more specific the model, the fewer its users.

Therefore, while the move towards a more complex set of risk models was necessary to develop enough detail in the risk models, we now need to make the reverse move. This move should not be towards no risk models, but towards another method of using these risk models. What I have in mind is a list, an overview of possible risks.

The added value of risk management

Let's examine what the actual added value of risk management can be? It is the optimization of our response to priority, identifiable risks if and when they occur. I may be insulting quite a few experts with the following statement, but risk management should NOT be a central pillar of a management system. It adds to better risk response, and can be added to ways in which an organization is run, but should not be the central element.

In essence, even if no management exists, this would not preclude risk management systems to exist across an entity or a group of entities.

An example of simplied risk models in risk management - the case of distributed ad hoc structures

The context of the example

We see the demise of certain (types of) corporations, especially, but not only in the services sector. These mastodont, monolythical structures are being replaced by decentral, distributed networks of independent contractors which come together on a project-by-project basis. This is the context in which I want to develop this short example.

The case for risk management

Given their increased exposure to larger and larger projects, hence larger and larger responsibilities and linked to that larger and larger potential liabilities, perhaps now more than ever, these decentralized networks need risk management, but they inherently do not have a management structure to, well, structure or 'manage' their risk management.

A quick detour - the trigger list in Getting Things Done

So, how do you manage risk in a distributed, decentralized environment, or in any type of environment for that matter, in an as cost-effective way as possible? You develop a risk trigger list for that specific environment or for that specific project they are engaging in.

Actually, this idea is not new. I borrow the central idea from David Allen, who in his excellent book "Getting Things Done" refers to an incompletion trigger list as an essential tool for the brain dump, in essence a way of clearing any issues in your head and getting them on paper, for further processing.

The trigger list is a very powerful tool: it is small enough (David Allen's trigger list, here in its excellent Merlin Mann interpretation covers at most 2 modest pages) to be used on a regular basis and yet complete enough so all elements you may have forgotten can be dealt with. What is even more interesting is that the tool can be used again and again in the same type of environment, and is easily adaptable to other types of environment.

The solution - The Risk trigger list

In order to enhance adoption of risk management as a tool, in order to make it usable on a regular basis and complete enough to deal with most risks one could forget about, I advise to develop a risk trigger list per project, process, organization or even industry. This trigger list, which should not be more than 2 pages long, contains trigger words, words that will result in a comprehensive listing of most of the relevant risks which can occur in that process, project, organization or industry.

You may be surprised. At least per industry, I believe at least 50% of the risks will be the same across organizations. The list will partly be generic, and partly specific to the organization, the process or the project. Developing a risk trigger list should be one of the first responsibilities in any new process or project.

The relevance

By simplifying the comprehensive risk models we've developed in the past 10 years and condensing them into risk trigger lists, we may reach the critical threshold to wider adoption of risk management principles, which will in turn lead to better managed processes, projects, organizations and industries.

Stakeholder perception as a third risk dimension

The limitations of current risk management approaches

Risk management is most usually limited to the organization whose risks are being analyzed. Stakeholders are considered in most frameworks, but often only in the context of information and communication. They are seldom considered an active, contributing party in the context of risk assessment. Adding a third dimension to risk management by identifying, analyzing and prioritizing the risks as seen by stakeholders, will yield important insights and assist in saving the organization's license to operate.

Why stakeholder perception matters

Your organization does not operate in a void. Risks are certain to threaten it, and some of these risks will also significantly impact your environment and other stakeholders active in this environment. And of course your stakeholders will react to the exposures they experience. Exposures caused directly or indirectly by your organization. In a worst case situation, their perception of an issue where you are convinced no real risks exist may create an issue where you expected none. If this catches you unaware, you have a real, additional exposure on your hands, an exposure you will have to manage.

Just imagine the following situation … your company operates a production site which treats certain types of contaminated materials. In order to process these materials, you need the authorization of the local authorities. No matter how safe your operation actually is, if you cannot convince the stakeholders present in that environment of that very simple and to you more than obvious fact, they may convince the local authorities not to extend the license to operate for your authorization. Do you have a plan B? Can your organization carry the costs of moving your clean-up activities elsewhere? Can you deal with the possibility of having to move your entire operation? In less than a year?

Stakeholder analysis

How do you know what is bothering the relevant stakeholders? I may be reaching here, but perhaps you should ask them. It may be a rather novel or even a revolutionary idea, but approaching your stakeholders with questions on what they deem to be important, ideally introducing them to the exercises you have been running internally to assess your risks and even clearly showing them your current risk mitigation is not always a bad idea. In some cases, it may actually be a first step in establishing a true relationship or at least a regular communication with these stakeholders. In essence, you are applying the 'First seek to understand' principle Stephen Covey promoted. Doing this will increase your understanding of their concerns. Be aware that these are real risks to you if they can threaten any aspect of your business.

So, you could imagine yourself, in some future, querying your stakeholders on their concerns, checking whether their concerns map to your internal risk model and add the risks you did not take in account. Let them go through an exercise similar to the exercise your collaborators go through. Let them evaluate their perception of the current level of residual risk (impact and likelihood from their perspective) and their assessment of the current level of control or current level of effort.

We all have a natural resistance to bothering other people with our questions, ignoring that just asking the question can be considered to be a sign of appreciation, of relevance and may lead to the initiation of relationship.

An illustration

Now imagine the following scenario, which I will call scenario 1: You spend a lot of time communicating on your corporate social responsibility, and note this message comes across really well. There is no significant difference between the perception of your stakeholders and the internal perception of the risk in your organization. You will not need to spend a higher effort in managing the perception of your stakeholders in terms of your CSR activities.

However, in scenario 2 you have spent a significant effort in securing your waste transportation activities. Your engineers confirm there is little to no exposure to the environment nor to the stakeholders active in this environment. You failed to communicate this appropriately, focusing on the technical aspects only. The stakeholders are not convinced and consider the actual risk to be significantly higher than you engineers lead you to believe. You have an issue, even if your processes are in fact under control.

Even if you haven't seen it, it is still there

In conclusion, You need to be continuously aware that the risk as perceived by your stakeholders can evolve into a very real risk to you.

How? The stakeholders can influence or even determine the validity of your license to operate. In the case of the example scenario 2 above the stakeholders can organize themselves and become a pressure group challenging your license at the local government level. In turn, the local government can decide to raise your taxes or even deny an extension to your current license. Each of these possibilities will cost you money.

Some further thoughts on professional service (de)commoditization

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

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

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

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

Differentiation in services

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

Why consulting is like plumbing

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

Consulting organizations continuously undermine their own effort

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

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

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

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

Be truthful

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

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

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

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