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.