In creating GTDNext, we are always trying to make the behavior of the system as logical as possible. Often, the reality appears to be far beyond what we’ve planned in our logic. The Parallel/Sequential paradigm is one of these cases.
Historically, applications and tools refer to the parallel term only in the context of Actions. The main reason for this (I’m guessing) is probably the internal architecture of those tools.
Almost all the tools on the market handle the projects and actions separately. Very few offer a limited sub-projects functionality.
In these circumstances, the parallel projects concept that other tools use does not make much sense, and the parallel is used only for actions.
So, setting parallel for a project in, for example, NirvanaHQ actually means that the actions in this project are meant to be done in parallel (so confusing, isn’t it?).
Our own way.
In creating GTDNext, we’ve decided to model the behavior of the actions from scratch, not looking back to the previous implementations. Having such a flexible structure of projects and actions as in GTDNext allows us to bring project planning to the next level. We just needed to introduce the reasonable defaults. One of the key moments was keeping any sub-project behavior as an independent project.
A key GTD principle is that any project can have only one Next Action, which is very reasonable. And that was the first default: Any single project (or sub-project) may have only one Next Action. In sequential/parallel terms, it means: all the actions within one project are sequential (should be done one after another).
Keeping sub-projects as separate units makes every sub-project also have its own next action. And that is the second default: any project/sub-project is parallel by default (please, don’t get confused by NirvanaHQ approach).
That means that when you have a number of sub-projects within a project, you’ll have an entry (the Next Action) from every sub-project in your Next List.
However, there are situations in which you need to do the actions in a project and all sub-projects strictly in their order. For that case, we’ve introduced the Sequential option on the project (and action, as a special case) level.
Another helper method is the Force Next option. It allows users to mark additional action in a single project/sub-project as the Next Action. While it contradicts with the first item in this list and the main concept of GTD, it allows users to make more than one Next Action in a single project as a form of an exception to the general rule.
In combination, these options allow users to manage Next Actions behavior in a flexible way, letting you see in the Next List only those actions you want to see.
So, in summary, we have the following concepts in GTDNext:
- By default, there is only one Next Action in a project.
- Users can “force” an action to be on the Next List by using the Force Next option.
- Parallel/Sequential only refers to projects in GTDNext, not actions within a project.
- Sub-projects in GTDNext can be set to parallel or sequential. The default is parallel.
As with all approaches, this one has a few downsides.
In the next post on this subject, I will describe these issues and possible ways we are planning to solve them.