Projects are not containers

[Jared Caron]

I was asked to elaborate on this response I made to another contributor regarding projects and next actions:

"In GTD, projects are not 'containers' that hold tasks. They are placeholders to remind you of the outcome you are committed to at least once a week. This is I think one of the hardest things to learn about GTD."

Hopefully, I can help flesh this out a bit.

First I'll unpack the title statement: projects are not containers that hold tasks. This is a counterintuitive concept for most people learning GTD.

Many of us want to organize our projects as:
Project 1
Action 1
Action 2
Action 3
Project 2
Action 1
Action 2
Action 3

Let me clarify that the above structure is not "wrong", is just not the way you will typically engage with your actions, which is why GTD recommends a slightly different approach. After all, GTD is not a set of "rules" but rather a collection of best practices and principles.

That type of planning and organizing is useful and necessary for many projects. However, the contents of that outline and plan are usually kept in project support and do not constitute next-actions. A next-action is distinct and separate from this support material, and the best practice is to organize these onto context lists.

So as a simple example if you have 2 projects that each have next-actions to buy items at the hardware store, you don’t want to have to pull out both project "plans" to figure that out while you're at the store. You'll see "buy lightbulbs" next to "buy concrete" on that list, and remember both while you're there. You want the same kind of efficiency with all your next action lists.

You want your next action lists to read more like a restaurant menu than like an outline.

If you're at a restaurant, you look at the menu and it presents you with:

- Here are all your options for appetizers
- Here are all the salads you could choose from
- here's all the entrees
- and if you still have room... what about desserts?

Similarly, your next actions are a menu - the options of work you could choose to do at any moment. Therefore context lists present as:

- here are all the appointments you have today (calendar), if you've got some discretionary time...
- here's all the calls you could make
- emails you could send
- articles you could read
- etc.

In this way, at the speed of life, you can engage without thinking too much about the overall plan for each project - except for when you choose to do that kind of thinking. This could happen during the weekly review, during intentional planning sessions, or ad hoc through random ideas or creative thinking (as long as you capture it!). This is a dynamic process as you capture and organize next actions, engage, review plans, rinse - repeat until the project is finished.

Hopefully, that was more helpful than confusing.

 

[lastgasp]

Many of us want to organize our projects as:
Project 1
Action 1
Action 2
Action 3
Project 2
Action 1
Action 2
Action 3

...That type of planning and organizing is useful and necessary for many projects. However, the contents of that outline and plan are usually kept in project support

Thank you for elaborating on your earlier post, Jared. I'd be interested to know how you and others handle "project support" notes. Do you keep them handy in a next-action centric app (e.g., Things, Nirvana)? Do you keep them in a separate notes app (e.g., Notion, Evernote) - and if so, does that separation create any friction? Does anyone also keep a manilla folder for each project to handle paper notes and references? I have found it challenging to integrate all these moving parts smoothly and consistently.

 

[Oogiem]

First I'll unpack the title statement: projects are not containers that hold tasks. This is a counterintuitive concept for most people learning GTD.

I disagree with this. For me the only reason for actions is to further the goal of a completed project. The project contins those tasks needed to complete it to my definition of done. It IS a container for those actions BUT that does NOT mean that I work the actions through the lens of the project.

That is why the 2 separate views of your plate of stuff. One is by Project. I actually live in a world where 90+ % of my projects can be well planned out and nearly all are sequential as in I can't do action C until I've done actiosn A and B, in order and very few change much during the execution of a properly planned project using the NPM as a guideline.

I WORK my actions through the lens of the context in which I am most effective at performing that action. So I have Contexts for major software packages I use because I work best by doing all tasks, nomatter the project, within a single app because app switching is for me difficult.

I need to have actions linked to projects for my own sanity. I do have single actions but I keep them in one place. I use tools that allow me to tie the actions to their projects without any friction and that is what works for me. The idea of a separate project list is just a matter of collapsing the display of my projects and actions to show only the top level. My tool will show projects in actions in a structure similar to an outline and that is ideal for me.

I'd be interested to know how you and others handle "project support" notes. Do you keep them handy in a next-action centric app (e.g., Things, Nirvana)? Do you keep them in a separate notes app (e.g., Notion, Evernote) - and if so, does that separation create any friction? Does anyone also keep a manilla folder for each project to handle paper notes and references?

Project support is something very different. I tend to keep that in either a totally separate application if it is digital or in a paper file folder or both depending on the project needs. My current active projects have their respective project support in tools I can access when I need them. If I need something from those reference materials to complete an action I put a reference in the action to tell me wher that supporting material is.

For example:
I have a project
Compare Sheep Linear Measurements from Grass Master sheep to our numbers
My next action is Write query to pull linear measurements from the LambTracker database for our sheep by age and class and the context is LambTracker
Other actions within the project include
compare age and class measurement numbers of our flock to those of the Grass Master sheep with a context of inside by myself and there is a note attached to that action saying See Article from SGF in paper project suport
run a statistical analysis on whether we have enough data to say with what confidence level that our sheep also meet the Grassmaster breed definition with a context of Misc Mac

and so on.

The project is the container for the actions but when I work on it it is because I am in the context where the actions are.

So right now my LambTracker context has the following actions
Update owner note file with all info from UK flock books on US and Canadian sheep.
Verify differences in ownership and location changes for the sheep from the east coast shipment that included Mountain View Curly. I think I have errors in some of the dates.
Add USA export tattoo info as an id_info record for all sheep we have exported to Canada
Enter in all historical weaning dates
Investigate how to run the SQLite VACUUM command on the database

and about 20 other items.

When I work in LambTracker I can move a bunch of projects forward.



But in the note for the project is the following See SGF article on GrassMaster minimum and maximum measurements

 

[Jared Caron]

Thank you for elaborating on your earlier post, Jared. I'd be interested to know how you and others handle "project support" notes. Do you keep them handy in a next-action centric app (e.g., Things, Nirvana)? Do you keep them in a separate notes app (e.g., Notion, Evernote) - and if so, does that separation create any friction? Does anyone also keep a manilla folder for each project to handle paper notes and references? I have found it challenging to integrate all these moving parts smoothly and consistently.

Not a problem.

Your question about project support is a loaded one, as you will surely find reading this thread. THere is no one right way to do project support; the key best practice is to keep this material cleanly separated from next-action reminders so it does not create "noise" when deciding what to do next.

I'll give you my personal spin:

Short answer: Depends on the project.

Long answer:
The primary forms of project support I tend to have generally fall into a few categories:

1. Notes, ideas/brainstorming, meeting notes, reference info - I keep these in OneNote; after much experimenting, I have found this type of note-focused app to be best suited for the wide range of unstructured material that can accumulate for most projects. Evernote and Notion can accomplish similar things.

caveat - I used to rely more on manilla file folders and paper. I love to take notes and brainstorm on paper, but I've learned over the past year that scanning them into OneNote makes for much easier indexing and retrieval later on. Sometimes, if they're short/simple I'll type them, but most often I just snap a picture using MS Lens. Then I have my rich, contextual handwritten notes available electronically and almost anywehre. I now keep fewer and fewer manilla folders.​

2. Documents/spreadsheets/presentations- these typically live in a windows document folder.

3. Emails - outlook folder. I try to keep my active projects nested under my Inbox in outlook, whereas archive/reference material lands in a .pst file. Just my way of demarcating.

4. Simple, sequential planning of future actions - if it's nothing more than a simple list of steps to take, I'll sometimes keep this in my list manager. I was on todoist and just migrated back to Nirvana (i really can't decide which I like better... chronic GTD problem) and both can do this pretty well.

Caveat - at work, I cannot do this, since I'm using outlook as my list manager and we do not have MS todo, so there is no good way to store future actions. Instead, I put them in OneNote.​

There are some projects where I have all of these, some that have none, and every iteration in between.

I think the important thing is to have just a few places where you keep project support and to be consistent with nomenclature with folders and such. I've found it helpful when changing my system to write out where I am going to keep various forms of project support as a way of externalizing/declaring my intention, and clarifying for myself- "this is where that goes".

Just ideas. Hope they help.

 

[Jared Caron]

I WORK my actions through the lens of the context in which I am most effective at performing that action. So I have Contexts for major software packages I use because I work best by doing all tasks, nomatter the project, within a single app because app switching is for me difficult.

Thanks for providing a different perspective about the container analogy.

I will cede that my title/catchphrase is but a heuristic for what you are explaining here: that in terms of how we work and engage with our system, it is less helpful to think of projects as containers that hold your tasks. I think the reality is that it is much more complicated than that, and much depends on the perspective/horizon from which you are operating.

DA explains this well in the 2nd book Making it All Work. I think that material is a more advanced spin on GTD, the deeper layers if you will, and packed with much more nuance.

 

[Oogiem]

in terms of how we work and engage with our system, it is less helpful to think of projects as containers that hold your tasks.

But for me that is actually a tiny part of making my system work. The real wor is in the planning and in some cases the scheduling of projects. SO a container is the easies and fastest way to deal with them. I would also argue that a context is a container as well. It's a container that holds like tasks that can be done together.

 

[Gardener]

in terms of how we work and engage with our system, it is less helpful to think of projects as containers that hold your tasks.

I'm not clear on what you mean. I feel that you're seeing "container" as prescribing a particular behavior, but that that behavior is not obvious to me.

In the restaurant menu example, I'd say that the "appetizers" section is indeed a container for holding descriptions of appetizer options. I can do whatever I please with the contents of that container--I can choose an appetizer to order, I can use it as a list of ideas for what I'm going to cook tomorrow, etc. But I still see it as a container.

So...I remain confused.

 

[Quicksilver10]

I think there may be some confusion in this conversation between 'projects' and 'project lists'. I believe that the GTD project list is, slightly modifying what Jared said, a list to remind you of the outcomes (those that will take more than one action and (?) no more than a year to complete) that you are committed to. The GTD method of dealing with lists does not require that next actions (as listed in Next Action lists) be linked to projects, although obviously they often derive from projects. They can and usually are though split out by context. Nor does it require that a Project list be any more than just that - a list of your projects. Any detail on a project is kept in Project Support Material, but this is not part of the GTD lists. A Weekly Review should look at the lists but also, as appropriate, Project Support Material (in order to ensure where needed that that a fresh Next Action is identified). The GTD Setup Guides for popular apps make this approach very clear and sometimes (e.g Things 3 app) subvert dare I say the intentions of the developer, in order to generate the classic GTD lists in an app that is designed to show actions within their "project containers". So Next Actions are listed by context, definitely not listed under their projects.

Another subtlety, which it took me a long time to see, is that a Next Action can be like a bookmark. Say you spend some considerable time working on a project, and in doing so knock off several actions. Of course, only one of these actions was a Next Action - so you were therefore working from Project Support material, not your lists, as the lists would only show the Project name on the project list and the Next Action on the appropriate context list. Anyway, your session has ended, but you need to make a reminder to yourself of where you have got to for next time you pick up the project, just as you would place a bookmark in a book you had been reading. So you identify the very Next Action that you will need to take, and put that on the appropriate context list. You will then review that context list as necessary, along with the other GTD lists, but you won't need to look at the "project container", with its Project Support Material (including list of all future actions), at the very least until you do that Next Action.

Sorry, I have rambled on a bit . Not sure it adds much to the debate, but I felt the need to contribute.

 

[mcogilvie]

I think there may be some confusion in this conversation between 'projects' and 'project lists'. I believe that the GTD project list is, slightly modifying what Jared said, a list to remind you of the outcomes (those that will take more than one action and (?) no more than a year to complete) that you are committed to. The GTD method of dealing with lists does not require that next actions (as listed in Next Action lists) be linked to projects, although obviously they often derive from projects. They can and usually are though split out by context. Nor does it require that a Project list be any more than just that - a list of your projects. Any detail on a project is kept in Project Support Material, but this is not part of the GTD lists. A Weekly Review should look at the lists but also, as appropriate, Project Support Material (in order to ensure where needed that that a fresh Next Action is identified). The GTD Setup Guides for popular apps make this approach very clear and sometimes (e.g Things 3 app) subvert dare I say the intentions of the developer, in order to generate the classic GTD lists in an app that is designed to show actions within their "project containers". So Next Actions are listed by context, definitely not listed under their projects.

Another subtlety, which it took me a long time to see, is that a Next Action can be like a bookmark. Say you spend some considerable time working on a project, and in doing so knock off several actions. Of course, only one of these actions was a Next Action - so you were therefore working from Project Support material, not your lists, as the lists would only show the Project name on the project list and the Next Action on the appropriate context list. Anyway, your session has ended, but you need to make a reminder to yourself of where you have got to for next time you pick up the project, just as you would place a bookmark in a book you had been reading. So you identify the very Next Action that you will need to take, and put that on the appropriate context list. You will then review that context list as necessary, along with the other GTD lists, but you won't need to look at the "project container", with its Project Support Material (including list of all future actions), at the very least until you do that Next Action.

Sorry, I have rambled on a bit . Not sure it adds much to the debate, but I felt the need to contribute.

I think this strict separation of project, next action and project support, although supported by some originalist arguments, will not be treated kindly by history or the court of public opinion. The simple fact is that almost all of the most popular apps for organizing actions are not designed to work that way, and don’t work well that way.

 

[Gardener]

I think there may be some confusion in this conversation between 'projects' and 'project lists'.

Ah. So maybe, "Projects are not containers" means, "The best presentation mode for your actions is one where those actions are NOT grouped by project"?

Or...

OK, not at all sure.

 

[Jared Caron]

The GTD method of dealing with lists does not require that next actions (as listed in Next Action lists) be linked to projects, although obviously they often derive from projects. They can and usually are though split out by context. Nor does it require that a Project list be any more than just that - a list of your projects. Any detail on a project is kept in Project Support Material, but this is not part of the GTD lists. A Weekly Review should look at the lists but also, as appropriate, Project Support Material (in order to ensure where needed that that a fresh Next Action is identified)... Next Actions are listed by context, definitely not listed under their projects.

This is a better description of what I was getting at.

The challenge is that every horizon above next actions is a level of abstraction, so it can be both ways. Depending on the perspective you are currently viewing it from, the project can both be the container that holds its related actions or not be.

On the ground (next actions) - contexts are the container, because from this perspective you cant get inside the project, because the "project" is removed from the concrete actionable world by a level of abstraction.

Elevating up to the project level (formerly termed 10,000 feet), you can see the projects as containers with all their related actions "inside" because you are operating at that level of abstraction. This elevated "project" perspective is useful for planning, organizing, and fleshing out a project; its just not usually accessible at the speed of life.

I think when new to GTD this separation by levels of abstraction/perspective (the horizons of focus model) can be a bit difficult to get used to.

 

[Gardener]

On the ground (next actions) - contexts are the container, because from this perspective you cant get inside the project, because the "project" is removed from the concrete actionable world by a level of abstraction.

I don't think that I agree. Going to your first post:

- here are all the appointments you have today (calendar), if you've got some discretionary time...
- here's all the calls you could make
- emails you could send
- articles you could read
- etc.

Sure, you COULD work this way. Or you could decide that you want to work on one project, and make the calls, send the emails, read the articles, etc., for that project. No, you can't necessarily work every possible context, but you can quite often immerse yourself in a project and exclusively work actions for that project.

And that immersion can be a valuable thing. Switching from project to project is not a zero-cost strategy. That call, that email, and that article may all be about closely related ideas for solving the problems of that project. When you switch from a call about Project A, and another call about Project B, and another call about Project C, you're unloading and reloading all the details of those three projects. Whether you view this through Gerald Weinberg's twenty percent rule, or David Anderson's discussion of the cost of too much Work In Progress, or any number of other views, it looks like that cost may be very large.

Yes, some people have no choice but to work many projects in a single week or day or hour. But the fact that it's unavoidable doesn't mean that it's a good thing.

So I would say that, yes, whenever possible, it's a good thing to get inside the project, all the way down to the "on the ground" level.

 

[mcogilvie]

I am reminded of the experienced politician of yesteryear who, when asked about alcohol, replied, “Some of my friends say it is the devil’s work, the destroyer of homes and marriages, the ruiner of men. And some of my friends say it was given to us to celebrate happy occasions, to ease our sorrow, and to warm us on a cold night. And I always agree with my friends.”

 

[Longstreet]

I don't think that I agree. Going to your first post:

Sure, you COULD work this way. Or you could decide that you want to work on one project, and make the calls, send the emails, read the articles, etc., for that project. No, you can't necessarily work every possible context, but you can quite often immerse yourself in a project and exclusively work actions for that project.

And that immersion can be a valuable thing. Switching from project to project is not a zero-cost strategy. That call, that email, and that article may all be about closely related ideas for solving the problems of that project. When you switch from a call about Project A, and another call about Project B, and another call about Project C, you're unloading and reloading all the details of those three projects. Whether you view this through Gerald Weinberg's twenty percent rule, or David Anderson's discussion of the cost of too much Work In Progress, or any number of other views, it looks like that cost may be very large.

Yes, some people have no choice but to work many projects in a single week or day or hour. But the fact that it's unavoidable doesn't mean that it's a good thing.

So I would say that, yes, whenever possible, it's a good thing to get inside the project, all the way down to the "on the ground" level.

I am in agreement with @Gardener's post. In my work, I find myself focusing on a particular project for an extended period of time. Jumping from project to project just because you are in the computer or calls context to me makes no sense whatsoever and creates a huge amount of attention residue and loss of ability to focus on the work at hand. This is why I rarely work out of contexts. It has always been taught the we decide what to do based on what we can do with where we are and the tools at hand. A limiting factor. But here is how I feel about this. If I have a project or an area of focus I wish to concentrate on, I will PUT MYSELF in whatever "context" is necessary to do the work. I work some from home on a laptop. I can access all of my files that I keep on an secure university share drive. I can call and have a zoom meeting with anyone who happens to be physically in our research institute. I cannot think of a time that I could not do something because I was not "in that context". Now, of course if there is something at home that needs to be done and I am in my office at the institute, then there is that. But to me that is just common sense and I don't need to have a context for that. I do have areas of focus that reflect the kind of work I do at home, so there is that separation. So in our rapidly expanding and changing digital world, standard contexts are meaningless to me. Energy is a much better way (and the amount of time estimated for completion of an action) for separation and that is quite useful.

Just my thoughts from a senior professor in academia...

 

[Longstreet]

I am in agreement with @Gardener's post. In my work, I find myself focusing on a particular project for an extended period of time. Jumping from project to project just because you are in the computer or calls context to me makes no sense whatsoever and creates a huge amount of attention residue and loss of ability to focus on the work at hand. This is why I rarely work out of contexts. It has always been taught the we decide what to do based on what we can do with where we are and the tools at hand. A limiting factor. But here is how I feel about this. If I have a project or an area of focus I wish to concentrate on, I will PUT MYSELF in whatever "context" is necessary to do the work. I work some from home on a laptop. I can access all of my files that I keep on an secure university share drive. I can call and have a zoom meeting with anyone who happens to be physically in our research institute. I cannot think of a time that I could not do something because I was not "in that context". Now, of course if there is something at home that needs to be done and I am in my office at the institute, then there is that. But to me that is just common sense and I don't need to have a context for that. I do have areas of focus that reflect the kind of work I do at home, so there is that separation. So in our rapidly expanding and changing digital world, standard contexts are meaningless to me. Energy is a much better way (and the amount of time estimated for completion of an action) for separation and that is quite useful.

Just my thoughts from a senior professor in academia...

Just to add...I took the Kairos cognition assessment and I am predominantly an associate thinker versus sequential. This really helps explain my behavior to want to focus so much on one major project almost to its completion versus a more sequential thinker moving many projects forward simultaneously.

 

[RS356]

Just to add...I took the Kairos cognition assessment and I am predominantly an associate thinker versus sequential. This really helps explain my behavior to want to focus so much on one major project almost to its completion versus a more sequential thinker moving many projects forward simultaneously.

I too am a strong associative thinker vs. sequential, and am also more comfortable with focusing on one major project at a time. In her podcast @megedwards mentions that associative thinking helps us make sense of and respond to the vast amount of information we receive, which, of course is a benefit of GTD. I'd be curious to learn if associative thinkers are more drawn to the GTD methodology and whether sequential thinkers tend to favor more traditional time management practices.

 

[Gardener]

Just to add...I took the Kairos cognition assessment and I am predominantly an associate thinker versus sequential. This really helps explain my behavior to want to focus so much on one major project almost to its completion versus a more sequential thinker moving many projects forward simultaneously.

Huh. You made me curious and I went to take it. Apparently I'm a Balanced Thinker. ("neutral access to both of our brain's dominant processors") For some reason, I'm surprised.

 

[Oogiem]

I took the Kairos cognition assessment and I am predominantly an associate thinker versus sequential. This really helps explain my behavior to want to focus so much on one major project almost to its completion versus a more sequential thinker moving many projects forward simultaneously.

And that could explain my preference to stay in context. I am pretty strongly sequential on that test. Also very high reader and high listener which explains why noise or music distracts rather than helps me and why I MUCH prefer reading about things rather than seeing them done or hearing about them.

 

[Jared Caron]

Just to add...I took the Kairos cognition assessment and I am predominantly an associate thinker versus sequential. This really helps explain my behavior to want to focus so much on one major project almost to its completion versus a more sequential thinker moving many projects forward simultaneously.

Interestingly enough I am pretty strongly associative preference as well.
I can appreciate the value of both styles of working. I don't think one is better than the other.

I think I find them valuable precisely because I have a strong associative focus.
Context lists are most valuable when I am pressed for time (which is often) because they allow me to move a project forward without getting "sucked in".

To be fair, I also deep-dive into single projects regularly, and I strongly prefer to work that way. I just would struggle to get things done if I only took that approach. As I was describing, in the Horizons model this would be operating from "10,000 feet". Not wrong, just a different perspective and useful for that associative thinking. Some people prefer the view from 10,000 feet and make better decisions there. Others get overwhelmed and would rather stay on the ground...

However, sometimes you have no choice but to land the plane.

One of the strengths of GTD is that it helps you tap into both your associative and sequential processing abilities.

 

[mcogilvie]

If I’m understanding correctly, people are interpreting a “sequential” preference as preferring to work sequentially on context lists, and an “associative“ preference as doing next actions associated with the same project, but on different context lists. That seems to me to be an artifact of how you look at your.contexts and projects. If I am using Omnifocus, Todoist or Nirvana, I have the option of working either way. If I’m working sequentially through a project, that’s sequential, right? But if I do the same thing by thumbing through context lists, it’s associative? This all seems a bit facile. Am I missing something?