Given the background about my use of GTD, now I get to into some new opinions.
I’ve been thinking a lot about personal productivity after getting a blast from the past and the emails it spawned about the persistent poor state of high volume email management.
In object oriented programming terms, GTD is an interface, and it doesn’t come with a reference implementation. It is exactly this lack of an implementation that leaves people struggling with the use of the system and its habits.
Each person implements GTD according to their primary constraint. For instance, if you have a high email volume to balance, you tend to look for a system that deals with your inbox and sorting and categorizing the emails into projects and next actions. If you’re highly nomadic, you might look for a more physical implementation such as as hipster PDA, so that you’re confident your system is always at hand.
Each of these systems needs to apologize for its underpinnings. The hipster folks have techniques for dealing with email, and the email folks might make tickler emails for the voicemails that they need to return. Or maybe they try a grander email system that integrates calendaring and todo items. But every time you integrate with a pre-existing system or concept, you have to compromise to put your round peg into the square hole.
I contend that even GTD suffers from its underpinnings of trying to be all things to all people. Because it lacks a system, it has introduced more elements than are necessary. For instance:
- The weekly review - It’s amazing how good this sounds, but it in practice its job is to patch up all the cracks resulting from a lack of an implementation. Known as “closing the open loops,” it wouldn’t be necessary if your implementation prevented the loops from getting buried in a folder. For example, if you have a high volume of next actions, you probably track those items per context. So each weekly review you have to review the lists to make sure the fact that you haven’t gone to the store this week isn’t blocking the ingredients need for the cake for the party this weekend.
- The project list - If I have faithfully made a folder for each project, why do I need to keep another piece of paper itemizing the folders in my stack?
- Actions vs Projects - Allen defines a project as anything that takes more than one task to complete. But since large projects aren’t a strict sequence of tasks, you end up with sub-projects. Suddenly, the scope of an item is obscured, and you lose the big view of your projects. ”Should I make a folder for this smaller item?”
- Hard edges – We’re encouraged to keep hard edges between the categories of things to keep track of. When the book lists the 7 primary types of things, they’re supposed to stay separate, or you’ll get really confused. But today’s “waiting for” list is tomorrow’s reference for why the project is late.
I know the book addresses many of these points. I’m not trying to throw out the whole system, or impugn the value of the habits and flow that GTD promotes. But I want to build the case for a fresh implementation of something that doesn’t have to apologize for its roots.
Comments are welcome. I’m actually hoping that this blog can become more of a discussion than just my soap box.