[Betsy]

This is perfect for some of what I do. I prepare various packages of documents. I get my part done, and I have to wait for the next piece of information from someone else. Or I finish it, and hand it over to someone to approve and sign off on, and I wait until they give it back to continue my part.

Perfect! I just added a bunch of actions with @Waiting contexts to my projects for these situations.

[curt.clifton]

To avoid losing my flow, I often just use QuickEntry to toss a new Waiting For in the inbox after I send an email or leave a voice mail. I empty my OF inbox a couple of times a day, and will do some project organizing then. If I happen to see an action in my context list that I know I can't do immediately, then I'll use the Cmd-Opt-R shortcut to jump to it and add a new WF above the should-be-blocked action. Sometimes doing more than that leads me into over-planning.

[omnibob]

A slightly different question than what this thread is talking about, but related. It's also partly about the granularity of actions. I'm trying to establish a method for implementing waiting fors.

Broken down to physical actions:

o Email John Smith for xzy survey. WF: John Smith's reply.

o Review xyz survey results and write analysis.

--

Using just one action; assuming the email to John Smith occured without entering it first as a separate action:

o Review xyz survey results and write analysis. WF: John Smith reply to my email.

How are others handling it?

Bob

[brianogilvie]

Originally Posted by omnibob

Using just one action; assuming the email to John Smith occured without entering it first as a separate action:

o Review xyz survey results and write analysis. WF: John Smith reply to my email.

How are others handling it?

I usually handle it as you indicate in your second example. I'll often put the thing I am waiting for in the action note and then drag the action into my Waiting context. Sometimes, if I really can't move at all on the project until I get a response, I'll toggle the project from parallel to sequential (which can be done from the inspector, without switching to planning mode), to make the remaining actions unavailable. (But remember to toggle it back when appropriate!)

[kingsinger]

I try to discipline myself to break it into separate actions, entered separately in their appropriate contexts. At least based on my reading of GTD, that's the preferred approach. Also, as brianogilvie indicates, if you do this and set the project (or sub-project) to sequential, it effectively blocks the next action after that until you confirm that you received what you were waiting for.

To me, that's a great check, because it encourages me to look just at the waiting for context and clears my head of any other aspect of the project that is dependent on that action until it has been accomplished.

Typically, I try to use OF to establish chains of actions. Some of my work happens off repeated templates. To the extent possible, I try to construct similar sorts structures with other projects.

Judicious use of the waiting for context, and mixes of parallel and sequential sub-projects make it possible to create some nifty dependencies within a larger project. Indeed, the need to use a waiting for to block further action on a part of project is often what gets me to create a sequential sub-project branch within an otherwise paralell project.

At first I didn't get the way waiting for, parallel and sequential interrelate. But now that it makes more sense, it's great and very helpful for building the sorts chains of events I referenced above.

Part of the focusing thing is not having stuff visible that isn't relevant right now. At least in my experience, if you do it the way I describe above, OF does a better job making this happen in an automated and predictable way.

Ultimately, OF is specialized database, and in every database I've ever used, its utility is only as good as the quality of the data entry. While it's not explicit, your implicit question goes to what data structure you are going to use in this particular database. Will you put the first and last name in one field? Or put them into two separate fields?

As in good relational database design, GTD generally seems to encourage people to at least consider beaking things down into more granualar units (although not slavishly so).

Certainly, it can take a bit more time to do this. But it also encourages thinking a bit more about the specifics of the project, and I think that over the long haul it makes the information more useful, and allows one to focus more right now with less distraction on side stuff.

Ideally, I'd rather not be dragging the same action around to different contexts as the project progresses. If I find myself doing that, it seems to me it's a sign that there's more than one action embedded in the present item, and I should probably take a second to think about that, break it down, and set the individual actions out in project mode. That way, it's easy to focus on each element separately.

It's not that I can't "do the math in my head" as far as this goes and keep track of those things as I move one compound action around. But doing that takes mental overhead and creates distractions. Seems like the point of GTD is to try and eliminate those.

That being said, I know this approach may be overkill sometimes and not so practical. But as with any discipline, it takes a bit of work to establish good habits (I've certainly got a way to myself on that front <g>). On the other hand, once you do, and they become second nature, then a lot of things start to fall into place.

KS