At least a few GTD best practices don’t comport with the usual advice given in time management literature.
- GTD doesn’t assign priority codes to action list items.
- To do lists are split into several smaller lists, typically organized by physical context.
- Potential, uncommitted projects are tracked on their own list (Someday/Maybe) rather than dispensed with altogether.
- Instead of generating tasks and projects on a top-of-mind basis, everything that consumes attention is collected and processed — whether it’s an internal thought or an external document.
But one of the most frequently debated issues in GTD is tying actions to projects. When people read Getting Things Done, then try to implement the system on their own, one of the first things they notice is that their next actions and projects are on separate, flat lists. Wouldn’t it be more logical to have actions and projects on a nested list, with projects as the top-level hierarchy, and their actions subset directly beneath them?
When I first set up my own system, I had never heard David Allen weigh in either way on the subject (as he did later in this 43 Folders podcast). I just assumed I missed it in reading the book, or that the need to link actions and projects was implicit. So I tried a couple of applications for my Treo that facilitated nested lists, like LifeBalance and Bonsai. After one weekly review, creating hierarchical lists, I realized that it was way too much work for too little benefit. Here were the problems I encountered.
I started using my project list as my action list. Referring to a list of projects does have the benefit of conveying more perspective, but at the cost of spending more time in the system. When you’re at a computer, it’s much faster to scan a list of all 17 next actions on your @Computer list than to scan through a list of 53 projects, then figure out which actions involve a computer.
Seeing inactionable tasks among actionable ones required more discrimination. When you have a flat list of only the very next actions you can take, and not subsequent ones, there’s no need to rethink what you have to do next to drive a project forward. This is a subtle, but important point: putting action triggers and reference items in the same collection bucket (e.g. an action list) blurs their distinction, and creates progressive disengagement. You begin to unconsciously resist looking at your lists, because they’re no longer honed to function as focus tools.
I spent more time organizing simple projects. In GTD, the word “project” is a technical term for any outcome that requires more than a single action step, which is to say that the action is not synonymous with the outcome. Outside of GTD parlance, most people use the word “project” for endeavors of some complexity. By organizing simple projects into nested lists, I was overengineering things that didn’t require a critical path outlook.
I noticed that virtually all linkages were self-evident. Don’t take my word for it. If you have a flat next action list, take a look at it and see if you can’t remember the project for each action in one or two seconds. What I realized that that I was anticipating a problem that never happened in practice. When I look at “Draft questions for Julie” on my @Writing list, I know immediately that the action is for my upcoming interview with Julie Morgenstern. I don’t have to create a pointer.
So does the impulse to link actions and projects come up so frequently? I have a couple of theories.
People assume GTD is project management. Project management is concerned with administration, which usually involves more overhead than required for personal task management. Project management is primarily concerned with deliverables across timelines, not the specific actions needed to manifest those deliverables. A Gantt chart will have items like “Complete requirements document” on a software project, but not an discrete action like “Call Andy: schedule requirements meeting” needed to complete the document.
The thinking required for some projects is unfinished. Most simple projects only need to have their next actions defined to offload them from the mind. While defining the next action properly can unstick any project, some projects require more planning to provide relief. The level of planning needs to scale appropriately to the level of the project’s complexity. Broadly speaking, there are three types of project intensity.
- Multiaction tasks. These are the types of projects that only need the outcome and next action defined. The vast majority of projects, like product purchases or meeting preparations, fall under this category.
- Low-coordination projects. These can be very important projects, but the level of detail to track isn’t exceptional. Applying for a loan, setting up a personal blog or starting an exercises program would be examples. Creating a mind map or an outline to file for reference is usually sufficient.
- High-coordination projects. These are the ones requiring PM (project management) tools and methods. These require tracking many resources, personnel and due dates, using solutions like MS Project. Starting a business or constructing a bridge would be examples. When you need to apply this level of planning, you’ll know.
In a personal task management system, like GTD, it’s important to distinguish between planning projects and tracking them. If projects and actions are reviewed regularly enough, no pointer should be required to reference an action’s associated project. If a next action evokes the question, “What project does this belong to?”, then the project probably requires more planning than defining the next action.
While a next action can usually be defined in seconds, some projects might take much longer to map out in order to offload them from the mind. Using a list, tree or map, work out all the actions necessary to complete the project. Extract the actions that can be done now and put them onto your action lists, and file the project plan away as support material. Next actions are bookmarks for where you are on each project now, not the actions that have to be done afterward.









Comments
Suzette. South Africa
// Jul 19, 2008 at 8:53 am
Thank you this was my final nagging little issue which held me back from really working well with GTD. Thank you a thousand times it’s a brilliant article.
Doug Toft
// Jul 19, 2008 at 4:04 pm
Another fine post, Andre. I’ve tried several times to nest actions under projects. It failed each time, and I never understood why until now,
Andre
// Jul 19, 2008 at 8:49 pm
Suzette and Doug: Thanks. I’ve seen this debated many times on forums, and I’ve noticed that the GTD users with the most experience usually concur on maintaining flat lists. I had to learn my lesson the hard way.
Charlie Gilkey | Productive Flourishing
// Jul 20, 2008 at 5:41 pm
This is a great post, Andre. I think it’s safe to say that I’ve abandoned the GTD system, although my own personal system clearly has the insights from the system.
One of the things that has bugged me is that I do think there’s room for project management paradigms for people that don’t need MS Project. This is especially true when you’re managing compartmentalized aspects of yourself and need to firewall time to work on projects associated with those aspects.
For instance, I’ve learned to firewall Tuesday mornings to work on Guard projects. Having an easy way to block-out Tuesday morning from other actions, when planning, is helpful. I’m still working on a way to do it that doesn’t create so much overhead that I then become even less productive because I’m managing yet another system.
GTD is a great system for task and project execution - however, I think as a pure system, it has serious shortfalls when it comes to life management, especially when it hits the planning dimension. I probably need to spend more time thinking and discussing this at PF rather than having scattershot, longish comments at T4T.
Andre
// Jul 21, 2008 at 1:53 am
Hi Charlie,
I’m not quite understanding the link between firewalled time and “project management paradigms.” Blocked sessions are useful for many types of high-focus tasks, with or without PM. I’ll generally block out any activity that takes an hour or more on my calendar.
I think that a lot of former GTD users find get stuck in the first half of the book, which isn’t surprising, considering the major investment of time and energy (and sometimes money) it takes to set up the system compared to time management systems that require nothing more than a day planner. The Natural Planning Model, Areas of Focus and Horizons of Focus are rarely discussed — certainly nowhere near as much as Moleskine hacks or Outlook tips. A complete GTD model addresses horizontal and vertical focus appropriately.
How to Write Effective ToDo Lists | Productive Flourishing // Jul 21, 2008 at 12:01 pm
[...] Project X” and “Call Susan at 422-111 about Project X by Wednesday.” The latter links the action with the project it belongs to quite nicely and allows you to complete the action as a stand-alone item, whether you write it down, put it into [...]
João Brito
// Jul 22, 2008 at 12:02 am
Hi, Andre! Great post, again. I can’t remember how many hours days I spent looking for a todos manager where I could maintain projects with next actions in them, I’ve tried many (natara, agendus, time & chaos, to name a few) and that never worked well. I used to blame the tool, of course, and kept looking for the right one. Well, many allowed it, that is, tagging a project item as a next action, but then projects and Next Actions lists became so complex, I always, as you say, “disanged”. But it’s very hard to give up projects, it seems the right way to do things: if I have projects, why don’t put NAs in them? Well, it doesn’t work, believe me, it just becomes a mess. I’ll try flat lists, thanks for posting. Finally I think I agree Next Actions don’t belong to projects, as strange as it may sound.
Ella
// Jul 22, 2008 at 5:18 am
Hello andre, Your post is so great. Thanks for sharing it. The GTD is nagging controversy from me. But I like your post it give me an idea about my next plan. Try to visit the impactful actions maybe it can help you to know more about goal setting.http://impactfulactions.com/
Charlie Gilkey
// Jul 22, 2008 at 1:43 pm
Yeah, I didn’t make what I was talking about very clear. Maybe this’ll help:
I have several different aspects (areas of focus) of my life that I like to keep separated. In fact, it’s not so much that I like to, but I have to. I’ll take the three major ones and illustrate.
I’m an officer in the Guard, an academic, and a blogger. The way in which I communicate with each of the different people that make up those different areas are different. I have to make a mental switch to keep things right.
The easiest way for me to do this is to schedule blocks of time in which I only handle stuff from that area. You can do all of this without PM thinking.
What I’d like a personal PM tool for, though, is for getting real with my planning and seeing that certain days are already “spoken for” because I’ve firewalled them for other activities.
I can do this by simply plugging my recurring activities in a calendar and then doing the juggling myself - but it is useful to know that a research project I’m working on will take me 8 weeks to complete even though it only requires 40 hours of work because I see that, all told, I only have 5 research hours free a week.
Part of the other draw to PM tools is because, when I used them, I saw how much of my time went to overhead and logistics versus work time. Somehow the global view made that stick more than other views I have.
A somewhat simple to use personal PM that integrates the planning piece with the execution piece would be ideal. I’ve yet to figure out how to make it, but I have been working on it, nonetheless. Until then, I’ll stick with a recurring calendar and task list.
Even though I’ve read it several times, I’ll go back and read the parts of GTD that you mention. It’ll prove fruitful (again) and it’ll likely help me sort out some things I’ve been thinking about for a while. It’s my favorite part of the book, anyway.
Andre
// Jul 23, 2008 at 10:13 pm
@Joao: The trick is to put blinders on your next actions to avoid thinking about the project it belongs to, and therefore everything else related to it. When I’m making a phone call, I only want to think about the phone call, and not everything I have to do afterwards. At any one moment in time, we can only focus our attention on a single action. Anything else is a waste of emotional energy. That’s why I recommend keeps project headings in a different “drawer” than next actions.
@Charlie: In the case of a research project, unless I had a lot of experience with the material, I would avoid mapping out a complete time allotment on the front end. Instead, I prefer to block a single session for gauge the pace of apprehension, then schedule each subsequent session individually — at least until I have a reliable idea of how much ground I can cover per session. Reading 100 pages of Being and Time will take much longer than reading 100 pages of Time and the Art of Living, so the density of the material needs to be factored in.
Once I map out a project plan, I extract the next actions and file the plan away for retrieval on an as-needed basis. It might take me eight weeks to complete a research project, but I’m generally not concerned about anything that lies beyond the week ahead (i.e., past the next weekly review) unless I’m behind schedule, or need to ensure that something else I’m scheduling that far in advance doesn’t conflict. As long as I’ve done everything I’ve scheduled between weekly reviews, and assuming there hasn’t been a change of deadline, I don’t need to review the plan to reaffirm than I’m on course. But if I find myself lost for any reason, that’s when I pull out the project plan again. Sometimes I do find that I’ve left something out, but as long as I know I’ll see the plan once a week, I usually don’t have to think about in in between.
Blair Rorani
// Aug 4, 2008 at 11:58 pm
I am in beta-version with actions and what David calls milestones in his Make it Up, Make it Happen article.
When you plan a project in some detail (because you need to versus submit tax return that takes say three actions) he talks about purpose, vision, brainstorm, organise and next actions.
When I get to the organise step, I create what agile software developers will call a feature or a story or a backlog item. This is a deliverable. Because nearly every action will have a deliverable (something is different in the world after you take action) then this works well I find. These stories/milestones mean you can keep visibility across an entire project (if it’s mapped out) but the next actions are kept on your flat lists.
For example:
Project (vision step) = Design new training programme
1 Milestone (organising step) = Complete training needs analysis
All that can go with your project support materials.
Then, on your @computer list your next action might be “E-mail SMEs to arrange time to scope learning objectives”. This is one of several actions that will produce the deliverable/milestone of “Complete training needs analysis”
If I am reporting on this project, I can tell the stakeholders the status of the milestone, rather than the next actions. If Matt is responsible for the milestone I mentioned above I know to follow up with him if it gets behind.
If you really need to estimate and track time to complete or effort, then the milestones can have this data added to them as well.
As I’m in beta, I’m using plain 3×5 cards for milestones, and the smallest rectangular post its for next actions on context lists (A4 paper).
Andre
// Aug 5, 2008 at 12:09 am
Hi Blair,
“Milestone” is a better way to describe an intermediate deliverable than what I typically refer to as a “subproject.” It’s easier for non-GTD users to understand.
3×5 cards are great for planning — for stepping out the milestones; and they give you a good workspace for breaking down milestones into next actions.
By the way, what exactly are you referring to when you mention being “in beta-version”? Is that another (cooler) term for white belt?
Productivity through Lucidity: Why Perspective Precedes Action // Sep 8, 2008 at 7:35 pm
[...] to nest action items underneath project headings to reaffirm their relationships. I came to the same conclusion very early on. I found that by using hierarchical lists, I wasn’t so much reviewing as [...]
Leave a Comment