Moving to OmniFocus (Kind of)

Merlin Mann has posted what amounts to an advisory on moving to OmniFocus. His caveat essentially boils down to the fact that you should review your practices and current system to make certain that you are sticking to the tenets of the GTD system. During my brief tenure as a GTDer, I have switched tools numerous times, switching from paper-based, to iCal, to kGTD, and now iGTD. In addition to the desire to try something new, and the increasing bells and whistles that more polished and directed tools provide, the chance to do a GTD review is one of the driving factors for these upgrades. I am currently very happy with iGTD, but with the due diligence that seems to be going into OmniFocus, I feel it is worth my while to give this thing a trial.

Another reason for doing so, is to achieve exactly what Merlin outlines on his post. When I moved from kGTD to iGTD, it was only half-heartedly, giving it a shot out of curiosity. I had recently changed my work situation, so it was an easy way to switch working paradigms without scrapping everything. I did not however employ best practices in terms of having actionable “next actions” only and my projects have boiled down to amorphous and overly general hold-alls like “Around the House” and “Professional Growth”. One of the key features of any of these systems is the nestable project because pretty much every project is going to have sub-projects that are required to achieve the ultimate goal. For some reason, despite the fact (and likely due to the constraints of OmniOutliner) kGTD featured nested projects from the start, OmniFocus and iGTD added it in after the fact, since I had been employing the nested projects, these super-buckets emerged so that I could quickly clear the “professional growth” items from my list when I was in the mood to do chores “around the house”. I suppose this may be an issue with refining my contexts, especially since I am currently working from home, so far too many things fall into the “Home” context (I still maintain Work and At Computer contexts, but things still tend to blur).

Now that OmniFocus is offering the nested contexts and I better understand how to quickly access them (thanks Ethan), it is a perfect time to scrap everything and rebuild my task management from scratch. Basically, this consists of the following which aligns nicely with the whole initial set-up described by David Allen in Getting Things Done. I am maintaining, my iGTD in the background of this whole process, which while making for what is perhaps the most illogical and inefficient task management system, it does allow me to have a backup while OmniFocus is in Beta and allows me to see the pros and cons of each system. This is also going to create a bit of a conflict with my Treo and how data is handled there since I am only allowed a limited number of contexts there. That is easily resolved with a little cleaning up of contexts (and the imminent arrival of the iPhone).

The first step is a dump off all of the tasks via a handy tool called the printer. iGTD allows you to do some fairly granular filtering of tasks, so I am doing a pull of all ‘Current & Future’ tasks and ‘All Tasks’ (including Wait For and Delegated’)

Next comes the transfer and processing of tasks. This is a bit of a rehash of what Merlin outlines, but I assure you entirely unrelated since I am mid-transfer. I am looking for a few things as I look at each individual task:

• Contexts – I am going to be refining contexts, determining if anything that can be combined is (for example, I have Home, Social, and Time Off/Hobby which get a bit blurry), anything that is empty and unused gets dumped (I use text files for Agenda, and yet I for some reason maintain a context for them), Purposes are clarified (frequently Agenda and Brainstorm conflict) and additional contexts are added as necessary.
• Parallel versus Serial – One of the best new features of OmniFocus is that it allows projects to be classified as Serial (whereby tasks must be completed in order) and Parallel (items can be performed in any order). This dramatically affects how ‘next actions’ are displayed and therefore critical to implementation of OmniFocus
• Projects – Probably one of the biggest problems with the implementation of kGTD is confusing projects with actions. I intend to look at each task and determine whether or not it is an actionable item, if not it becomes a project or sub-project and actionable tasks are added beneath
• Timing and intent – in keeping with Merlin’s advice and actionable items a keen eye will be focused on whether a task is actionable now or something that I intend to do in the future (when I have the money, the time, the inclination) or whether it is just pie in the sky. You gotta be ruthless here!
• Recur versus Reset – This one is a bit subtle, but I think it is important to consider in the processing of your tasks. Let’s say you have a task that says ‘brush your teeth’ that is set to recur daily, you brush your teeth on Monday, but don’t check it off until Tuesday, since it recurs daily, you would then be prompted to brush your teeth on Tuesday. Conversely, if you set the task to reset daily, when you check that Monday task off on Tuesday, it will assume that you completed it on Tuesday and will not alert you until Wednesday to brush your teeth. If you have items that absolutely must occur on these intervals, then set them to recur, if it is willy nilly and more important that they actually happen than they happen at regular intervals, set it to reset.
  

Based on keeping each of these items in mind, it should be possible to get a pretty finely tuned GTD system up and running based on one that is currently in place. I will update things as they progress and be sure to note any snags that I hit in the process and more items that are worth consideration.

technorati tags:OmniFocus, iGTD, kGTD, 43Folders, GTD, Productivity

Blogged with Flock

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.