Getting Things Done is generally platform agnostic, with perhaps a slight bias toward paper. As such, people have implemented it any number of ways. I doubt any two people have the same methods. This leaves some gray areas, one of which is how to associate Next Actions with projects. It has plagued me since I started. Yesterday, after I sat down to brainstorm, I finally put the last piece in the puzzle and got the whole picture.

As a quick review, in GTD, a Next Action is the very next physical thing that needs to be done to accomplish a desired outcome. If one, and ONLY one action is required, then the action can stand on its own. However, if the action requires two or more physical actions to complete, it becomes a project.

Project is a loaded word. It can mean a vast number of things, and the differences have a big impact on how the next actions are associated and recorded. I’ve been re-reading GTD, and it’s a good thing, as it reminded me of a very useful detail: Next actions should advance toward desired outcomes.

My solution involves these three key things. I have slightly re-defined projects to make this all sane and self-consistent:

1. Desired outcome – Something that needs to Get Done. It can require one or more Next Actions, but it should not require parallel next actions. It may only require sequential Next Actions. Should be past or present tense.
2. Next Actions – these are the atoms of the system, in that they are the smallest singular and cohesive component. Again, these must be physical or pseudo-physical (i.e. Search for X on google). Given a desired outcome, a Next Action is the next physical action that you would do to pursue that outcome.
3. Projects – Projects are collections of desired outcomes that must occur either serially or in parallel. Typically for me a project will be an experiment, where say, there are a few Desired Outcomes involved in experiment set-up, which can be worked on in parallel, and Desired Outcomes such as “Parameter Foo experiments run” and “Parameter bar experiments run”, but the experiments can’t be started until the set-up outcomes have been accomplished.

This begs for an example, because it’s a little complex in words. I’m working on setting my old desktop linux box up as a new MythTV DVR for recording shows and cutting out commercials. I’ll use that project. It’s a “Project” as defined above. Here’s the list of desired outcomes I’ve outlined so far, as I have it on my wiki project page:

The first Desired Outcome, “Needed software listed” has been completed. I couldn’t do the rest until it had been completed. Once I finished it, I moved on to two items that can be done in parallel: “Software installed” and “TV recording works”. TV recording does depend somewhat on the software being installed, but first I have to splice the cable from the modem so that it goes to both my computer and the modem. I could also order and set up a remote, but I haven’t started that yet. The last desired outcome, “Jason notified I’m paying for cable” won’t happen until I actually get the box working — why pay for something I’m not using?

Wikis are too cumbersome to update continually with next actions, especially if it means you later have to copy each next action out and keep it in sync with iCal manually. I tried that for a while, and it really bogged me down. Wikis are, however, useful for tracking the higher-level, slower-changing aspects of a project, such as its Desired Outcomes.

So, now we have parallel outcomes, and you can see how that would occur, as well as how a multi-outcome project is organized. How does this go in the system? I have synthesized the PigPog method, which only works for serial-action or serial-outcome projects, with a suggestion based on one of David Allen’s clients does.

Any outcome that requires more than one step is listed with its associated project. If it’s not part of a project, it goes:

Some next action >> Desired outcome

However, if it’s part of a multi-outcome project, it becomes:

Project Name – Some next action >> Desired outcome

Basically, this should be all you need. Think about the desired outcome: when you finish the current next action, will you automatically know what comes next? If so, you’re done. If not, you might want to add notes on future next actions to the “notes” section of the task.

Despite some of its other issues, iCal has a very nice search feature. The little search bar is always at the bottom. If you want to check on the current outcomes/next actions associated with a project, you can just type the project name in:

Note the “mythtv” in the search box in the lower right.

This is a lot of writing, and I feel like this still might be unclear. Is there anything that seems particularly confusing?