Prioritization and Next Actions

[aprochaska]

I'm a GTD newbie, but I'm giving it a go because it makes sense and I've already seen some improvements. Most notably, the feeling of lower stress when I know things are contained in the work system so I don't have to remember them myself.

I'm struggling with a couple of things, though, and would be interested in others' thoughts...

I like and accept the GTD definition of a project: anything with more than 2 steps. This makes for a nice dichotomy: either it's an action or it's a project. Binary. Nice. Simple taxonomy.

In my work as a Project Manager at a Health Care company, I have a handful of company projects I'm managing at any one time. These are larger than GTD projects: they consist of many more than two steps. That's ok. I do my project planning and break it down into work steps. I may have several open loops for the project at any one time: Develop project plan, update budget, submit work request, get quotes for purchases. That's cool...I tag the GTD project with a prefix for the company project.

Here's my problem. My next actions list has become overwhelming and I don't know where to store actions that aren't the next actions. Say, I conduct a project meeting. We review schedules and tasks, we collect issues and actions and all go forth. Some actions are mine so I record them. But they aren't the NEXT ACTION for any of the open loops and they aren't a new loop either. They are usually things which have to be done, but I wouldn't put them in the front of the line. What to do?

I tried creating a category "Future Actions" to capture them. I also thought about putting them in the category "Inbox" which means they have to be processed and then either done or scheduled. Not sure...

I also see a huge list of next actions and think I need a prioritization function in it. Within the collected actions some are clearly related and there is a priority sequence to them. I can usually pick out the real NEXT ACTION, but what do I do with the rest? I'd like to capture them in a queue somewhere so I could pick up the next appropriate one and make it the NEXT ACTION when it's the right time.

Thoughts, anyone? Sorry to ramble so much....
Thanks for any help.

Alan Prochaska
Pasadena, CA, USA

 

[kewms]

Future actions are project support materials, and can be filed wherever other project materials go.

Katherine

 

[GTD Sydney]

I'm also coming to grips with next action vs: 'just' action, future actions, multiple project actions, etc. For me very few actions/NA's are strictly sequential. It seems most if not all are a matter of selection and prioritisation vs. "this MUST be done before that can be done."

There are other threads here on this topic and I too seem by nature inclined to want/need to write down (electronically or on paper) all actions I can think of for a particular project. I am learning the discipline of then storing those lists, plans, and notes in a proper project support file (again electronic or paper depending on the project).

What I think I have yet to learn is that this need/inclination is something I can safely "let go" of, as I progress with GTD. From reading 'experts' like Katherine and Brent, I'm realising the GTD truth that things change so rapidly every day and this means any action/note/plan that is NOT a true next action may -- will!? -- very likely change and my precious plans/lists/notes of other actions/future actions will quickly become obsolete or old or not really useful because so much has changed there are new actions and new priorities and so on.

But for the moment I too am still saving all the 'possible' actions ... your post has helped me focus on a new goal of "letting go of much that is not a true next action." It seems counter-intuitive for a somewhat detail-oriented, "completed staff work" person but it seems that's a real design point of GTD - that it's safe to do that letting-go, and/or no-one will beat us up if we do put all our action/future action lists in a project support file.

 

[Cpu_Modern]

Here's my problem. My next actions list has become overwhelming and I don't know where to store actions that aren't the next actions.

These belong into the so-called "Project Support Material".

I also see a huge list of next actions and think I need a prioritization function in it. Within the collected actions some are clearly related and there is a priority sequence to them. I can usually pick out the real NEXT ACTION, but what do I do with the rest? I'd like to capture them in a queue somewhere so I could pick up the next appropriate one and make it the NEXT ACTION when it's the right time.

That queue is also part of your "Project Support Material". About sequence, priorities and so on in projects read p.74 ff about "Organizing" in the book.

Priorities in NA-lists are for loosers.

 

[luomat]

Priorities in NA-lists are for loosers.

Looser than what ;-?

For what it's worth if I have a series of sequential steps that need to happen, I write them all down on the same sheet of paper.

To adapt one of David Allen's examples from The Book, assume you need to get your car serviced and want to call your friend Tom to find out the name of the garage he uses.

My next actions might be

1) Call Tom for number of garage @phone
2) Call garage to schedule appointment @phone
3) Add appointment to calendar
4) Check extended warrantee to see if work should be covered @home

The idea that DA put forth is that you ought to do your thinking as early as something comes on your radar screen. So if you know of other steps which need to be taken, put them all down.

Actually #4 above does not need to wait until I do any of #1-3 so it could go on its own next action list @home and probably should actually.

I just finished the audiobook (unabridged) and agree he didn't go into this multi-step stuff as much as I wish he did.

Priorities, DA says, will become clearer IFF you have done your weekly review and everything else is in shape. Trust your intuition/gut feeling.

If it doesn't have a physical action attached to it, it's resource material.

 

[scott.stephen]

Alan, I hope this will help a little.

A project is actually anything that has more than one action.

The GTD system is definitely for ALL sizes of projects. A large project usually just means that there are sub-projects within. Each sub-project should be treated as project when it comes to processing.

Any material/ideas/plans/contacts/agendas should go into your support folder for the project in question. Remember, a sub-project is a project. So, your actions, that aren’t NA, should go into this folder.

Your different context lists (@Work,@computer,etc..) should only contain physical next actions. If you keep to this, your lists should not be overwhelming.

For prioritization, try DA system: context, time available, energy available, and finally by priority (once you have gone through the first 3 thoughts, the prioritization should be natural).

During your review process (minimum weekly) you will review all of your projects (and sub-projects), the material within should help you decide on your physical next action.

If you have extremely complicate projects, with tons of milestones, and interdependent sub-projects, I suggest using a project planning system such as MS Project. But, only if absolutely necessary.

Regards,
Scott STEPHEN

 

[aprochaska]

Wow! Great replies, and fast, too. I guess that bespeaks an attentive, sincere community.

The idea of all these other ideas, possible future actions, etc going into the project support materials makes sense. In Notes I have a task for a project and links pointing out of the body of the task. So I'll collect all this project information in the task body, then review and process it during the weekly review. From there I'll select the real Next Action and put that into the context list.

Conceptually, I'd really like a network diagram (aka PERT chart) of each project's tasks. That's what I have in my head whether or not I create one for the project. When issues, actions, etc come up, what goes on inside my head is the creation of a new box that gets inserted somewhere in the network, and the dependencies adjust appropriately. I'll have to work on that more....

A technique I established in Notes a while ago, and continue to use, especially in situations like these is to pre-define text styles representing different statuses. Red-Bold: Action to Do, Green-Bold: Action-Completed, Orange-Bold: Action-Inprogress, ... This way important things jump out clearly, distinct from simple information. As I collect the project support information into the body of the task, I can categorize the items as I see fit then. I may reevaluate during review and processing.

Thanks for the responses.

Alan Prochaska

 

[quantumgardener]

Here's my problem. My next actions list has become overwhelming and I don't know where to store actions that aren't the next actions. Say, I conduct a project meeting. We review schedules and tasks, we collect issues and actions and all go forth. Some actions are mine so I record them. But they aren't the NEXT ACTION for any of the open loops and they aren't a new loop either. They are usually things which have to be done, but I wouldn't put them in the front of the line. What to do?

If they aren't the next action for any open loops, but you expect them to be, then there must be some trigger event which will change their state from non-NA to NA. Outside of project support material as already described, I'd be

a) checking there really isn't a NA there
b) working out what I have to wait for eg. "@waiting for Julie to tell me that here part of the project is complete" and manage those
c) forget it and wait for the time to come. I used to track many NA's that never came to fruition.

David