With this post I aim to reach two categories of people. One is GTD app developers, who I wish to encourage to implement the types of features described here. The other is fellow users who might be able to point me in the direction of apps that already have all this.
The periodical review of your lists is a fundamental part of GTD. One of the main purposes of these reviews is to go through and verify that you have everything that needs to be done listed, that nothing is missing, that everything is properly categorized, and that old entries are removed or modified. Another important purpose if the review is to genuinely understand and adjust, and build an intuitive feel for, what the totality is all about, what is important, and how the various parts fit in with your overall goals.
Projects are important in GTD, because even the simplest little task with more than one action step in it is called a project. And projects can also be very large and contain lots of actions. Often some tasks need to be completed before others can be started. And in real life, projects are often not entirely independent of each other, but rather a bit inter-dependent both in terms of certain actions being fundamental for multiple projects and in terms of having certain overall goals or purposes.
Some simple but significant features to the fundamental project structure offerd in most apps would be immensely useful, making reviews much simpler and accurate, and making the work in between reviews, and ongoing task selection on a daily basis, so very much simpler.
Feature: Hierarchies (subprojects)
Being able to arrange projects and tasks hierarchically brings overview. The list of projects (usually on the left) can be kept as short and overviewable as you like it. Each project, at any of its levels, can be kept as short and overviewable as you want it. You can specify your projects down to the tiniest little action without thereby creating a big daunting mess. And you can consistently filter tasks by tags (i.e. contexts, labels etc).
There is nothing novel or strange about this, nor is it complicated for the user. This is how we all normally organize stuff in Windows etc. You make your hierarchies as deep or as flat as you want them - whatever serves your purposes and your personality and the particular project best.
Feature: Multiple parents
Much of what we need to do serves more purposes than just one. If we plan to buy a good scanner, this may be part of an overall refurbishing plan for the office, but the scanner may also be needed for a particular photo/advertising project we are about to start, and for a litigation project where we need to capture in electronic format some heavy legal documents that we expect to get in the mail next week.
By being able to list "Procure scanning equipment" (which itself is a task or subproject) in all those projects for which the scanner is essential, we make our review work so much simpler and less worrisome. We need not make notes about these interrelationships. We need not feel anxious that something is overlooked. We need not switch back and forth between different projects to make sure all is covered. We can see, wherever we need to see it, that buying the scanner is necessary for the project to succeed.
The very same multi-parent capability is a powerful solution to another extremely common situation. GTD (and most other methodologies) suggest that we batch things up and do more than one thing when in a given context. Sometimes these contexts need to be deliberately planned and set up; they do not just "happen". The multi-parent capability allows us to create little "batch" (or "agenda") type projects such as "Meeting with CFO" - about all kinds of things that belong to different projects, or "Trip to outlet center X" - to buy things for many different projects. And then we can also add little "context setup" actions to that little project, such as book a van, book a conference room etc.
Feature: Semi-dependent task flow within projects
Some apps have separate project types, parallel ("shotgun") and sequential ("bead of pearls"), but it is simpler and better to have just one universal project type and make it realistic enough to serve both purposes. What we need is to see all our true Next actions on the Next list (and true Waiting actions on the Waiting list), while keeping the rest (the not-yet-relevant actions) well hidden within their project until it is their turn. And we want the automatic progression sometimes offered as a strictly sequential project type.
The solution is simple: Make the "sequential" container a built-in part of an overall "parallel" project. Let the sequential container feed tasks one by one into the parallel main container when this gets empty. All actions in the parallel container would be visible on the Next and Waiting For lists, but all actions in the sequential (subsequent) container would be hidden. Allow the user to manually move actions between the parallel and the sequential container as required. Default placement for new tasks should be the parallel (active) section (to avoid being overlooked if you forget to place it in its correct position.)
This gives us all existing capabilities of both project types, and adds the flexibility to manually adjust what tasks are currently active (in parallel; often more than just one) and which ones are subsequent and in what sequential order. It is not only more powerful, it is also easier for new users to understand (no need to select a project type).
In addition, this very simple task flow mechanism is actually all we really ever need even for more complex pre-sequencing of the task flow, because subprojects can be made use of for creating sub-suites of tasks that fit into the simple overall structure of its parent project.
All this might sound a bit abstract to some, but things are easier to see and understand in real life than it is to understand a theoretical description of them. These features typically can be implemented with virtually no impact at all on the existing UI for the novice user, but increases the app's power tremendously for those users who have reached the limit of what they can use the app for. Basically, for the UI, the subtle difference with these enhancements is that you can drag and drop (move) things a bit more freely - but that almost invisible difference makes a world of difference in power and usefulness.
I think this has been addressed by DA in his last book where he said that the while it would be nice to cross reference every task to a project, it would probably be more trouble than it was worth. You would spend more time on updating your system than necessary, although I would imagine that depends on the individual. Some people might find it more rewarding to add the extra details.
My life is not complex enough. I don't need to connect a scanner purchase with multiple projects.
Originally Posted by AJS
... while it would be nice to cross reference every task to a project, it would probably be more trouble than it was worth.
I think there is a misunderstanding here. All three features are simple and virtually invisible - and would not require any action at all on the part of the user except for those projects where he/she needs these features for better overview and control, or to reduce the strain on his/her memory:
Hierarchies: By all means, keep projects as flat as you want - several pages of tasks, if you like, but if on occasion you would like to group related tasks under a single line (a subproject line listed within the project) you would have the means to do so without either cluttering your main project list or losing sight of it from within the project.
Multiple parents: By all means, rely on your memory whenever you can, but if on occasion you notice a tendency to forget or overlook the fact that some steps in a project are actually vital to another project as well, then you would have the means to make sure that you do not overlook this when looking from that other project's point of view. Also, it would relieve you of being forced to make silly-rigid classification decisions such as whether a particular photo shoot is best considered as belonging to the brochure project, the web shop project or the exhibition project; instead, you have the means to see it from as many of those projects as you want - if you think it is worth the trouble (say, shift-drag the subproject over to an additional project as well). And, important, too, in my opinion, although a slightly different use case, is where you have little "batch projects" (context based projects), such as a plan to hire a van and do certain heavy errands that belong to totally different projects all at once. This is a kind of situation I encounter all the time, often with meetings, conferences etc. (Using temporary special tags etc is usually not convenient enough.)
Semi-dependent task flow: By all means, keep your tasks all active at once if you like (parallel), or have them made active one action at a time (sequential-automatic; available in some apps), but if you ever have a project where there are more than just one action perfectly relevant to see right now on your Next and Waiting For lists, but far from all actions in the project, then you will appreciate being able to handle this more realistically and still have a degree of automation that guarantees that you never see less than one action.
I agree with the other replies in this thread, but thought I should say that Omnifocus can do most of what you want. However, it's the app that launched a thousand posts. There are more reviews, set-up guides, tweaks, et cetera about Omnifocus than you can imagine, which should tell you something. It's a decent program, but it is no more essential for gtd than a rhinestone-studded day planner. Be careful what you wish for- you might get it.