How to deal with delegated or "waiting for" actions

[bisimpson]

I'm new to GTD and omnifocus on the mac and iPhone. What are some solutions to indicate that I'm waiting for an action? I see how I can do this with a particular project, but not a specific action. Right now I'm considering moving the action to a specific context.

[Brian]

Creating one (or several) contexts that are in the On Hold state and assigning actions to that context is a popular approach.

Here's what I prefer, though: I have contexts for the various folks I work with, so I don't have actions like "email Steve about secret lair". I know who it's for from the context, so I just have an "email about secret lair" action.

Once it's done/delegated, I bump the start date and add "check on " to the action name. The future start date keeps it off my active list until that date rolls back around, at which point it pops back on automatically.

This works for me, without requiring a separate context to hold those actions I'm waiting on. They just stay in the context for the person the task was handed off to.

[keone]

I have a [single] "Waiting For" context setup in my context lists.

So, let's say that I have an action with a "Phone" context. I make that phone call on the prescribed date, but now need to wait for something back from the person I called in order to move the project forward. I briefly write down a summary of the call in the note section under that "Phone" action, and then change the context to "Waiting For" with a due date of, say, three days out.

Now, three days later when I'm in context view I can readily see that a red badge next to my "Waiting For" context indicates that I have one item due. I click on the "Waiting For" context, and there it is, a recap of that phone call of three days ago. Since I haven't yet received whatever it was I was waiting for,

I now have three choices: a) Call that person to follow-up; b) Bump the due date forward another two or three days; or c) Ignore it and let the action sit there in red until I do something with it.

[bisimpson]

This is helpful. Thank you. I have a waiting for context now. This is helpful to flag things for later. Setting it as a context makes it easy on the fly.

For some reason, I have a project labeled "waiting for." Is there any sense in this? If its tagged with the context, then I can leave it with the appropriate project.

[keone]

For some reason, I have a project labeled "waiting for." Is there any sense in this? If its tagged with the context, then I can leave it with the appropriate project.

No, there is no sense in it. By creating a separate project of all of your "Waiting For" actions, I think you were trying to accumulate them together in one area in order to stay on top of them. However, now that you have a "Waiting For" context, let OF accumulate them for you in the context view. That way you can keep all "Waiting For" actions in their respective projects. Just make sure that when in context view, you have the "Project" column visible in the right panel. That is "Project" should be checked in the Columns preferences (VIEW>COLUMNS>PROJECT). That way, you'll readily see the projects that your "Waiting For" actions are linked to.

[Buckaroo]

I'm reading over the GTD and Omnifocus document, and in the "Delegate It" discussion on page 11, it mentions putting the action into the "On Hold" context or "Waiting" context, or even creating a context for the specific person you're waiting for.

What's the difference between these approaches?

Steve

[Kourosh]

It's a matter of preference really. I prefer having a "Waiting for ..." context. In the notes field, I'll add a bit about the conversation and a date and time stamp (Shift-Command-\).

I then have a daily review task to look through the Waiting for ... context.

[Brian]

As Kourosh mentioned, the advantage of the "Waiting For..." approach is that you have one list which contains all your delegated tasks.

What works best for me is to leave the actions assigned to the context of the person I'm waiting on, and then use the start date field to hide those actions until some point down the line when I want to check back with them. Whenever I'm in a conversation with them, I can just bring up their context and run through whatever items I have open.

A side benefit is not needing to move stuff from one context to another and then back again during your reviews. (At the cost of having that list that Kourosh's method gives him, of course.)

[webalstrom]

As Kourosh mentioned, the advantage of the "Waiting For..." approach is that you have one list which contains all your delegated tasks.

What works best for me is to leave the actions assigned to the context of the person I'm waiting on, and then use the start date field to hide those actions until some point down the line when I want to check back with them. Whenever I'm in a conversation with them, I can just bring up their context and run through whatever items I have open.

A side benefit is not needing to move stuff from one context to another and then back again during your reviews. (At the cost of having that list that Kourosh's method gives him, of course.)

I think this is a great example of the need for either multiple contexts (or tags) or being able to set the status of actions, not just projects. If there was an "on hold" or "waiting" status for individual actions, we could keep our context intact but have a clear indication that we are waiting for something on that particular action. Then you could make a perspective of all "on hold" actions" organized by context to see what's waiting from whom.

Eric

[whpalmer4]

Ken has stated that 2.0 will support putting individual actions on hold.

[marcussommer@mac.com]

I have a context PEOPLE with adequate subcontext according to the people I work most with.
YET this I use for actions I do TOWARDS them.
What about items I am waiting for FROM them?
I just might do the same yet THEN I will have to handle 2 separate context menus when I for example meet them:
http://dl.dropbox.com/u/6086817/Screen%20shot%202010-05-04%20at%2018.52.37.png

ANY comment / idea / suggestion most WELCOME

tyia

marcussommer@me.com

[Brian]

Marcus, welcome to the forums! I'm going to move your post to a thread where there was a recent discussion of the approaches you can take for delegated actions. Hope this helps!

[Sprice33647]

Hello everyone. While it initially did not seem natural to assign a context of Waiting on and a person's name to items or projects; I forced myself to use this strategy and I have found it surprisingly effective. With a few clicks I can locate any items I'm waiting to hear back on by my direct reports or other people. The context view shows everything for this individual including things due soon, overdue and just assigned. It makes for very productive face to face or telephone conversation with individuals. It is ideal for one to one review with direct reports.

[bradleychambers]

I have a [single] "Waiting For" context setup in my context lists.

So, let's say that I have an action with a "Phone" context. I make that phone call on the prescribed date, but now need to wait for something back from the person I called in order to move the project forward. I briefly write down a summary of the call in the note section under that "Phone" action, and then change the context to "Waiting For" with a due date of, say, three days out.

Now, three days later when I'm in context view I can readily see that a red badge next to my "Waiting For" context indicates that I have one item due. I click on the "Waiting For" context, and there it is, a recap of that phone call of three days ago. Since I haven't yet received whatever it was I was waiting for,

I now have three choices: a) Call that person to follow-up; b) Bump the due date forward another two or three days; or c) Ignore it and let the action sit there in red until I do something with it.

This is how I am going to deal with it from now on. I hate having overdue actions with a @waiting context. I'll start bumping the date out. One thing I'm struggling with is projects:

Web Design Project
1. Input content
2. Send Sample
3. Upload

That's very basic, but when I lay out a project, I want to have every action with a start and due date. If I have #1 with a due date of tomorrow and #2 a due date of Saturday and #3 with a due date of Sunday, when I can't take action on #1 b/c I've not been sent the content yet, I end up having to bump everything back b/c if I dont, the due dates will be wrong. I am using sequential tasks here. Any advice here?

[whpalmer4]

Use Dan Byler's Defer script: http://bylr.net/files/omnifocus
Defer will change the dates for multiple items simultaneously, and is great for things like adjusting the remainder of a project when a delay strikes.

Also, don't put on more dates than necessary, especially due dates. A start date on each action isn't really necessary in a sequential project unless you are not willing or able to start on an action before the start date.

[bradleychambers]

So basically leave the 2nd action no start/no due and when I complete the first action, decide when it starts/is due? Wow, that makes a ton of sense and I really dont know why I never thought of that

[Schnack]

Has anyone come up with an easy method of emailing OF tasks with notes to colleagues? While I have a good method of tracking delegated tasks within OF, it would be a huge timesaver to be able to export an individual OF entry (with notes) to my email client (or any kind of text/report) and send it straight to the colleague that I need to chase for an update.

Thanks

[Brian]

Schnack, one of our support ninjas recently created something which may be helpful to you. He put together a web form (http://twitter.com/dmessent/status/2569990364463104) which uses Javascript to make a clickable "add this action to OmniFocus" link you can email to other folks.

Hope that helps!

[Omni Clint]

Ken has stated that 2.0 will support putting individual actions on hold.

YES! I was just coming to post about strategies for "waiting for..." and saw this sticky thread. The "Waiting" context is a good workaround but actually being able to just put individual actions "on hold" with a perspective/view for everything "on hold" grouped by project is ideal in my opinion.

Great to see this will come one day.

I think the strategy people have stated about different context per-person they are waiting on is interesting but I work for an 18,000 person company and unfortunately I wait for a TON of different people. I think it would make my omnifocus far too complex.

Ultimately, i wish putting an individual action "on hold" would also bump the due date a week (with a global preference to set what that bump is). That would be awesome and convenient enough to use regularly.

[canadianchris]

While I'm not sure that this aligns with the GTD methodology, the way Things has implemented meta-tags is really helpful in this regard. I work in Omnifocus because the cloud sync is functionality I need desperately for my workflow, but that's a great example of how this can work. During my capture sessions or throughout the day as I capture todos, it's incredibly useful to attach to a context - a large deliverable/project for example - and also tag with a resource. Then when I'm chatting with the resource I can bring up projects and filter by tag or filter by tag and view by project, etc. I would love to see this in OF

[nicoledb]

I have a context PEOPLE with adequate subcontext according to the people I work most with.
YET this I use for actions I do TOWARDS them.
What about items I am waiting for FROM them?
I just might do the same yet THEN I will have to handle 2 separate context menus when I for example meet them:
http://dl.dropbox.com/u/6086817/Screen%20shot%202010-05-04%20at%2018.52.37.png

ANY comment / idea / suggestion most WELCOME

tyia

marcussommer@me.com

Your example doesn't seem to work anymore in the current version of OF (1.10.4). When I try to recreate a similar hierarchy, and put the top context On Hold, that's exactly what happens: the top context is put On Hold, but not the hierarchy of contexts below that. That's not what I expect to be happening, I would expect all contexts below the top one to inherit the property 'On Hold'. Is this a bug maybe?