Rethinking my GTD contexts in OmniFocus

The big idea

I have been rethinking my contexts based on a blog post I recently read and cannot, for the life of me, find back. The basic idea is to have two lists. The list of things to do today and the list of things to do. Each day, you transfer items from the second to the first list, and you work that list. If the tasks on the list are done, you're done for the day.
So, whereas my context before were a proper implementation of David Allen's GTD methodology, and quite complex, and actually never really used as they should have been, now they are simply lists of things to do today in a broad context, or things to do someday in a broad context. To date, it has really increased my output, because I am no longer focusing on the GTD process but rather on the content. Let me take you through this in more detail.

My original take on contexts

There's a great book on using OmniFocus with GTD on the Mac. The author is Couros Dini, and the book's title is TITLE. You can find it here. I organized my OmniFocus implementation pretty much as prescribed in the book, and it worked reasonably well for a while. I tweaked it and it worked even better. But, big but, I had to remember to check my OmniFocus perspectives when in a certain environment (which I define as a set of available contexts).
For example, when I was at work I had several contexts available to me. I had certain tools available, I was at a location and I had access to certain people. So my perspectives showed all the contexts available in that specific situation. My iphone set-up worked flawlessly: I was informed when I was in a certain context based on geo-location data. But, the system turned out to be too complex. I was spending a lot of time correctly linking tasks to contexts and projects to make sure that I was informed of the task, but ... I was not working the task.

Adapting the contexts

So based on a blog post which I can't remember the author of, I switched my approach. Rather than being confronted with tasks depending on context and start and due dates, I killed all my contexts and replaced them with the following very simple ones:

• Today @work: all the tasks I want to accomplish today at work
• Today @home: all the tasks I want to accomplish today at home
• This week @work: the list of tasks I aim to accomplish this week at work, which feed into the today list based on my consciuous decision during my daily review
• This week @home: idem for the @ work list, but then about tasks I aim to accomplish at home
• This month @work and This month @home: two lists which feeds into my this week list.
• Someday/Maybe @work and Someday/Maybe @home: two lists which feed into my this month or this week lists.

I lose some of the technical capabilities of the geo-location, however, as geo-location triggering is linked to the context, I have defined both Today @work and Today @home context with geo-location triggers. So for all that really matters, I still have the triggers. If I want to do certain activities elsewhere, I can create additional Today-contexts but this far I have refrained from doing that to keep this system simple and flat.

Remarks and ideas

Surely I could achieve this using the start and due dates. But the point is that changing a context for a task then becomes an automatic process, where I want this to be a consciuous decision. I'm in control of my time, not my task list. I am still working the list, but it is a list of my chosing, and the level of frustration I create by loading too many tasks onto that list is my own conscious decision, not dictated by a system.

Working on a (creative) task versus working in a context (UPDATED)

For those not familiar with GTD, David Allen’s highly successful personal productivity approach, get this book (please note this is my affiliate link, you can of course log onto Amazon yourself), and read the first three chapters. It’s worth it, if only for the different way you’ll be looking at your work and your life.
GTD refers to contexts, areas or situations in which you execute certain work. Context are one of three elements that help determine what you can best do next. The methodology suggests to try and remain in a context as long as possible to work optimally.

Why contexts matter

The idea of contexts is based on money concept of our modern production oriented society: working in a production line, executing a comparable task over and over again. The reason for this is simple, and still applies today: changes in tooling, sets of tools used in the execution of a task, cost time. This is non-productive time since you are not actually producing during the time allotted for the tool change. To optimize the production time, you minimize the need for tooling changes as well as the time required to change the tool. To put it simply, if you’re at your desk behind the computer in your word processor, stay there as long as possible.

The production belt or production chain is the ultimate tooling change optimization: you never change the tools, but the product, solution or whatever you’re working on in its different stages of completion moves through a set of tools.

Tool changes and sequential execution

Often contexts are related to tools or their modern day equivalents. Certain activities can only be executed in a certain environment, or requiring a certain tool, system, software or person only available at a certain place.

Imagine I’m working on a project. I have a task list with a certain sequence and dependencies. I first need to write this paper, then have it read by that person, then present it to that meeting, then have it signed of by that person … If I sequentially run through those activities, I will likely execute a good project. But, I will have a lot of non-productive time and idle time as well. After all, there’s a lot of tool set changes involved and a lot of waiting as well. I have to give the reviewer the time to review, I need to prepare the presentation, I need to see someone for his or her signature. Not really very productive at all.

In all of this, I’ve lost a lot of time. If I have more than one project, it pays to remain in a context to execute as many as possible the tasks I need to perform in that context prior to jumping to the next context. For example, it seems wise to first write all the papers you need to write prior to starting the development of your presentations. The tool switch cost from writing app to presentation app is minimized.

why contexts don’t always make sense

But this doesn’t always make sense. Certainly not in creative work.

Think about the following situation and its associated cost. I’m working on a project which requires me to write both a report and a supporting presentation. I’m also working on another, unrelated project with another presentation due. Which of the following would cost me most?

The tool switch or the mind switch? A mind switch requires me to abandon a train of thought in favor of another, while a tool switch requires me to abandon a set of tools in favor of another. I’m convinced that in certain cases the productivity impact of the mind switch is more significant than the productivity impact of the tool switch.

An illustration of the difference between mind and tool

Let me clarify: imagine you are asked to write a number of proposals. Part of this may be retrieving proposal templates or prior written proposals from a repository. The context here may be for example “online - proposal database” and for this activity a tool change is not appropriate. You get out of the proposal database what you need for the different proposals.

Once you have the templates, you start developing and writing. An important “meta-context” for me is mind mapping, but this is a meta context in that it often requires me to go through multiple tool switches during the activity. I do the mind mapping in Mindnode Pro, but I will frequently be switching back and forth between my browser, my notes (which I keep in text files in Dropbox) and the mindmapping software. For me, the frequent tool switches I make are actually part of the creative work. I can do this because the tools all together form the creative analysis and development context for me.

In essence, my context is no longer a unique context of one tool, one activity or one environment, but rather a set of complementary tools which together allow me to work towards a certain result.

UPDATE - A number of better GTD experts than me pointed out that there is no explicit mention of remaining in a context for as long as you can. I stand corrected, they are right. However, switching context too frequently often carries too high a tool switching cost, unless you have all your tools arranged in order to optimize efficient and effective use. Therefore, while it may not be explicitly mentioned, I do feel remaining in context is an important aspect to the entire productivity concept.