Keeping NA List in Sync with Projects

[dgorley]

I've only been using the GTD process for a few days now, but already I'm noticing an improvement in my comfort level with the things I'm doing. It's great to be able to see, at a single glance, all the balls I've got in the air, and all the things I could be doing right now.

I've got a question about how people manage "Next Actions" that are attached to projects. Having a next action for all of your projects seems like a great idea, but once I've completed that action, then what? It seems to me that ensuring every project has a next action is a task for the Weekly Review, but I find I don't want to wait until then to move forward.

Here's an example: one of my projects is "Create program X". The next action associated with that project is "Define potential inputs and outputs for program X". Once I complete that task, I find myself thinking if there's something else I should be doing on that project, and if there is, I add it to the NA list.

This process is functional thus far, but it feels kind of clumsy. Does anyone have any better suggestions on keeping my NA list in sync with my projects?

 

[neil007]

NA's

Define the NA(s) at the point of completing the previous one. If its a priority now or takes less than 2 mins do it. Then define the next one. Think of an NA as a stake in the ground so you know where you are with your project next time you look at it.

 

[Mark Jantzen]

How do you synch up or link projects & next actions? Your mind does that and no software or artificial intelliegence (yet) will do it for you. I'm paraphrasing David here and I believe it's true.

From my experience, most of the time the next action is obviously tied to the project. Example, if a next action is "Surf the web for new tire information" your mind will go "oh, yeah that's the 'New tires on car' project".

One technology solution is the Find feature - e.g. Palm or Outlook. For me, that synchs up projects & next actions well. Find "tires" and I've got my project and next action and maybe even a few other trigger reminders.

I've seen many thoughtful people describe more complicated (to me) solutions, but I really wonder if the effort vs. payoff is worth it. But I'm attracted to the GTD methodology largely because of the "lazy" aspect, "how to get as much done with as little effort as possible".

Mark

 

[andersons]

dgorley, in my experience this is one of the most frequently asked questions about implementing GTD. The answer is dependent on what tool(s) you use to maintain your lists: your choice of tool will dictate a lot of what you have to do to keep actions and projects synced. There are many approaches that have been discussed at length on the forum, such as the projects-as-contacts method which uses Outlook.

If you are not yet committed to a tool, you may want to search the forum to read about the many ways of syncing projects and actions with different tools. If you are committed to a tool, you may want to search on the name of the tool to read about how other people implement GTD with that tool.

I too find maintaining separate projects and actions lists clumsy. It is natural to think of actions as subordinate to projects, just as David Allen in the book describes outlining a project using Microsoft Word. There are much better outliners than Word, though -- including some specifically designed for projects and actions. I use an outliner that also shows the actions, which are at the bottom of the hierarchy, in a separate context-based NA-list view. There is no need to sync projects and actions since the NA lists are just a different view of the same data. The outlining tool for me eliminates the tedious aspect of syncing projects and actions, frees me to think of my projects at a higher level much more easily, and does not constrain me to have only one NA per project. Most importantly, it does not require me to maintain the connections between projects and actions in my head.

 

[andersons]

How do you synch up or link projects & next actions? Your mind does that and no software or artificial intelliegence (yet) will do it for you. I'm paraphrasing David here and I believe it's true.

How can you know that "no software will do X" unless you have personally investigated every piece of software out there? And kept up with that investigation because software development is an constantly changing landscape. There is no logical reason to believe in universal negatives, especially in the constantly-changing landscape of software and technology development.

I have used at least two software products that will sync/link projects with actions for you so that you don't have to do it in your mind. I have read about a third here on this forum. Not everyone may want to use them, but they do exist.

 

[jkgrossi]

The way that I overcame this very thing was I stopped associating Next Actions with "To Do's". I came to the realization that rather than To Do's, Next Actions were simply reminders of what the next physical action is to move something forward. I believe that is an important distinction, and once realized, will help you get past the need to "sync" in some sort of artificial fashion all of your projects and their related NA's.

Using your example: one of my projects is "Create program X". The next action associated with that project is "Define potential inputs and outputs for program X". Once I complete that task, I find myself thinking if there's something else I should be doing on that project, and if there is, I add it to the NA list.

The time that you would need to figure out what the next action is (the "something else I should be doing") is when you stop working on project "X" and need to put a stake in the ground to remind you where you left off, or you could just catch this at the weekly review.

You wouldn't necessarily, upon the completion of "Define potential inputs and outputs for program X", stop what you're doing, think of the NA, write that NA down and then keep working... Instead, you'd just keep working.

When you reach a stooping point, you'd either:

1) Put the project aside and move on to something else (and catch the NA at your weekly review), or
2) at that point think of what the NA is and write it in the appropriate list as a reminder for when you pick up the project again to start working.

At least, that's how I'd do it.

 

[jkgrossi]

How can you know that "no software will do X" unless you have personally investigated every piece of software out there? And kept up with that investigation because software development is an constantly changing landscape. There is no logical reason to believe in universal negatives, especially in the constantly-changing landscape of software and technology development.

I have used at least two software products that will sync/link projects with actions for you so that you don't have to do it in your mind. I have read about a third here on this forum. Not everyone may want to use them, but they do exist.

Well, I think that what DA means is that he doesn't believe that the technology exists currently that can do the job as elegantly as the human brain.

Even though the software may exist that is capable of accomplishing the task, it's still more cumbersome that just using your brain to do the job...

I think that's the spirit of what Da was trying to say.

 

[kewms]

Well, I think that what DA means is that he doesn't believe that the technology exists currently that can do the job as elegantly as the human brain.

Even though the software may exist that is capable of accomplishing the task, it's still more cumbersome that just using your brain to do the job...

I think that's the spirit of what Da was trying to say.

But DA has also said that you should get things out of your brain and into a trusted system whenever possible.

As I see it, "keeping NA list in sync with projects" means making sure that you know where you are with each project and what you need to do to move forward. But that's really two different tasks. The first is planning: actually deciding what the actions required to complete the project are. And you're right, the human brain is the best tool for planning.

But the second task is housekeeping: making sure that the results of your planning are captured somewhere that allows you to find them again. There are lots and lots of tools that can (and should, IMO) handle the housekeeping component.

So many, in fact, that I have trouble understanding why this question keeps coming up. IMO, if "syncing tasks and projects" is difficult, there is a serious problem with your system.

All you're doing, really, is creating an outline. The projects are the top level, subprojects are the second level, and next actions are the bottom level. Thus, you need a tool that lets you
* collapse the outline so that you only see the top level, also known as the project list
* expand each individual project so that you can see the actions associated with it
* sort the next actions by other criteria, such as context or date, without losing their association with their parent project

Note that I'm using the term "outline" in its most general sense. You can actually capture the structure however you want, from a formal outline in a word processing file to post-it notes stuck to a wall. The important point is that the entire structure, including the relationships between projects and actions, must be captured by your system. If it isn't, the system can never be trustworthy.

Katherine

 

[jkgrossi]

The important point is that the entire structure, including the relationships between projects and actions, must be captured by your system. If it isn't, the system can never be trustworthy.

Katherine

I don't know if I agree.... capturing the entire structure in your system may make it easier to review, but I don't think that it necessarily makes it more trustworthy. I don't link them as you describe, and I trust my system completely (and rightfully so).

I know that at least once per week, I'll review my projects and make sure that each one has an action associated with it. If an NA gets completed during the week, and a subsequent NA isn't created on the spot, I don't fret over it (i.e. it's off my mind) because I know that a NA will be created at the very least during my weekly review.

So, I don't necessarily see the need to "link" projects and tasks via an outline. In fact, I think that I'd find this level of structure burdensome.

In my opinion, the more you try to structure something, the more you restrict it. My system would move way too slow for me if I had to maintain the links as you describe.

Jim

 

[kewms]

I know that at least once per week, I'll review my projects and make sure that each one has an action associated with it. If an NA gets completed during the week, and a subsequent NA isn't created on the spot, I don't fret over it (i.e. it's off my mind) because I know that a NA will be created at the very least during my weekly review.

So, I don't necessarily see the need to "link" projects and tasks via an outline. In fact, I think that I'd find this level of structure burdensome.

I guess I wasn't clear, because it sounds to me like your system does *exactly* what I describe. You clearly are able to keep track of what your projects are, and the status of each. If you can do that, your system works, regardless of what the implementation actually looks like.

Katherine

 

[jkgrossi]

Well, that's why I wasn't *sure* if I agreed ;-).

It *sounded* to me like we were saying the same thing... (and I had a nagging feeling in my gut that we were ). I just wanted to be clear that IMHO an actual hierarchy wasn't necessary.

Others mileage may vary...

Jim

 

[pageta]

I think that projects have to be reviewed more often than just weekly in order to do the proper planning. There may be one next action, there may be simultaneous next actions. There may be next actions that you can do today that you couldn't do yesterday. Thus I try to review my projects at least as often as I progress on them. In other words, if I work on it every day, I review it once a day to make sure I'm doing everything I can be. But if I work on it once a week, then I only review it once a week. So I guess you could say, every time I finish taking action on a project, I do a quick review to make sure everything is in order for the next time I come back to it.

 

[andersons]

So many, in fact, that I have trouble understanding why this question keeps coming up. IMO, if "syncing tasks and projects" is difficult, there is a serious problem with your system.

All you're doing, really, is creating an outline. The projects are the top level, subprojects are the second level, and next actions are the bottom level. Thus, you need a tool that lets you
* collapse the outline so that you only see the top level, also known as the project list
* expand each individual project so that you can see the actions associated with it
* sort the next actions by other criteria, such as context or date, without losing their association with their parent project

Beautiful post. Wow.

I think the syncing question comes up because the true hierarchical structure of actions and projects is not made explicit in GTD. If you follow the book, there's a list of projects. And several separate lists of NAs. So for a beginner, you look at your long list of projects and longer list of actions and don't see all the relationships. (Or at least, some people might, but other people don't.) You can even look at an individual NA on your list and wonder what the heck it's about, if its relationship to its parent project isn't immediately obvious in your mind. If the connection IS obvious, it's because you remember it -- it's in your head.

It's true that you can maintain these separate lists, which do not explicitly or visually show the structure, and if you keep reviewing them, your mind WILL create the structure for you. The brain's learning mechanism is essentially to create hierarchical structure. And you may help your mind out by using naming conventions, codes, symbols, etc. to create and remember that structure more easily. But the structure visualized in the expanded outline view Katherine described will exist only in your mind.

But if you make the structure explicit by writing it down, it doesn't restrict you. (If you don't like the word 'structure,' maybe think of 'relationships.') The structure already exists; you're only making it explicit and visual and therefore easier to remember. You're just writing it down.

So why write it down? Well, why write anything down? Writing down the structure has a similar benefit to writing down anything else, like a list of stuff that's on your mind. Writing things down actually encodes a stronger, more organized memory. And the written reminder serves as a trigger to recall the previously encoded memory. Without the encoding and trigger, you need a lot of rehearsal to remember stuff.

Therefore I think that the expanded outline view Katherine describes adds value to GTD and takes it to the next level (literally -- pun not intended!). If it's good to get all your commitments down in lists, rather than keeping them in your head or in scattered physical reminders, then why isn't it good to get the structure of projects and actions down visually in one place too.

And yes, there are many ways to visualize hierarchies. Outlines are just compact and familiar.

 

[kewms]

Therefore I think that the expanded outline view Katherine describes adds value to GTD and takes it to the next level (literally -- pun not intended!). If it's good to get all your commitments down in lists, rather than keeping them in your head or in scattered physical reminders, then why isn't it good to get the structure of projects and actions down visually in one place too.

Thank you for the kind words, but please remember one of the points you deleted: it doesn't matter how you capture the structure, as long as you do. Any system that reliably captures and retrieves the information is fine. That includes stacks of index cards and other tools that don't look like hierarchical outlines, but turn out to capture the same information.

I emphasize this point because I've seen so many posts obsessing about tools. Though there are many excellent tools out there, the One Perfect System doesn't exist, and looking for it can easily get in the way of getting things done.

Katherine

 

[andersons]

. . .please remember one of the points you deleted: it doesn't matter how you capture the structure, as long as you do. . .That includes stacks of index cards and other tools that don't look like hierarchical outlines, but turn out to capture the same information.

Yup. I thought I got it with the last line "there are many ways to visualize hierarchies. Outlines are just compact and familiar."

And my point was that you can capture and retrieve the structure entirely in your mind, without any external tools, but it's advantageous to write it down somehow. I'm making a case for the usefulness of visualization.

I agree that the most important thing is to capture the structure somehow, and that the traditional outline is not the only way. I might add that some people I have taught just don't see relationships when they look at an outline, but will see them readily if I use boxes and arrows. Many people are comfortable with outlines, but some people are not.

However, I don't agree that the how doesn't matter at all. In 10 years of teaching, I have seen huge differences in learning and memory of depending on the visual structure of information. In one class, I taught 6 different ways to organize information, as well as how to determine which way(s) worked best for which kinds of information. (I didn't invent those 6 ways, BTW. I'm sure there are many more.)

I emphasize this point because I've seen so many posts obsessing about tools. Though there are many excellent tools out there, the One Perfect System doesn't exist, and looking for it can easily get in the way of getting things done.

Yes. But not all tools help you do the 3 things you listed -- collapse the outline for a project list, expand the outline to see project-action relationships, and show you actions by context. Some tools really help with this housekeeping, others don't. The ones that don't, IMO, are not well suited to GTD and cause more obsessing than the ones that do. (Not to say they cannot be used and sometimes have to be.) People do have legitimate problems with tools not being suited for the information they want to track. For me, the value of changing my tool was immense. I really did get more done with less stress.

Obsessing about tools can surely be a means to avoid work, but don't people know that even while they obsess? Do people really believe that a perfect tool will help them get more done? Are we so in the dark about how unproductive our tools can make us? That would be ironic! If not obsessing about tools, wouldn't we be obsessing about something else or finding other means to procrastinate? (Like organizing other stuff, not just project and action information.)

I kinda think of GTD as being a bit obsessive in general. Collect everything, process everything -- even if it takes you 2 days initially -- keep everything organized, review. . .

 

[mcogilvie]

This is a general comment on this thread and a request for ideas. I have found that vanilla GTD with no explicit connection between Next Actions and Projects (on a Palm, say) can work very well for a large percentage of projects. Somewhere around 80% of my projects have, at any given time, a small number of NA's (often 1). The state of the project at any given time is easily described. Unfortunately, those are NOT the projects which are most important in my work. The most important projects are characterized by a large number of potential next actions, many moving parts, complicated state, large amounts of information, and shifting, tentative goals. What I don't see in any of the GTD material is how to handle these kinds of projects. These are not GAANNT and PERT chart projects, by the way. The issue is really not deadlines or resources, but the inherent difficulty of the problem. In other words, I see how the GTD system scales with volume, but I don't see how the system scales with complexity. So if anyone has tools, techniques, or words of wisdom for handling such projects, I would love to hear them.

 

[jwarlander]

Being some 6 months or so into struggling with implementing paper-based GTD, I don't know how valuable my advice will be, but I'd like to describe my setup since the Project vs. Next Action tracking was something that I felt had to be dealt with..

I'm using a Filofax planner, with the calendar (of course) and then sections related to my GTD implementation: Next Actions, Projects, Agenda, Checklists.

• Projects are divided into Work and Home, then numbered from 1 and up, like "W39 Write instruction for startup / shutdown of tape robot".
• Next Actions are divided into contexts and have a description and a reference to the project, like "Take photos of tape robot controls (W39)".
• Project support material is gathered into hanging folders that are numbered according to the project references, ie W1 - W61, H1 - H29. This way I never have to do any further folder labeling, except for extending the system in case of project overload of course.

I also have a small section in the planner for project planning material in case I want to do some of that "on the road", then I can just merge with the project support material when I get back home or to my office.

Recently I've abandoned the "pure" pen-and-paper approach in favor of keeping the actual lists as documents on my computer, then printing them on A5 paper for the planner. During the week I do write on the paper version of those lists for changes and additions, but the computer document gets updated and printed during the weekly review. Similarly I'm probably going to merge my contacts from the planner into Outlook and make printouts from there instead, though I haven't tested that yet.

Anyways.. this is how it works right now. It might change as I find that some things don't work or could easily be done in a better way.. but that's no different than for any other system, I guess

 

[pageta]

I'm another paper person and I recently had an idea that helped not only sinc my projects with next actions but also with someday/maybe's. I'm a paper person who just uses blank notebook paper and blank tabs (different colors) so I have no clue how this might work in a computer program of some kind. Anyway...

I have one section in my notebook for each context. I have home, contacts, office, errands, etc. At the front of each section are the next actions for that context. Behind the next actions are projects - one page for each project. The projects with the most activity are in front, those that are still in the planning/brainstorming stages are toward the back. Then behind the projects are my someday/maybe lists.

For example: under Home, I have my next actions. Behind that, I have a page for a room I am currently re-decorating. On that page I have notes and ideas for what I want to do, as well as next actions. If the next actions are to buy something, it is also on the front page/next actions of my Errands section (buying the paint). If a next action is something that easily stands alone and can be accomplished in a generally short amount of time, the next action goes on my next action list in Home. If the next action is one that will lead to a bunch of others or require a large chunk of time, it stays on the project page because I will see it when I am working on that particular project and I don't want to have to think about it unless I have a large chunk of time to devote to it (like painting the walls). Behind this project (and others like it) are my lists of home improvement projects that we've talked about doing but haven't done anything more than talk.

The beauty of this system is that when I am at home, I can see what my next actions are, what projects I have going on currently, the things I want to do - all in one place (I'm not flipping between three sections to see the big picture). So I can easily determine if I have time to start another project I'm excited about at the moment or if it really needs to wait.

My wish lists of things to buy (toys for my son, clothes for each member of the family, things for the house) all go under Errands because it is when I am in town that I might see those things or have a chance to shop for them. My style of buying things is to do a lot of shopping before I actually buy something so having my lists of what I think I might want to buy is very practical for me. If I'm driving by a furniture store that's having a sale and I have the time and energy to stop by, I can glance at my list and know what items I might want to make sure I specifically look at (i.e. bedroom furniture).

With this system, it doesn't really matter that all of my next actions for a certain project are on my next action list. My next action list is basically a list of quick hits - things that can be done very quickly (less than an hour). If I have a larger chunk of time (like an afternoon), I can go back a few pages and look at my projects and just work on one of them for a while.

 

[pageta]

This is a general comment on this thread and a request for ideas. I have found that vanilla GTD with no explicit connection between Next Actions and Projects (on a Palm, say) can work very well for a large percentage of projects. Somewhere around 80% of my projects have, at any given time, a small number of NA's (often 1). The state of the project at any given time is easily described. Unfortunately, those are NOT the projects which are most important in my work. The most important projects are characterized by a large number of potential next actions, many moving parts, complicated state, large amounts of information, and shifting, tentative goals. What I don't see in any of the GTD material is how to handle these kinds of projects. These are not GAANNT and PERT chart projects, by the way. The issue is really not deadlines or resources, but the inherent difficulty of the problem. In other words, I see how the GTD system scales with volume, but I don't see how the system scales with complexity. So if anyone has tools, techniques, or words of wisdom for handling such projects, I would love to hear them.

Try subprojects...

In other words, identify small projects that you can work toward and complete that apply to the larger goal. If your goals are that big and that changing, you will drive yourself crazy trying to keep things going on that level. Just do GTD with the things that are small enough to actually identify and make progress on and you'll find that you'll be making progress toward the whole project as a result.

 

[jkgrossi]

And my point was that you can capture and retrieve the structure entirely in your mind, without any external tools, but it's advantageous to write it down somehow. I'm making a case for the usefulness of visualization.

I'm not sure I necessarily see those advantages... if anything, in my opinion it's just creating more "work".

However, I don't agree that the how doesn't matter at all. In 10 years of teaching, I have seen huge differences in learning and memory of depending on the visual structure of information. In one class, I taught 6 different ways to organize information, as well as how to determine which way(s) worked best for which kinds of information. (I didn't invent those 6 ways, BTW. I'm sure there are many more.)

I don't think that it matters because we're not talking here about learning or improving memory. If anything, we're trying to free up memory so that resource can be allocated to other things.

It doesn't matter at all because I don't care about improving my memory related to my projects and NA's. In fact, I want to forget about those things... until I'm at a time and place where I can do something about them.

IMHO, artificially linking projects and NA's just creates more work and makes the process that more cumbersome.

However, I do agree that it makes the review process easier, and it might be a good crutch for those just starting out.

Jim