Do future project actions go on actions? Dependencies?

Question

In the GTD system, Actions represents next actions -- things you can do now to do the next step. But I have a quandry: how do I handle future actions?

Let's say one project is "paint X for my living room." I may need to:

• Brainstorm
• Paint
• Frame it
• Hang it

(I removed concurrent next actions for the sake of focus and simplicity.) Now, how do I handle this?

• Do I put all four into Action -- although the latter three are not actionable yet?
• Do I keep them in stuff -- even though I know what to do with them?
• Or worse yet, do I keep them in my head until I've handled the predecessor items?

I favour the first option, since it allows me to brain-dump a list of actions and know "how many actions until I'm done this project?" The problem then becomes when I look for a next item -- I see a huge list of actions I can't even do yet, because of predecessor/successor relationships. (Which are not mapped anywhere.)

How do I solve this dilemma?

Answer 1

A number of the software options available provide for distinguishing between "actions" and "next actions". For an implementation agnostic approach, however, I've had the best luck with putting them in the project support notes.

All of my projects but the simplest have at least a bit of notes, where I jot down anything related to the project that comes into my head, including actions that will need to be taken at some point during the project. I don't put a lot of effort into arranging them "just so", as they usually change over the course of the project, but it gets them out of my head, which is much of the point of GTD.

The exact form of project notes can be quite varied - text files, handwritten pages, index cards, cell comments on a spreadsheet, a linked Evernote "note" . . . - so you should be able to work out a version that meshes with your current system.

Answer 2

GTD coaches compare those actions to bookmarks. Maybe you finish the brainstorming action and you keep going and start to paint. The moment you are interrupted, you write down what's the next action so that you remember it next time.

You can have several actions related to a same project, but only if they are not sequential. For example: you cannot frame something before you paint it, so there is not point in having to see that 'frame it' in your Next Action lists when, by the moment, it is still not a Next Action. If you do that, your brain has to triage whenever you look at that list if the actions are really doable or not, and that defies the whole purpose of a NA list; you want it to be like a buffet of direct, immediate things you can do in one sitting.

The actions that are not directly actionable by the moment would go in the project material folder.

Answer 3

This is going to be application specific, but here is what I do using Omnifocus:

If I just have a project that needs to be completed in a certain order, I set the project (or sub-project) type to sequential, that way Omnifocus knows that only the first action listed is currently available and once each item is completed, the next becomes available. You have the ability to collapse projects and sub-projects to hide them from view (so you don't see a huge list of actions).

If you are waiting for something to happen before you make more actions available, a Waiting context is also valuable.