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.