Benefits to One Next Action

[furashgf]

There's some history that many people have misread David Allen's book as saying that there only can be one next action per project. There are also many methods that make it hard to track multiple next actions, like PigPog.

I'm just wondering if people who, for whatever reason, have been sticking with the one na per project rule have seen any benefits? I'm guessing in some cases you'd be less productive (since you might be in context N but not know you could be doing something on the project), but it might be simpler: reviews would be much easier/faster, etc.

 

[mcogilvie]

By coincidence, I am trying a modified pig-pog method right now. On palm and mac, I am using the format

Next Action > Project

Information about the project goes in the note section. The due date, if there is one, is typically the due date for the project. The next action changes as the project moves, and the context can change with it. I allow for a subprojects to fork off, as

Next Action > Subproject > Project

but the subproject has to eventually rendezvous with the project. I suppose one could fork off a singleton task with a syntax like

Parallel Next Action >> Project

but I haven't had to do that. The fork is done by duplicating the master entry, and I have software that allows this on mac and palm. If I have finished a next action, but don't know/have time to figure out the next one, I change the entry to

> Project

which signals that a next action is needed (I think I learned this trick from Frank Buck). I have been moving these items which need next actions (there have been few) back onto project lists, but soon I may just use unfiled for these.

So far, it's all good. Review is easy. The problem furashgf is concerned about does not arise for me. My biggest constraints are the things that must be done at work (not many) or must be done at my home office (not many), and my biggest list is @computer, with actions that can be done in either place. One issue is finding a project to update it. Searching for a project key phrase is sometimes the fastest way to find it. All in all, it seems a very workable system.

 

[cornell]

yes!

Great timing - I've had some problems making progress on a project, and just yesterday decided to *really* break it down. In my case I'm putting on a six hour workshop in a few months, and the next action is to send out a reminder to my network, asking for help getting people to sign up. I finally broke it down to simply "collect email addresses," which I was able to finish last night.

As Mark Twain put it:

The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one.

Now on to the next step!

matt

 

[howman]

I think it is perfectly valid to have many NAs for one project and in some cases it is required.

Let's say your house has a leaky roof (this hits close to home for me). Your next action might be - call roofer to schedule a repair. If you already know a roofer and already have the phone number in your address book, that would be a valid NA.

Now let's say you don't know any roofers. Your NA might be "@Home - Look up roofers in phone book and record phone numbers." Or, it might be, "@Home - ask neighbor who he used for his roof last year. Does he recommend?" These NAs are not dependent on one other and can be done in any order. Therefore, I would put both of them on my @Home context list.

Going further, the next part of the project would be to get estimates from three roofers. Once I have the phone numbers of the roofers, I would add each one to my @Calls list as separate NAs. It wouldn't make sense to list only one of the roofer and wait for that action to complete before calling the others. I can call any of the roofers in any order to set up an appointment.

The bigger the project, the more likely your will have parallel streams of activity.

 

[TesTeq]

You can use subprojects.

Going further, the next part of the project would be to get estimates from three roofers. Once I have the phone numbers of the roofers, I would add each one to my @Calls list as separate NAs. It wouldn't make sense to list only one of the roofer and wait for that action to complete before calling the others. I can call any of the roofers in any order to set up an appointment.

The bigger the project, the more likely your will have parallel streams of activity.

As mcogilvie suggests you can use subprojects for this purpose and have three separate parallel streams (subprojects) for each roofer. Each stream (subproject) will then have one next action only.

 

[kewms]

As mcogilvie suggests you can use subprojects for this purpose and have three separate parallel streams (subprojects) for each roofer. Each stream (subproject) will then have one next action only.

You could, but why? To me, that sounds like you're fracturing the project in order to fit arbitrary rules, rather than allowing the structure of the work itself to define the best approach. Also, an approach that needs subprojects for as simple a task as identifying a roofing contractor seems likely to collapse under its own weight when confronted with non-trivial projects. How many levels of hierarchy would this system need to build a house (or a moderately complex piece of software)?

One thing I've discovered in my own system is that there is no one BEST planning approach. Some projects require extensive outlines, detailed timelines, and lists of dependent and independent tasks. Some projects require three words scribbled on a sticky note. The right tool can make a huge contribution to the success of a project; the wrong one can sabotage it from the very beginning.

Katherine

 

[mcogilvie]

You could, but why? To me, that sounds like you're fracturing the project in order to fit arbitrary rules, rather than allowing the structure of the work itself to define the best approach. Also, an approach that needs subprojects for as simple a task as identifying a roofing contractor seems likely to collapse under its own weight when confronted with non-trivial projects. How many levels of hierarchy would this system need to build a house (or a moderately complex piece of software)?

This example illustrates precisely the problem. We had several big storms in the midwest a few weeks ago which caused a lot of damage. A family I know had their 2nd floor parted down the middle by a tree. If I put "ask neighbor about roofers" on a list somewhere separate from the rest of the project, I will never feel like I have the project under control because it seems like there is always some additional NA "out there." Personally, I would probably put "ask neighbors" somewhere in the note section of the item, and at some point do it or delete because with or without the neighbors' help I need a roof!

One thing I've discovered in my own system is that there is no one BEST planning approach. Some projects require extensive outlines, detailed timelines, and lists of dependent and independent tasks. Some projects require three words scribbled on a sticky note. The right tool can make a huge contribution to the success of a project; the wrong one can sabotage it from the very beginning.

Absolutely. I use folders (I bought some very nice Esselte transparent plastic ones the other day) for larger active projects, and I routinely use mindmaps and outlines. I put pointers like *SEE FOLDER* in the note section of the item to point me to them. The key point is that when you focus on a project you need to have all the relevant information about that project at hand, not "somewhere" in your system. I think the dispersal of next actions is a real issue. If you use a program that can assign a project title to a next action (this includes outliners, with assignment by placement), you inevitably spend a lot of time making sure everything is the way it needs to be, and problems happen. Of course, YMMV.

 

[nhardie]

PigPog?

Well I am the new guy here and one of the questions I have had since I began using GTD is whether to list next actions at the beginning of a project or let them appear in sequence as one NA leads to the next.

Now I am curious about something called PigPog ?

Can somebody clarify?

thanks

NH

 

[kewms]

Well I am the new guy here and one of the questions I have had since I began using GTD is whether to list next actions at the beginning of a project or let them appear in sequence as one NA leads to the next.

If you know you'll need to do it, write it down. But expect that new NAs will appear as you go, too.

Katherine

 

[mcogilvie]

Well I am the new guy here and one of the questions I have had since I began using GTD is whether to list next actions at the beginning of a project or let them appear in sequence as one NA leads to the next.

Now I am curious about something called PigPog ?

Can somebody clarify?

thanks

NH

See my post above for one pigpogesque implementation, or you can google "pigpog gtd" to read about it. Basically, it does away with the project list in favor of a constantly moving next action bookmark for each project. It is almost inherently a digital technique. It is neutral with respect to listing future next actions (in, say, the note field of an item). For myself, I try to write down reminders rather than plans. Plans change, but reminders are good to have until I don't need them anymore. A kind of mental martial arts move for me, I guess.

 

[andycwb]

I'm just wondering if people who, for whatever reason, have been sticking with the one na per project rule have seen any benefits? I'm guessing in some cases you'd be less productive (since you might be in context N but not know you could be doing something on the project), but it might be simpler: reviews would be much easier/faster, etc.

I haven't been doing that at all. I came at GTD via the My Life Organized (MLO) software which lets you break down projects into a hierarchy. Some projects have many next actions that will move you forward. When reviewing a project, or when I run out of actions, I try to come up with all the steps that I can easily identify as things that will move forward, and then structure them as parallel or sequential actions.

A concrete example: "Order Printer as requested by the boss", breaks down into "Identify options needed", "Get Quotes", and "Place Order". "Get Quotes" means I have to call three vendors with the spec, but it doesn't matter which order I do them in, they're all equally valid NAs. I put the whole lot down. I have a plan. I might not have the entire plan, since I know that placing the order has a coupe of substeps I can figure out later depending on the vendor (if X is cheapest I can order on line, otherwise I'll have to raise a PO).

I often just list "WTNA" as the next action for a project. What's The Next Action? I don't know right now, but I don't want to wait until the next review to figure it out. It's a reminder for me to spend some time planning that particular project before the next review.

 

[wordsofwonder]

While I don't typically adhere to the "one NA per project" rule, I do try (where appropriate) to keep my lists to one NA per project/context pairing. I've found that if I have multiple next actions for a project in a given context, I tend to spend too much time thinking about which one I should do rather than just picking one and doing it.

I'm helped in this regard by NoteStudio, which contains all of my GTD system save for Hard Landscape items. (These would go in NS as well, if I could set alarms for them.) Anyway, I've implemented GTD with NoteStudio using the "backlinks" approach shown in this movie. Because of how NoteStudio implements the backlinks, I can list something like this:

[@Computer] Complete task A
[@Call] Jane to confirm priorities
[@Email] Bob a status report
[@Computer] Complete task B
[@Computer] Complete task C

And only the first action in each context will show up in the corresponding list. When I complete task A, I remove it from the project page and then task B automagically appears on the @Computer list for that project.

I think the point made earlier in this thread is a good one, though: we can share techniques and ideas and thoughts and suggestions, but there's no one-size-fits-all implementation of GTD that works for everyone. For example, the hierarchical model used by the MLO/ShadowPlan/Bonsai folks totally paralyzes me, but it works well for some. That's why GTD focuses on the process, not the tools.

Tammy