The KISS approch to GTD project planning

I've never really got how projects work in GTD. I understand how "Next Actions Lists" worked, but never understood how multi-action projects worked in with that. This is what I came up with it. I'm not sure if this is how it's done in GTD or not.

Let's start with how a project is defined in GTD. A project is a goal that has multiple actions associated to it in order to reach completion. From what I've read of GTD, you keep those actions on a separate list than your "Next Actions" list. That's fine and dandy, but I never did that because it seemed to be just one more list to keep.

So what is this "Next Actions" list that I mentioned? Those familiar with the GTD process know it to be a list of atomic actions. Atomic actions are actions that cannot be broken up into subtasks. Since these actions are the simplest actions you can perform, they are the easiest to complete and it's easy to keep your work flowing smoothly.

This morning I have a project that I need to work on. It's a project that consists of a lot of subtasks of many different types (research, programming, documenting, testing) When looking at this project as a whole, it's overwhelming. I don't know where to start. So I thought, "Let me start with the goal, "Write a PUSH service for a search engine". That is an action that could be simply added to my task list, but it's not atomic. This action has many sub-actions, so therefore it's a project, not a next action. I need to break this up into atomic next actions. Anyone that knows how to factoring prime numbers, the process I used is similar to that.

So I started with the task:

  1. Write a PUSH service for a search engine

Next I thought what actions are needed to accomplish that:

1. Write a PUSH service for a search engine 1.1 Find out how to write a Mason template for the search engine system 1.2 Find out how to make it spit out XML 1.3 Write a template that will output the search results as XML

Ok, actions, 1.1 and 1.2 seem to be atomic to me. There isn't much more complexity to those actions. I could split it up further into, "1.1.1 Google for docs about Mason, 1.1.2 Read docs"... but let's not get obsessive now. There has to be some limit to factoring an action.

So 1.1 and 1.2 are atomic, groovy. Let's look at 1.3. I could say that 1.3 is atomic, it seems simple enough, but it really isn't. There are at least two actions I need to do.

1.3 Write a template that will output the search results as XML 1.3.1 Define the XML format that will be generated 1.3.2 Write Template

There might be more that that, but I'll revisit 1.3 when I get to it.

How does the "Next Action" list come into play? The Next Action list acts as a filter to keep only one action of a project in view at a time. So what I do is put, 1.1 on my next action list, when it's completed I put 1.2 on there, then 1.3.1 (not 1.3 because it's not atomic), then 1.3.2. I never have more than one atomic action from a project list on the next action list at a time.

Having only one item from the project list keeps my mind focused on the action at hand and not the whole project. I'm not tempted to look down the list and imagine the mammoth project that the ten actions scattered among the other actions represents. That's the point of GTD, keep the mind focused on the simplest thing and at a time when the mind should be focused on it.

The other advantage of not having all a project's actions on my next action list is my next action list isn't bloated by things I can not take care of before the action before them is completed. The next action list has to be a list of actions that any could be completed at this moment. No action can be dependent on another action.


1. Determine a goal, factor that goal into atomic actions. This is your project list. 2. Place only one action from the project list on your next action list 3. No action on your next action list can be dependent on another action

Final tip for project lists: Keep your project list simple as well. If your finding that your project has more that three levels, your project goal may be too lofty. Split the first level into sub-projects. You should never have to look at a single piece of paper and feel the world collapse, something is wrong, simplify.

Eric Moritz

Comments !