After reading Ben Brooks’ recent post on OmniFocus start dates, I thought I’d take a moment to talk about how my personal usage of start dates has changed as my OmniFocus workflow has evolved over the years.

When I first bought OmniFocus, I never used start dates. I processed my daily to-dos by using a handful of custom perspectives¹, flagging hot items, and setting due dates. In theory, this should have been fine, but when I asked myself, “what should I do today?” I was working way too hard to answer the question. The most obvious side effect of this era was due dates too often represented the days I aspired to get things done, as opposed to hard deadlines.²

Somewhere along the line, I began to use start dates as a way to define when tasks should hit my “to do” queue. My methodology during this phase was that a start date would represent the theoretical day that a task could be started, as opposed to when I was committed to starting it. This had the benefit of keeping the future stuff out, and then I’d surface the hot stuff from the currently available tasks by assigning flags or due dates in my daily or weekly reviews. For example, let’s say my task was to “call someone about something”. If I could potentially do that task on the day I created it (even if my schedule would most likely prevent me to do so), I would plug in a start date of “today”. Then when it became a priority, I’d flag it. I drove my workflow primarily with a single perspective that used a “Due or Flagged” status. This worked better but it still wasn’t as smooth as I thought it should be.

My final adjustment was based on modifying how I defined a start date. In my workflow today, start dates represent either the day I intend to complete the task, or the day I will evaluate when I am going to do it. The primary benefit is this has eliminated all of the cruft from my list of daily tasks. My daily routine is driven by a “Daily: Start” perspective which groups tasks by start date and sorts them by context. ³ If I don’t get to a task on the day it starts or if I decide it is not a priority anymore, I just defer the start date to the day I expect I will be able focus on it. If I’m unsure when that is, I typically defer the start date anywhere between one week and one month in the future, so I can re-evaluate it when I have a better view of my schedule.⁴

I’ve gone from never using to start dates to having them as the primary driver of my entire workflow. That said, the power of OmniFocus is it can be customized to your heart’s content, and this system is just what works for me. Your mileage may vary.

There is a very fine balance point of maximum effectiveness between simplicity and complexity of systems. How much detail, how much cross-referencing, how much coding and categorizing is enough, without becoming too cumbersome? Most of what’s out there to help is grossly overbuilt. Once you realize that you only need to define your projects with the next actions on them and keep track of all that in a complete but simple set of lists, you won’t need to bother yourself with much else. You’re better off being a good carpenter with a simple, well-balanced hammer than a novice with a garage full of unused power tools.

– David Allen, David Allen Company Email Newsletter July 19, 2010

I started a pretty serious test-run this week of TaskPaper as my GTD app in place of OmniFocus, so reading this in David Allen’s email newsletter today could not have been more timely.  While it’s still too early for me to say for sure if I’m sticking with it, the allure of TaskPaper is exactly what David Allen talks about above.  It gives you exactly what you need, but nothing more.

Side note: The simple act of writing this short blog post has invoked a subconcious fear that Merlin Mann will come out of the woods running and screaming that I need to stop talking about switching productivity apps and do something meaningful.