Hybrid single Next Action / Project list? (Outlook)

[jengagne]

Hi all. I've read the book and a lot of the forum, but I guess I'm still fuzzy on why you would want to divorce your Next Action list from your Project list.

Perhaps I'm confused because of my working scenario -- a set of projects that always have a single Next Action. If there were multiple parallel actions I can see why you'd need multiple Next Action items.

But in this case, I'm left wondering if it's really necessary to build out a separate Next Action list.

I'm theorizing that I could instead indicate the Next Action right there in the title of the Project folder, like:
"Article on Confidentiality (Call Donna for details)"

And then put that folder itself in the @Call list, or whatever.

That way all the Project emails etc. are together, along with my notes in chronological order.

And then of course I can just move the project folder around as needed whenever I change the next action.

(For the record, I can't install any plugins and I need to do this inside of Outlook, so those are my constraints.)

Any advice appreciated! Thank you!

[TesTeq]

GTD – The PigPog Method uses no Project list in the similar manner.

[jengagne]

Ahah, good to know someone successfully pulled this approach off, thanks!

Now I'm wondering whether to list the action first, or the project name.

Listing project name first would stop it from jumping around in my list whenever my action changes.

OTOH, listing the action first would group similar actions together: call, read. I'm thinking that's the way to go since that way if I'm in a "calling mode" or a "reading mode", they're all there together.

Also, having them jump around the list as the actions change isn't necessarily a bad thing. In the past using other task lists, I've sometimes found myself focusing a bit too much on the items above the fold, ignoring N through Z... So a mixed-up list may help me get a fresh perspective whenever I see it.

[mcogilvie]

GTD – The PigPog Method uses no Project list in the similar manner.

Frank Buck also described a similar approach in some posts several years ago. You can find them by searching for his user name under Advance Search. He used entries of the form "next action + project". I have been playing around with it recently, but I am not sure I want to use it regularly. I think it is fine if you are committed to one action at a time per project, but for some projects, I have multiple threads going at once. Also, I miss checking things off!

[Longstreet]

Hi Folks,

This is an intriguing thread....how many GTDers out there follow the pig-pog method? I can see a strong benefit in that it forces one to maintain a next action for each project. Of course, one downside as pointed out by mcogilvie is that you can only have ONE next action on your context lists per project.

What does the GTD team feel about this approach?

-Longstreet

[RegionalSalesman]

I followed this approach prior to my GTD days. In outlook I had my tasks mainly occupied with contacts (clients that is). Everything related to these contacts was included in the body of the task. I moved these contacts/tasks to and from different categories (next actions) according to the situation at hand. Outlook only displayed (filtered) active tasks and if I had completed a project I didnt mark it as completed, instead as "not started". This way I had all the prior history also at hand when starting a new project associated with this client.
This approach was ok to an extent, but as I've gradually been able to dive deeper into mind like water i've found genuine value in the simpler approach.
-Jukka

[context]

@jengagne: Projects are end states or outcomes (i.e. the way things are when you're done). Next actions are things that you physically do (verbs, verbs, verbs). If you mix the lists the meaning of the list becomes mixed. When you want to know what you can do from where you are physically you don't really need to know what the outcome is -- you just need to move.

[jengagne]

@Longstreet -- For me, that requirement that you promptly figure out the next action and reclassify the project is a huge advantage. I promise myself that I will define my next remaining action before closing a project folder.

But you could give yourself the "always figure out next action" requirement no matter how you use GTD, right? That could be useful regardless.

@context -- yes, I can see how this action+project approach would be problematic for someone working from multiple locations or with multiple next actions to take.

I guess I'm lucky in that my productive life is at a computer with a phone next to me and my contacts nearby. I do use a naming convention for my next actions so all similar actions get grouped together: "call", "email", "visit" (for the people who never reply to emails...). So depending on what mode I'm in, I can knock out a set together.

It's conveniently rare in my case that I run into situations that have multiple next actions. I'm also lucky in that I haven't run into any issues with branching.

One branching point: delegating a sub-project. I just kept the email where I sent the person the information in the same folder, then used that as the basis for calendar reminders to follow up with the person. If I get status updates, those go in the folder and revise my reminder (and possibly my next action)

Rarely, I do need branching for sub-projects: made a duplicate folder (again with a cross-reference) just so I have the history of that branch up to that point. For whatever reason, I haven't run into trouble (yet) with this approach. I can definitely see how it could get out of control for frequent or multi-branching, though; I'd lose a sense of what's going on with the overall project.

@everybody -- thanks again. If I ever end up in a "power user" situation I can see how doing it the other way around would make more sense, so all your explanations help!

[J.D. Iles]

I approached this issue just like this for years, but for the last few years I have followed GTD to the letter in regards to projects.

Ask yourself the following:
The reason you upgrade something to a "project" is because it is critical enough to not lose track of. You are someone else is going to be looking for completion on this.


Can you review your list of projects in under 2 minutes? If not, there is a hole in your system.

[rdgeorge]

Best practice would be separate Project List and NA lists. NA's can be sequential, for a given project, or not.