We have just seen that checklists can be used when we have a group of things which need to be done to complete a task. There is a closely related concept in GTD called projects. A GTD project is much simpler than what we normally call projects: anything that needs more than one action to complete is a project. We cannot "do" a project. Instead, we plan a project, breaking it up to tasks which we can do.

In DGT GTD, the idea is implemented by a version of checklist where the entries are full tasks, rather than simple checklist items. Let's see projects in action. We start by creating a task, say to acquire a printer.

 

Of course we choose to create a Project this time.

All the statuses

We should also set a status. Because we cannot do projects, setting it as "Next action" is not appropriate once it is planned. It is a good time to understand all the available statuses:

Of these, only "None" and "Next Action" are special in DGT GTD: "None" is always the default, meaning the task status is unset. So it allows the task to be in the inbox. "Next Action" makes the task title green in color when listed. (There is also an option to turn the status of a new repeating task to None if it is created by completion of a task which status is Next action. But I strongly recommend against it use, as the task will not go back to the inbox and it will get ignored.) So we can actually assign any meaning to the remaining statuses. These are the meanings I'd assign to them:

• None: The task is not configured.
• Next Action: The task can be acted upon in the appropriate context and time. Or the project is waiting to be planned.
• Active: The project is planned and waiting to be completed.
• Planning: ??
• Delegated: The task is assigned to somebody else, but I still want to monitor its proper completion.
• Waiting: The sub-task, in a project, cannot be started now, because it is waiting for another sub-task to complete.
• Hold: ??
• Postponed: ??
• Someday: The task is not useful for now. It may be useful later, let's review it every some time, say, monthly. (I'd create a task for monthly review to make sure it happens.)
• Cancelled: I have decided that the task or project no longer worth doing. (I mark it as completed as well so that it will be automatically removed.)
• Reference: The task no longer needs any attention now, but I want to leave it there (rather than deleted automatically after some number of days). I'll leave it not completed. This allows me to search for it later.

Note that I've assigned no meaning to a few statuses, so they can be used for other meanings I see fit in the future.

So, how it matters? Essentially, just because I can do two things: (1) show only tasks having "Next action" status in the widget, and (2) during weekly review, select to list only tasks of particular statuses.

Because we are just about to plan the project, let's skip ahead and set it Active now. Once we save the project, we're again presented with a screen similar to the quick-add screen.

Sub-tasks

As said before, projects are holders of other tasks. Let's add them: acquiring a printer requires us to first measure the space available, then research about which brands and models have the best user comments, next shop for one of the chosen printers, and finally install it. We add all of these tasks.

At this point, everything depends on the printer space information. So we set "Measure printer space" to be next action, and set up its context (likely to be @home or @office), status (Next action, usually, unless we delegate it to somebody else) and due date. For the other tasks, we can think about how to do them as well, or we can just leave them unset (with a project set, they will not clutter our inbox).

Every time we complete a task belonging to a project, we should consider which other sub-tasks can become a Next action. I find it somewhat error-prone to require one to notice that a task is a project sub-task when completing it. This is required because then we need to go back to the project to check whether other sub-tasks become Next actions. It would be much better if DGT GTD actively asks whether we want to review the project once a project sub-task is completed.

Once these sub-tasks are saved, the widget looks like this:

We sure do not want to litter our home phone screen with subtasks which cannot be done yet (and the project which we have already planned)! We can set up the widget to filter out tasks which are not having Next action status. The result would look like this:

Alternatively, wait until we discuss Location sensitivity in the next section, which sets it automatically.

Checklist or Project?

So when to use checklists, and when to use projects? Projects contain full tasks, which allows sub-tasks to have different contexts. Each of them appears as a different task in the widget, so it reminds us to do each of the sub-tasks individually. Checklist items have no such flexibility. They don't even have appearance on the widget! So checklists are more suitable for tasks that we tend to do all at the same time and you do not want to clutter your task list with many tasks. Projects, in contrast, is more suitable for longer tasks.

We haven't mentioned about repeating projects. They are possible, too. The trick is to make use of a Repeat option called "with parent" for the sub-tasks, once the project is set as repeating. So once the project is completed, a new project is created with the same list of subtasks. After that, we will probably need to review the status of its subtasks. Again I hope DGT GTD provides some automation, e.g., have a field to tell what is the initial status of each of the subtasks. (Unsetting Next action whenever a task repeats is not usable, sorry.)