Next Actions for a Sequential Project

I have a question (possible issue) with the way GTDNext logic is set up to deal with Next Actions in Sequential Projects. Let’s say I have a Project (i.e Project A) which’s actions are needed to be completed in sequential order (i.e. Task 1, Task 2, Task 3, Task 4). If for Task 1 I’m either waiting on John to complete the task, or Task 1 is not scheduled to start for 3 days in the future, why does Task 2 appear on my Next Actions list?

If Project A is truly a project which requires the tasks to be completed sequentially, then I can not complete another task until Task 1 is completed. If anything, Task 1 should be on my Next Actions until it is completed, or none at all.

Can someone explain for me the logic here? Am I missing something? How could I complete Task 2 or Task 3 until Task 1 is completed if Task 2, 3, & 4 are dependent on Task 1 being completed? So therefore why Task 2 listed on the Next Actions list when the Forced Next box is not even checked?

No, I cannot explain the logic of how it works. I assume they have not had the time to think it through and implement it. They seem to have focused entirely on next actions in single-level active projects for the beta.

  • When we signed up, the other lists were not even implemented, remember?
  • And the green “parallel” indicator looks the same as the next action list indicator, and is even called “forced next”, never “forced waiting” etc
  • And there was no way to make subprojects sequential in the same way as actions (but since we signed up, they have also introduced a Sequential checkbox which is similar to Forced Next, but not quite)

I assume (and hope) they will tie up these loose ends.

In my opinion, just like yours, if a task is marked sequential (gray) it should never show up on its “main list” (next, waiting …). But if the sequential option is not marked the task should be considered parallel (marked green) and should show up on its “main list” (unless the project or subproject to which it belongs is gray.)

The force next box is no longer needed, but could still be useful for some edge cases if it were renamed to forced preview etc and worked consistently for all lists (not just next). It could serve as a tool for making tasks visible before they are possible, e.g. a huge task looming sequentially behind a small one, or for handpicking a now possible action from an inactive (subsequent) project. (It would need to have a very clear icon to show that it has bypassed the main parallel/sequential mechanism.)

I would like to add, and stress, that GTDNext have been very wise, compared to most other developers, in that they have applied the sequential/parallel mechanism at the marked item level (sibling level) rather than at the parent level (for all its children), which is the customary approach (Nirvana, MLO) and which is what makes it impossible in those apps to mix sequential and parallel items and which also forces the user to make a sometimes confusing initial choice about whether the project or subproject as a whole (its children) is either entirely parallel or entirely sequential. Very well done!

This was just answered in this post. Thanks!

@hntopper - This behavior was fixed in today’s build. Thanks for your patience!

Can someone please tell me what the Sequential box is for in the task detail? If every project is automatically treated as a sequential project, why do we need this check box? I can’t seem to understand it’s functionality?

Well, if you ask me (not @james or @sergio :wink: ) then the Sequential box is the one that should be kept. The Forced Next box should be thrown out the window. It has a confusing name and a disruptive function in many cases.

The Sequential box is all that is needed. If a task or subproject is not marked as sequential, then this should be taken to mean that the item is “normal”, in other words it is to be done in parallel to any other non-sequential items (siblings) under that same parent, before any of the sequential (dependent) items are started. (The normal/parallel items could be marked green, ad the dependent/sequential ones could be gray.)

So, in practice, for regular tasks within an active project the Sequential box therefore would work almost exactly like the forced next box does today (but inverted: “not marked” would mean “normal”, i.e. visible on the main lists next,waiting etc)

The important difference would be that this would work correctly not only within active single-level projects, but also when used within inactive (dependent) subprojects (marked Sequential) and multi-level projects. It would work consistently for all kinds of tasks (next, waiting etc) and subprojects at all levels with a simple and consistent UI. It would also allow pre-planning of the sequence of work in all kinds of projects (with any mix of parallel and sequential sub-entities in any number of levels).

That is not the case in GTDNext; it is not like Nirvana or MLO; it is potentially more powerful. Unlike those apps, GTDNext allows you to set this for each sibling individually, not for the parent as a one-or-all rule for all of its children. This is what makes it possible in GTDNext to mix any number of parallel items (active first) with a bunch of sequentially dependent items.

@hntopper Sorry, it seems I was half wrong. There is one more inconsistency here. When I just checked it seems that the Sequential setting now does affect the children, too, in some cases, not necessarily just the item itself in relation to its siblings, which is how it often works and which is how it should work consistently.

Overall, it is dissatisfying that you cannot see in the outline which projects (subprojects etc) are on hold (sequential)