View Single Post
Actually, there's another place where I do frequently use something like an On Hold Waiting For - when a project is dependent on another project.

So, let's say that I'm writing a better set of, oh, zip code lookup code. I want to install this code in every application in which I have zip code lookups. It's going to require a little customization for each application.

So that's a bunch of projects -

Write Zipcode Engine
Install Zipcode Engine Into Widget Application
Install Zipcode Engine Into Gadget Application

and so on. Until I complete the first project, I can't even start on the other projects, so I want them to be on hold and usually hidden from me. But I do create the projects, because I might have thoughts about them ("Configure Zipcode Engine to support Canadian postal codes in Widget.") that I want to get out of my head and sorted into a project. Now, I could make all of these projects part of one larger project, but I don't like that - I like my projects smaller than that.

So "Install Zipcode Engine Into Widget Project" has a Next Action of "Waiting for Write Zipcode Engine Project" and a context of HOLDINGFOR, which is an On Hold context. It's going to sit there, idle, until I write that Zipcode Engine.

And the "Write Zipcode Engine" project has a final action of "Wake up Install Zipcode Engine Into Widget Project". Other actions will come and go, but I keep that action at the bottom. And I keep a similar action at the bottom of the first "Install" project, and so on in a waterfall.

Again, I'm not sure if this is proper GTD, but it is another thing that I use On Hold for. If it works, then the completed project will trigger me to wake the On Hold project. If that falls through, then I'll eventually notice the sleeping project in a Review.