I’m a fairly new scholar in the art of GTD. Of course I have my problems — with getting started, with sticking to it, and with managing my lists (i.e. my tools). For this post, I’m going to focus on my take on projects. Or, I should say, project (singular).
Many GTDers are commenting on the problems with deciding the proper width and breadth of their projects; some people try to measure and compare the number of projects they have on their desk and then try to decide what that number means in terms of their GTD-fu.
David Allen often mentions the importance of creating clear and atomic next actions. When you’re doing your weekly review and are looking through your master project list, you come up with clear and atomic next actions for each. Perhaps I’m just wired differently than “The David” (or been programming for too long), but I have real trouble connecting the dots between a big fat project such as “Deploy BTT application” and the tiny concrete action to “email Amish re user load estimate” — it’s just too far a jump. No way am I going to get there from here; I need to go through a number of intermediate steps on the way. The deployment form wants to know the number of concurrent users. Amish is the contact point for end users. I should ask him to get me the figures. Then I can fill in the form.
Ah, but The David also says one should not have the same thought twice (and so on), so I probably should be making notes of these actions, be they proper next actions or not. So, I can either write more than only very next action items on my context lists, or I can queue up a bunch of ensuing actions on my project plan.
I should not be spending so much time on juggling sequent actions! There is simply too much rewriting and restructuring going on. Ideally, sequential actions ought to line up by themselves. I need to trust my system (another Davidism), but as long as I have no easy way of morphing projects to action lists (so I won’t weasel out of doing it), it is evident that I am only trusting it for input and output — not the part in the middle, the actual planning and rearranging into context lists.
One half of the solution to this is using an outlining editor. That, and discarding the notion of only tracking literal next actions. By doing this, you will allow your project outline — of which you will need exactly one — to contain a fractal of big projects, its constituent tasks, their prerequisites, and eventual next actions.
The best approach I’ve seen so far is Life Balance, but its interface is so horrible that the experience is, in a word, unbearable. That’s why on a daily basis I’m using Bonsai; its approach is different but the interface is very efficient. It’s just that I’m forced to arrange my actions in an awkward manner so they show up (only) when they should (once you’ve tried LB, you’ll know what I mean).
There’s a hidden trick here, and it may seem counter-intuitive at first, but try it and you’ll see why it works (in software that supports it): The trick to organizing a project outline for action is to store items that can be done in parallel as siblings, and nest sequential items so that the first items are the deepest. This way, all the endnodes (items with no subitems) are your next actions! Simple!
Think about this. It means that I have only one single project on my plate. Who cares how many projects you have? If you don’t factor in how much action is involved, the project count is a useless metric (I can lift one thousand rocks — if they’re all sufficiently small). It also means that once a project has run out of actions, the project itself appears on the action lists, ready to be ticked off as complete, finished, done.
So instead of counting how many projects you have on your plate, you should be counting ‘preprogrammed’ next actions. That tells you how far you’ve thunk ahead, a metric which is actually useful. If the number is low, you should sit down and plan some more actions in order to keep your momentum going.
The other half of the solution is to automate the process of looking through the (now fractal) project list, cull all the actionable items (the endnodes), and distribute them to appropriate context-specific next action lists. The last step requires that each item has a context flag; this is a natural thing to add when you’re writing the item in the first place.
Remarkably, there is no software that does this! I find this remarkable because (being a GTD newbie) I’ve been through my share of “productivity pr0n” to find a proper mobile GTD-centric application and, probably, so have the over seven thousand other members in the GTD_Palm newsgroup. We all use a more or less (mostly less) elegant combination of two to five built-in and third-party applications to manage our lists and GTD-ness. How did this become the ‘normal’ state of affairs? Anyway, we’re working on remedying that now.
> I have only one single project on my plate.
Not really, eh? You just have a wrapper with – …how many nodes is in the next level? I don’t see the point in having that top-level wrapper. Consider this:
According to your otherwise excellent concept, a project is done when it has no child nodes. That makes sense. But what happens when the first-level node (what I call the wrapper) has no more child nodes? Do you die?
The thing is, within a GTD perspective, you’re supposed to keep separate documents for each project, and separate pieces of paper for each to do item. Also, projects and actions are distinctly different.
For me it’s more natural to regard it all as one big fractal — anything can be broken down into subprojects until a project is indistinguishable from a concrete next action.
So in effect, the root node of my outline is “Life”. And yes, when it’s complete I die, happily. But then, I add so much new stuff constantly so that “right now, I’m so far behind I’ll never die”.