Unclear on How to Handle Projects

P

pi_seas

Guest
I have read GTD and have implemented most of the process. However, I am still unclear as to how the book recommends handling projects. From what I have gathered, I need to first write down just a simple one sentence or phrase for each project. Then I go back to the projects and write down the next actions for each project. Then, do I breakdown each next action into single steps to put into my 'In' box to work on?

I completely understand how this system works for the day to day things that always seem to pop up and interrupt project work. But do you then work on your next action steps for projects when all of the "less than 2 minute" items are cleared? If so, then it seems to me that we are still keeping "to do" lists, its just that instead of having items on to-do lists that are vague the book tells us to be specific with our to-do lists. What am I missing?
 

kewms

Registered
A Next Action *is* a single step. Once you have broken a project down to that level, the actions go on the appropriate context list(s) and you are ready to get to work.

The critical differences between a Next Action list and a conventional To Do list are, IMO, that NAs are already broken down to doable actions, and that NAs are sorted by context. Thus, you can actually do everything on the list.

Katherine
 

jkgrossi

Registered
pi_seas said:
I have read GTD and have implemented most of the process. However, I am still unclear as to how the book recommends handling projects. From what I have gathered, I need to first write down just a simple one sentence or phrase for each project. Then I go back to the projects and write down the next actions for each project. Then, do I breakdown each next action into single steps to put into my 'In' box to work on?

I completely understand how this system works for the day to day things that always seem to pop up and interrupt project work. But do you then work on your next action steps for projects when all of the "less than 2 minute" items are cleared? If so, then it seems to me that we are still keeping "to do" lists, its just that instead of having items on to-do lists that are vague the book tells us to be specific with our to-do lists. What am I missing?

Here's how I've come to understand and use projects, next actions, etc. within the framework of GTD:

1) You collect items throughout your day via your "inbox". So, the scraps of paper in your pockets, the notes you took at the staff meeting, your mindsweeps, etc..

2) You process your inbox. As you process each item you ask two key questions 1) What's the outcome? and 2) What's the next action?

Any action that takes 2 minutes or less gets done right now. All of the other actions go on your next action list, and if an item will take more than two actions to close the loop the "successful outcome" goes on your project list.

When you're in "work mode" and you're actively working on a project, a next action will act as a book-mark of where you leave off. That way, when it comes time to pick that project back up again, you know the very next thing that you need to do to get moving.

I think of next actions as place-holders rather than "to do's". IMHO, the big distinction between next actions and "to do's" is the next action lists are context-based and don't have a static priority assigned to them. Your lists of next actions are a list of your "options" given your context, level of energy, etc.

Jim
 
P

pi_seas

Guest
RE: Unclear on How to Handle Projects

Okay, now I think I see where this is headed. So then, for instance if I am using a calendar/list and I have scheduled in all date sensitive and time sensitive actions, then in the "free time" of the day I would write something like "Next Actions for Project X" and then refer to the NA's for that project, correct? If something comes up while working on NA's for project X, I would finish the NA I was working on and then address the item that came up using the 2-minute" rule, etc.? Is that correct?
 

jkgrossi

Registered
pi_seas said:
Okay, now I think I see where this is headed. So then, for instance if I am using a calendar/list and I have scheduled in all date sensitive and time sensitive actions, then in the "free time" of the day I would write something like "Next Actions for Project X" and then refer to the NA's for that project, correct? If something comes up while working on NA's for project X, I would finish the NA I was working on and then address the item that came up using the 2-minute" rule, etc.? Is that correct?

Sort of....

I don't think that it's necessary to schedule NA's in your "free time". You can if that what works for you, but I don't see the need. Here's basically what I do:

Like you, I schedule the time and date sensitive items on my calendar. When I'm free, I'll look at my NA lists and chose something based on what context I'm in, my level of energy, the amount of time I have, and what's got my attention at the moment (priorities). For example, let's say that I've just ended a meeting at 10:00AM and I've got about an hour until my next meeting. I'm at the office, so I've got my PC and phone near by. Let's say that I think that the most productive thing that I can do is make some headway on Project X. I'll look at my @office, @calls and @PC lists to see what's available to me "to do" related to Project X and do that. When 11:00 rolls around, I'll write a new NA that details the very next thing that needs to be done to move Project X forward so that I don't have to think about it again when I come back to that project.

Now, keep in mind that if I've only got 10 minutes before my next meeting, I'm probably going to pick a 10-minute next action rather than try to work on Project X. It would probably take more than 10-minutes just to dig out my project support material.

Hope this helps,

Jim
 

smithdoug

Registered
Next actions as placeholders

Jim,

I really like your notion of thinking of a next action as a placeholder rather than a to-do. My experience is that I usually don't make much progress on the kinds of projects that require a lot of concentration unless I can really immerse myself in them for a significant period of time. But when I have to leave the project and come back to it later, having a next-action "placeholder" should really help me get back into the flow of things. Thanks for a great way of looking at it.
 

TesTeq

Registered
Throw unlinked Next Actions into @context baskets (lists).

For each active Project you define Next Action(s) and throw them into the @context baskets (lists). You do not have to preserve any Project-NA links. In the non-scheduled time you are doing the Next Actions from the @context list which is appropriate in the environment you are in at this time.
 
W

willhains

Guest
I still don't get it...

So using the 5-phase approach to project planning - that's fine (and a very refreshing approach) - I may end up with a "plan" in the sense that I have a list of actions, but not all of them are actionable right now. What I mean is, there is an implied sequence to them. For example action #3 depends on successful completion of actions #1 and #2.

Where do I put action #3 when I come up with the plan? Does it go in Next Actions? Wouldn't that waste time because every time I look at it I'll have to remember that I can't do it yet?

If not in Next Actions, then where? The book says that the projects list shouldn't have plans in it (why not?), and even if it was there, it says to scan the project list less frequently (eg. Weekly Review). But then I would only do 1 action on the project per week!

I guess to summarise the big question I have:
So you figure out what the Next Action on a project is. That's great, but once that's done, what happens to get the Next Action after that? And how is this kept inline with the project plan?
In essence: how does the output of project planning feed into the GTD system?

Thanks in advance for any help you can give me!

Will.
 
next-actions-lists and project plan

willhains said:
In essence: how does the output of project planning feed into the GTD system?
Sorry, there is no interface to feed the output of project planning into the set of next-actions-lists. Usually the na-lists are not in sync with the project plan or project notes.

The synchronization is either done by your focused attention aided by tons of caffeine or you look up your "action after next action" in your project plan / notes. But fortunately you'll get interrupted before you can finish your second action and use that reminder as a bookmark for where you've been when you got interrupted.

If you know that you have an hour or more ahead of you to work on your project, then use your project plan as data to work from and not your next-actions-lists.

But if you know that a client or customer will come to haunt you in about 20 minutes, then work for those 20 minutes using your next-actions-lists.

Rainer
 

kewms

Registered
Not yet doable project-related actions are part of your project support material. File the list with any other materials related to the project. Filing details depend on your system: it could be a text file on your computer, a sticky note stuck in a file folder, whatever.

Katherine
 
P

pi_seas

Guest
RE: Unclear on How to Handle Projects

Eureka! Now it's clear to me. I went back last night and re-read the chapters that related to my question. Doing that and reading everyone's responses the concept is clear now. Thank you all so much for your answers, they were extremly helpful.
 

jkgrossi

Registered
willhains said:
I guess to summarise the big question I have:
So you figure out what the Next Action on a project is. That's great, but once that's done, what happens to get the Next Action after that? And how is this kept inline with the project plan?
In essence: how does the output of project planning feed into the GTD system?

Thanks in advance for any help you can give me!

Will.

Will,

As the others have said, the trailing next actions would reside in your project plan. These next actions will feed into the GTD system when you do your weekly review.

The reason that project plans are not included in a project list is because operationally, your project list is basically an index.

During your weekly review, you'll look at this index and consult the related project support file for trailing next actions.

Hope this helps,

Jim
 

eeckberg

Registered
Project Example

Remember, the project list is a simple list to help you keep a clear picture of what's on your plate from a bigger-picture viewpoint, especially during weekly review.

As an example, I am a computer programmer and have just received a request for a new automation project. This will take at least a week to complete and has a number of steps. Here's what I do:

First, it goes on my project list with the client client code I'm billing for. I try to word the short description as outcome-oriented. "Client K-043: Automation module for Profile XYZ". I number my projects to keep a sequential/chronological order to them. Because this project will have a number of pages of support materials (example profile, code listings, etc.) I create a project file folder with the same title.

I also create a project plan page, just a piece of notebook paper with a more detailed outcome statement and notes as to what needs to occur in what order. This goes in the Project Folder. I may go ahead and list three to five actual actions that need to occur to move it forward if they won't be obvious to me when I look at this later. Kind of a "don't forget you need to ..." type of list. I may also develop a more detailed/formal plan depending on the project. If it's a short project that will only last a day or two, the project plan sheet may be the only thing I create, no folder necessary. In that case, the Project Plan goes in my planner binder behind my Project Plans tab.

Now, which action is the real next action? Once that's decided, that's what goes on the @Computer NA List. "K-043: Print Profile XYY code for XYZ development".

When I kick off that print job, I pull out the project folder and look at the next action for the project. It gets written on the appropriate Context Action List. Now, if there are a series of two minute actions that I can devote time to, I can work directly off the project plan, but once I have to stop and put the folder the away, I MUST put the absolute Next Action on the appropriate Context Action List to keep it moving forward and not fall off the radar.

Basically, you flip flop between your Context Action List and the Project File to keep things moving forward. This allows you to do a single action for a project and feel okay about it instead of constantly putting it off because you feel you need to devote 2 hours to the project. You've listed the next action on the appropriate list and you KNOW it won't fall through the cracks.

This is my implementation for project management and is working well for me. I had to do it on paper in order to solidify the methodology, plus I the porability. I can grab a few project folders and my binder, then go hide at the local coffee shop to do some planning. That's another reason I preface the Next Action on the Context List with the project code. One quick glance, and I can see what projects are currently on my radar and know what folders to take with me.

Hope that clears things up a bit for you.

Eric
 
W

willhains

Guest
Thank you

eeckberg;42165 said:
Hope that clears things up a bit for you.

Eric

Sure does! Thank you very much for your at-the-coal-face description.
 

Fireproof

Registered
eeckberg;42165 said:
Remember, the project list is a simple list to help you keep a clear picture of what's on your plate from a bigger-picture viewpoint, especially during weekly review.

As an example, I am a computer programmer and have just received a request for a new automation project. This will take at least a week to complete and has a number of steps. Here's what I do:

First, it goes on my project list with the client client code I'm billing for. I try to word the short description as outcome-oriented. "Client K-043: Automation module for Profile XYZ". I number my projects to keep a sequential/chronological order to them. Because this project will have a number of pages of support materials (example profile, code listings, etc.) I create a project file folder with the same title.

I also create a project plan page, just a piece of notebook paper with a more detailed outcome statement and notes as to what needs to occur in what order. This goes in the Project Folder. I may go ahead and list three to five actual actions that need to occur to move it forward if they won't be obvious to me when I look at this later. Kind of a "don't forget you need to ..." type of list. I may also develop a more detailed/formal plan depending on the project. If it's a short project that will only last a day or two, the project plan sheet may be the only thing I create, no folder necessary. In that case, the Project Plan goes in my planner binder behind my Project Plans tab.

Now, which action is the real next action? Once that's decided, that's what goes on the @Computer NA List. "K-043: Print Profile XYY code for XYZ development".

When I kick off that print job, I pull out the project folder and look at the next action for the project. It gets written on the appropriate Context Action List. Now, if there are a series of two minute actions that I can devote time to, I can work directly off the project plan, but once I have to stop and put the folder the away, I MUST put the absolute Next Action on the appropriate Context Action List to keep it moving forward and not fall off the radar.

Basically, you flip flop between your Context Action List and the Project File to keep things moving forward. This allows you to do a single action for a project and feel okay about it instead of constantly putting it off because you feel you need to devote 2 hours to the project. You've listed the next action on the appropriate list and you KNOW it won't fall through the cracks.

This is my implementation for project management and is working well for me. I had to do it on paper in order to solidify the methodology, plus I the porability. I can grab a few project folders and my binder, then go hide at the local coffee shop to do some planning. That's another reason I preface the Next Action on the Context List with the project code. One quick glance, and I can see what projects are currently on my radar and know what folders to take with me.

Hope that clears things up a bit for you.

Eric

Great run-down. Gives me some ideas to refine my own process. Thank you!
 
S

skyking162

Guest
This discussion touches on the biggest reason why I haven't completely embraced GTD. My trouble is having the confidence that my NA lists really contain everything that I could be working on. They usually don't. For example, if I take 30 minutes to clear my @calls list, any projects that have steps after a phone call don't have anything on a NA list. Waiting up to week to look at the project during the weekly review in order to add another NA seems very inefficient.

One idea is to take time daily (or perhaps multiple times per day) to review recently checked-off NAs and look up the next NA in the appropriate project plan. Does anyone do this? Does anyone do anything more reasonable/efficient?
 
J

jac

Guest
A very common misunderstanding

Waiting up to week to look at the project during the weekly review in order to add another NA seems very inefficient.

Where does this misunderstanding come from? I have seen it so many times on this Forum.

Nowhere in GTD does it say you wait until your next Weekly Review before adding the next action to the appropriate context list. As you state, doing so would be extraordinarily inefficient in todays fast moving world.

Instead you should decide your next action immediately after completing the last one. Then either do it (and decide the next etc) or defer it and add it to your context list.

HTH
jac
 

kewms

Registered
I see the Weekly Review as a redundant safety check. That is, it catches any leaks in my system and makes sure that anything that goes "out of control" over the course of the week gets taken care of quickly. It is not intended to replace normal daily engagement with my work.

So yes, *of course* I review my project plans and update my NA lists whenever I need to during the week.

(A closely related common fallacy is the idea that you should only have one NA per project. An active project must have *at least* one NA -- otherwise it isn't active -- but can have as many independent NAs as you like. If it is immediately doable, put it on the list. I shudder to think what would happen to people who both limited themselves to one NA per project and refused to review their projects outside the Weekly Review...)

Katherine
 

packmatthews

Registered
The beauty of Front End Decision making

I too was initially confused, trying to visualize how NA's and Project plans populate each other. David and staff have been pretty clear that there is no way to automate this process and the weekly review helps catch leaks. However, the habit of Front End decision making, once I got that one, has helped me immensly. There's no point in putting the phone bill you just paid into your inbox when it would save a step to stick it right into the file folder for the phone. That's a small example of a front end decision. Now, many items get entered right into my @context NA lists as the lightening-fast planning process (most of which is too fast to get to paper) identifies what I need to do next. Then, as I complete that item, it's usually clear what the next step is going to be. I either dispatch that in the next two moments or it goes in a context specific list. Many very complex and mission critical projects of mine will go through the multiple Next Actions that define a project without ever being defined, named, or posted to the Projects list.

For example. Last night I started cleaning out the garage. I took a clipboard with me to mind dump all the potential projects that I encountered along the way so that I could keep on track with the cleaning. In the process I picked up a silver round object. "What is it?" the voice of David in my head asked. It was an extra hubcap from a previous car (Nissan Sentra). Was it actionable? Yes, it needed to be given away or sold on Ebay. Well that was more than a two minute task so it went on my core dump list under @Agenda/Hannah/ask freind who drives same model if she wants extra wheel cover. Low and behold, that very evening Hannah comes home with her friend who drives the same year and model as my old car. Item got delegated to her. Didn't even make it off my core dump list.

My point is, it's the habits of thought and action that I think GTD is trying to help us install. The paper trail is there to facilitate that, not to make our natural planning abilities and intuition untrustworthy or less lighting fast.
Pack Matthews
 
Top