David Allen says no to Sequential projects

It’s set for 3 days.

No, this is a common misconception. The Next Action on your task list is just a place marker for a project you can’t progress right now.

Say your project (an outcome requiring more than one step to achieve) is to have Fiona approve your proposal. So you might think that you’d add

  • ask Jason for Fiona’s number
  • call Fiona to schedule meeting
  • send Fiona documents needed for meeting
  • meet with Fiona

to your task list, and check off each in turn.


The Next Action is “ask Jason for Fiona’s number”. Just that: a way marker for your progress towards completion of your project.

When Jason gives you Fiona’s number, you could call her immediately but, if you’re meeting with Jason, it’s more likely that you’ll add “call Fiona to schedule meeting” to your Inbox.

When you process your Inbox, you might call Fiona (Two Minute Rule: if it will take two minutes or less, do it now) but if you can’t (for whatever reason), your Next Action is now “call Fiona to schedule meeting”.

And so forth. Note that you only need to note down the Next Action when you can’t do it right now. But for years people (mostly those who haven’t read the book(s), have decided that GTD is about breaking projects down into two-minute-or-less “Next Actions” and ticking each off in turn.

In his books, David Allen recommends extensive use of checklists. Note that the OP says they haven’t read the book from which the quote is taken. I tried to use GTD for three years before I read the book “Getting Things Done”, and all became much clearer!


I have read the book and I think we are agreeing with each other. break a task down into actionable steps, forget what you have to do, trust the system to remind you of the actionable steps, do the actionable steps one at a time until the task is completed.

a lot of the time you have to do one thing before you can do another = sequential project; sometimes you have a bunch of stuff that can be done in any order - parallel project. But honestly, if all your projects are truly parallel then I really don’t think you’ve broken it down into actionable steps.

I suspect that we’d all agree that it’s easier to create a parallel project and then order the steps with dates or flags! sometimes you can choose to do some of the steps in a different order, but mostly that plays into the myth of multi-tasking - we can hold nine or so tasks in our head, but we can only act on one at a time effectively.

No, trust the system to remind you of the Next Action. Just the Next Action: the remaining actions may be noted in the Project plan, but should not be entered into your task manager.

It’s easier (for me, at least) to note just the Next Action as I reach a point in a project where I can’t proceed in my current Context(s) than it is to enter every action step in advance.

Sometimes there may be more than one Next Action. Once I have scheduled the meeting with Fiona, I may need to book a room in addition to sending her the documents for the meeting. If I can’t do either as soon as I’ve finished speaking to Fiona, I should capture them both and, if I can’t do either of them when I process my Inbox, I should enter both as Next Actions for the project. If the Project is set to parallel in OF, both will show up. If the Project is set to serial, one will block the other.

GTD is all about moving a project forward as soon as possible. If I find myself in a Context where I can book the room before I find myself in a Context where I can send the documents, but ‘book the room’ is after ‘send the documents’ in a serial OF Project, then I will miss the opportunity to move the project forward.

If I thought we’d meet in Fiona’s office, but Fiona ssks me to book a room when I speak to her, what seemed at the outset to be a serial project suddenly becomes parallel at that stage

How we each choose to work is entirely up to us, and OF has mutated over the years to accommodate approaches other than GTD, but to practice GTD as taught by davidco, you don’t enter into your task manager all of the steps of any project in advance, just the Next Action, hence their advice against setting OF Projects to serial: you don’t know when the project might evolve to have more than one Next Action.

Maybe a nuance, but I think I would disagree with this. I think GTD is most about making the best choices about what to do so that you can feel good about what you’re doing, and also good about what you’re not doing. In order to achieve this, you need to have worked the GTD process (capture, clarify, organize, review, engage).

I don’t think this means “capture only the next action”, but rather “if it’s on your mind, you’re not done with it yet”, so capturing as much as is necessary to get your mind clear is a good thing. And that can mean “pre-programming” some projects, either sequentially or in parallel. At the same time, I think it’s critical to have a solid awareness of what limitations you are invoking by setting up sequential work (actions aren’t available until their predecessors are completed) so that implications of the capture/clarify/organize are understood, or at least have a solid review approach to act as a failsafe for the spotting of actions that might be blocked in a system but which should be available.

The power of a system like OmniFocus is in allowing one to hide things until they are relevant (without needing to carry round the forty-three folders) so that one can place their attention on where it is needed, while still providing a facility for a high volume of capture.

Everyone’s mileage may vary, just thought I’d add a thought.



I don’t think I said you would… I still think we’re agreeing with each other. what do I do next to move this project forward seems to me to be the heart of GTD.

I do have projects, where I know exactly what the steps are, I also know they have to be done in order, and often these projects repeat - they will be sequential. The original post says that David Allen says no to sequential projects, I think they have a place. Your example is clearly not a serial project, but it doesn’t mean that you can’t ever use them. Installing WordPress (something I do a lot) is a sequential project. (with one or two interchangeable steps) I can’t install it until I’ve uploaded it to my web server, I I can’t install it until I have a database set up for it etc…

We really are agreeing!

Agree, the power of having sequential projects where you know the first couple of things that have to be done and that you can’t do the third thing until you’ve done the first two is very useful, but after that? OF makes it very easy to then make the project parallel.

I don’t think it’s sane to recommend using solely parallel projects. (maybe easier when you’re getting started perhaps…)

If I could offer my input on this subject, as I think this discussion highlights a pivotal piece of advice that newcomers can easily misinterpret as GTD gospel. I think the problems stem from people having such varied interpretations of the GTD models which are themselves just recommend best practices from a 20th century thinker. I also think David Allen’s comments and guidelines (including his personal statements, books, company, trainers, and associates & affiliates) are given far too much weight in how to be productive or actually accomplish goals and complete tasks (saying “getting things done” is such a misnomer in this context) in the minds of many. We need to evaluate everything with skepticism and critical analysis before we accept it as a good idea, let alone gospel-like truth.

The perspective that I often fail to see people consider is that in order to actually accomplish goals and complete tasks you should do whatever works for you; a variety of tools and tactics exist to make doing whatever works for you, be effective and efficient. I think anyone who makes blanket statements about never using a tool should be considered very lightly and with a huge grain of salt, without being cliche. Every tool has its appropriate usage and its corresponding antithesis of abuse. (Please note, I think many of David Allen’s (and DavidCo’s) statements are incorrectly interpreted. I believe this is the case as well because it’s often noted that the GTD setup guides on his site, whose target demographic is new comers to GTD, are just recommended guidelines to make initiating GTD easier).

Think of it in terms of a toolbox: you have a hammer, screwdriver, saw, and tape measure let’s say. Each tool has a valid and best-use-case scenario; we don’t throw the baby out with the bathwater when something doesn’t immediately work, we tweak it. Contrastingly, we need to consider that if the only tool in someone’s toolbox is a hammer then everything starts looking like a nail; this is obviously an incorrect approach as well.

I think OmniFocus’ solution is quite elegant and correct via offering both types (parallel and sequential projects) because many people have different approaches to personal project management. Some like large amounts of granular detail such like a full project management work breakdown structure while others prefer a more loosely interpretable adaption of an outline of general steps.

I, personally, use sequential projects a lot, but make it so that the “blocked” actions always show up as “blocked” in my perspectives so that I know they’re not immediate but could be available given a change in context (see many of the noted examples above using Fiona, these are good examples). The ones that are more bolded / brighter are the clear next action for that project and I always know where my attention should be directed but I can choose to ignore the order if it is appropriate. As I noted above, there are many ways to “skin the [proverbial] cat” and the best way is the way that is most efficient and effective per user.

On a side note, you could create an implementation of GTD ignoring project types via utilizing just tags and due/defer dates to determine if an action is the “Next Action” or “blocked”. I don’t recommend it for everyone (or ever a newer GTD aficionado), but when I mentioned the actually usable OmniFocus 3 to one of my like-minded friends, who rather disliked OF2’s lack of flexibility shall we say, immediately theorized and planned on implementing such a strategy into OF3 on his Mac.

1 Like

I think this is an important point. Some projects don’t need a lot of planning; other, more complicated ones, need a fair amount, because they have several moving parts and you don’t want to forget any of them. I don’t want to fetishize the Gospel of David Allen, but it is worth remembering that his account of the natural planning process does take that into account. It’s helpful to do as much planning as a given project needs, and that will depend on how complex it is and how often you do it. For me, teaching a university course is a very complex project, but I’ve been doing it for over two decades, so I don’t need to do a lot of planning for any given course, and my “next actions” are often quite broad. On the other hand, planning a trip across the Pacific Rim is something I’ve never done before, so my project for that is going to have a lot more steps, and I’m going to want to capture everything as I think of it. And then I might sort it into sequential and parallel action groups when I do a review, because some things must be done in order, while others can be done at any time.

I really WANT to believe that it’s all in the project plan until I pull the Next Action. But if the project’s execution has any nuances, they will all need to be in that plan. So then the plan has a list of tasks. And promoting one to Next Action shouldn’t mean retyping or cut and paste into an actual task. Why not just enter them as tasks to begin with?