next actions with dependencies

[ArcCaster]

Hi

Per the outlook white paper, I am using tasks to manage my projects and next actions.

Some of the next actions in my @computer list cannot be done until I receive confirmation of an agreement, which I am trackling in @waitingFor. So, they really do not belong in my @computer list because the dependency on confirmation first makes them 'undoable' actions. Trouble is, I thought of them, I will do they as soon as I have confirmation, and I want to keep them somewhere. I was thinking of moving them to the body field of the @waitingfor entry until I get confirmation, and then, when they really ARE next actions, moving them to @computer.

How do you handle temporarily undoable next actions?

 

[moises]

I am going to be a stickler about terminology, in order to make this thread clear. A dependent action can never be a next action. Dependent actions go on your "Project Plan." In Outlook, for small- to medium-sized projects it's fine to put the plan in the notes field of the Outlook item.

When the waiting-for is complete, you can move your formerly dependent action, now next action, off of your project plan and into a context list.

 

[mcogilvie]

Hi

Per the outlook white paper, I am using tasks to manage my projects and next actions.

Some of the next actions in my @computer list cannot be done until I receive confirmation of an agreement, which I am trackling in @waitingFor. So, they really do not belong in my @computer list because the dependency on confirmation first makes them 'undoable' actions. Trouble is, I thought of them, I will do they as soon as I have confirmation, and I want to keep them somewhere. I was thinking of moving them to the body field of the @waitingfor entry until I get confirmation, and then, when they really ARE next actions, moving them to @computer.

How do you handle temporarily undoable next actions?

What you propose is ok, if you check the note of your waiting for before you check the waiting for off, if you see what I mean. A lot of people would put those non-Next Action steps in the note field of the project instead, giving you a single collection point for project notes. For more complicated projects, it's better to keep detail external to your lists.

 

[jknecht]

If the undoable thing is really simple, or the if the project is small enough to not require a formal project plan, I've been known to create items like:

@computer: Do XYZ after I receive info from So-and-so (this is in addition to the @waiting item)

or

@waiting: Receive info from So-and-so; then do XYZ @computer

 

[Andre Kibbe]

I use the word "for" after the deliverable, then follow this with the action it enables.

e.g. "John 3/19: approval of PO for sending to publisher"

The present perfect format ("sending to publisher") isn't exactly the way I'd phrase a next action, but it makes more grammatical sense to me; and since it really isn't a next action anyway, I prefer this kind of phrasing.

But more often than not, if the next action seem obvious when the WF is fulfilled, I leave it off. If it's something that isn't obvious but is important, I personally have no problems putting the dependent action on my project list, since it is, technically, a project. I'll probably know what to do without looking at it anyway, but this acts as a fail safe.

Sometimes the type of response can influence the dependent action, so it's better not to set that action in stone. In those cases, I would just use the Notes field to put down my options, or a project folder in a paper-based system.

 

[jknecht]

Sometimes the type of response can influence the dependent action

Good point! This is one area where the approach I outlined above sort of falls down... it doesn't take all the risks of reality into account.

I might have "@waiting: receive signoff from John; then send package to printers": but if John doesn't sign off, or if he needs me to provide him with more information, then my next action is NOT "send package to printers". So you just have to be flexible if you're going to work this way.

 

[Jamie Elis]

planning in time

I don't know the answer to this issue of depenancies. Let's say you have an action on your list (buy food) that you will do or are waiting for and some dependant actions in your support material (awaiting replies, make food if only 12 are dining, order from caterer if more than 12 are dining). The project has a deadline (July 4th) but there is a large window as to when you will hear from everyone but you need to have enough time set aside for shopping and food preparation if you are coooking it and, if you are ordering it, you need to let the caterer know by a certain date and you need to have reserved sufficient money for that. Do you just put these dates on the calendar as well as your project support materials?

 

[moises]

I don't know the answer to this issue of depenancies. Let's say you have an action on your list (buy food) that you will do or are waiting for and some dependant actions in your support material (awaiting replies, make food if only 12 are dining, order from caterer if more than 12 are dining). The project has a deadline (July 4th) but there is a large window as to when you will hear from everyone but you need to have enough time set aside for shopping and food preparation if you are coooking it and, if you are ordering it, you need to let the caterer know by a certain date and you need to have reserved sufficient money for that. Do you just put these dates on the calendar as well as your project support materials?

Jamie,

Most projects are a lot like this; they are rife with contingency and uncertainty. They cannot be microplanned many days, weeks, or months in advance.

Remember, GTD is flexible, and what and how you will plan a particular project is determined in part by your experience and confidence doing similar projects.

For your example, let's assume that you do not do this kind of entertaining very frequently and you want to document your actions with care.

Let's further assume that the caterer requires 2-weeks notice for events of this size. Let's assume that it takes you less than 2 weeks to plan and purchase food yourself for an affair of 11 or fewer people.

So, the above assumptions tell you that June 20 is the drop-dead date for notifying the caterer of your plans. I'd put that on my project plan and on my calendar.

Now, you know your guests, I don't, but I'd want to give myself a few days before the drop-dead date to draw up the final list of attendees. So, I'd calendar June 16 to list all attendees who have not RSVP'd. This would also go on the project plan. On that day I would call (e-mail, carrier pigeon) all the people on that list to find out what their plans are. This action would also go on the project plan and calendar.

Your actions are contingent and not predetermined. But there are some key dates that would go on my calendar. As I get more information, I would update my project plan. I might want to talk to the caterer even before I know exactly how many guests I will have. I might use this information to help me plan my budgeting.

I might set this project up with a few subprojects: (a) guest list finalized; (b) financial resources accumulated; and (c) menu planned. Some obvious NAs would go in my trusted system. A lot of actions would go on the calendar. Almost everything would go on the project plan. As the event approaches, I would review the project plan daily.

There are so many points on the decision tree where there are a number of possibilities and those possibilities are not known very far in advance. It doesn't make sense to overplan the dependent actions in a project that has a high degree of contingency. But you do need to know your firm deadline dates so that you can get them in your calendar and into your project plan.

 

[kewms]

Your actions are contingent and not predetermined. But there are some key dates that would go on my calendar. As I get more information, I would update my project plan. I might want to talk to the caterer even before I know exactly how many guests I will have. I might use this information to help me plan my budgeting.

Definitely a good idea. Call a caterer just two weeks before a summer weekend event, and they will probably laugh at you. It's much better to find out, well in advance, what *their* deadlines are. Those dates will define the whole project, from setting the menu to getting a firm count on the guest list.

And really, the same is true for any deadline-driven project. Start with the firm deadlines. Work backward from there to set the important milestones, and from there to figure out starting dates. Put all of these in your calendar and/or tickler, so you'll be sure to activate the project when needed. Put the whole list in project support materials, for use during planning sessions and/or weekly reviews.

Good luck,

Katherine

 

[dschaffner]

How do you handle temporarily undoable next actions?

Well, the software I use (lifebalance) allows me to associate next actions with projects:

Project A
Task 1 - phone
Task 2 - waiting for
Task 3 - computer

It also has the ability to select whether the tasks can be done independently or must be done in order. If I choose "in order" then Task 2 doesn't appear in it's context until task 1 is complete.

That said, many of the answers above are more "pure GTD" that will work no matter what software you use.

- Don

 

[ellobogrande]

Pending a next action using Outlook/Palm

I am going to be a stickler about terminology, in order to make this thread clear. A dependent action can never be a next action. Dependent actions go on your "Project Plan." In Outlook, for small- to medium-sized projects it's fine to put the plan in the notes field of the Outlook item.

When the waiting-for is complete, you can move your formerly dependent action, now next action, off of your project plan and into a context list.

I'm an Outlook/Palm user and I handle planned future next actions in the manner described above. But I'd like to add a little tip that I've been using to pend misidentified next actions that I've added to my context lists.

Occasionally, when I begin to do a next action I discover that it wasn't THE next action after all, but it still is a future action. Home projects frequently throw these curves at me--I get started on doing a next action and SURPRISE! I find a hidden problem that I don't have the means to deal with at that moment, I discover that I don't have enough screws, or I need to buy a special tool. So what do I do now?

First, I change the category of the original action to "unfiled" or "none". This removes it from the context list but keeps it in the task list application so that I can reinstate it easily. Second, I identify the true next action and park the reminder in the appropriate place. When I'm able to do the original action, I change its category so it appears in the appropriate context.

I only use the "unfiled" category as a short-term holding area for definite future next actions that I added to my context lists at the wrong time. Therefore it is a VERY short list. I don't put planned future actions there--those go in my project support material. During the weekly review, I prune this list just as I do my other lists.

It's worked really well for me so far.