[SpiralOcean]

The problem of waiting for items...

what is the problem of waiting for?

--i want to review waiting for items, and not see ones that I cannot accesss right now. Much like a tickler file. I only want to see items that I need to see.

--if a waiting for item needs action, i want to write the action down, and the waiting for item disapears from the waiting for list. If there is no response from the action, I want to be reminded again. Example...
Waiting for email from John about proposal
My next action is in the email place...
email john about status of proposal
The waiting for item should not appear in my waiting for list
once the email is sent and checked off, the waiting for item should appear again in a couple of days reminding me that I am waiting for an email from John.

--the problem is... when a waiting for item comes in... how do i search for it? It's not in the waiting for list, because I don't need to be reminded of it right now. I could perform a search for it, find it in the outline and mark it as complete. If using a tickler file, and one of the tickler file items comes in but the item is in the folder for a week from now, how do you easily find it?

--when i see a waiting for item, there are three responses,
take action on it, or
give the waiting for item more time, or
the waiting for item is complete and no longer needs waiting for.

[SpiralOcean]

Sometimes, I am waiting for something to happen in one project before another project can be started:

example:
install cool software
-waiting to install server os

And my other project is
Install server OS
-purchase software
-install server software

It would be cool if I could somehow tie in one waiting for to the completing of another task. Instead of looking at my waiting for list to see the task, waiting to install server os and check it off, when the Install server OS software project is complete, the waiting to install server OS is automatically completed and I can move forward on my project.

[Paul]

I think you are trying to make your projects and contexts too fine-grained. That might be helpful in a project management system that is used for tracking & reporting status across an organization, but for managing your own time and attention, it is creating busy-work.

'Waiting for' is for listing open requests or delegations that you've made to other people. If you plan to send a follow-up email, you are still "waiting for"; if you send a follow-up email, you are still "waiting for." You don't have to move some status marker around to keep track of that.

And in your software install example, you have considered separate tasks which need to happen sequentially to be separate projects, and then wished to have a mechanism for your system to recognize when the next 'project' becomes actionable. Instead, keep it simple:

Install Software project:
-purchase server software (Next Action)
-install server software
-install cool software

[SpiralOcean]

Originally Posted by Paul

I think you are trying to make your projects and contexts too fine-grained. That might be helpful in a project management system that is used for tracking & reporting status across an organization, but for managing your own time and attention, it is creating busy-work.

I don't agree with you on this Paul.

The purpose of GTD is to define the next action. An example from the book...
If you have to get new tires for the car, the next action is not,
get new tires for the car
the next action is not
call tire store
the next action is
get phone number for tire store

With waiting for, the next action is not: it's on a waiting for list.

The next action is one of two things:
1. Do some action to get it off waiting for (make a phone call, send an email)
2. Delay the waiting for until you are ready to decide what action to take.

When you have multiple vendors, with different projects, I don't want to use the brain power to go down a list and think...
when was the last time i contacted them
how do i contact them
do i need to contact them

I want to go down a list and just crank widgets... just crank through a list.

The point of the context lists is for them to really be next actions, so you go down a list and just make phone calls, or send emails, or paint the house. Not that you go down a list and think, hmm... do i need to do something about this?

The point of GTD is you do your thinking in the planning, and your action in the actions.

Originally Posted by Paul

'Waiting for' is for listing open requests or delegations that you've made to other people. If you plan to send a follow-up email, you are still "waiting for"; if you send a follow-up email, you are still "waiting for." You don't have to move some status marker around to keep track of that.

I agree that Waiting for is for listing open requests. The way I am visualizing the software is, I don't want to see waiting for items that I can't do anything about. I want to go through a waiting for list as if it were a tickler file, only showing me what needs to be brought to my attention when it needs to be brought to my attention.

If I get to a waiting for item that needs action, I should create an action in the appropriate list to get the waiting for item off the list. Make a phone call, or send an email, or have a meeting.

Originally Posted by Paul

And in your software install example, you have considered separate tasks which need to happen sequentially to be separate projects, and then wished to have a mechanism for your system to recognize when the next 'project' becomes actionable. Instead, keep it simple:

Install Software project:
-purchase server software (Next Action)
-install server software
-install cool software

The software example was just an example. I have projects that are more complex than that, and one part of a project to be completed, is relying on the completing on part of another project.

[Paul]

Hi Spiral, You're right, we do disagree a little on the purpose of GTD. That might be a bigger discussion, so I'll try to avoid it. Hopefully we at least agree that making lists is a means and not the goal of GTD.

I do agree that Get the phone number is the next action, but for me it's a waste of time to write it down in the project list, since getting the number is almost as quick as planning to get the number. GTD's two-minute guideline, Al Secunda's 15-second principle, and common sense all lead to this.

Ethan's kGTD answer to your wanting not to see all your waiting-fors is to put start dates on them. Then they are not actionable and don't show in the context list until the start date. I think that's a simple, practical approach.

And of course your example was just an example. My answer was just an example of the principle as I see it: if there's a dependency, it's just a sequence. If you really need to document those to get them out of your head, you can add a "Start install-cool-software" task at the end of your install-Server-OS project. If your dependencies are really more complicated than that, you would need project mgt software that maps the graph of dependencies -- lists simply won't cut it in that case.

Ethan's original workflow for kGTD assumed that you would do daily reviews of active projects, in part to resequence project steps because things don't always happen as you planned them. I've found this to be very useful even if it isn't fundamentalist GTD. Unfotunately, Ethan's writing about this is gone from the website, it must have been part of the prior version's write-up.

[SpiralOcean]

Originally Posted by Paul

I do agree that Get the phone number is the next action, but for me it's a waste of time to write it down in the project list, since getting the number is almost as quick as planning to get the number.

Agreed on that. Especially if you use LaunchBar or Quicksilver. LaunchBar you can select the name, and hit a keystroke to paste the name & number into your system. Quicksilver is a couple more keystrokes but it is still quick. Not to mention, most of my calls are made by looking them up from my cell phone.

The only time I'll need to look up a number is a place I've never been and need to look it up on the internet.

Originally Posted by Paul

Ethan's kGTD answer to your wanting not to see all your waiting-fors is to put start dates on them. Then they are not actionable and don't show in the context list until the start date. I think that's a simple, practical approach.

Now back to the "problem" of waiting for.

If you have 20 waiting for items, and one of them comes in... let's say a call from vendor B. How do you find it quickly?
If you go to your waiting for list, you can't see it. The item isn't set to appear for another week.

You could search for it in the outline, but what if you have multiple projects from that one vendor?

Originally Posted by Paul

And of course your example was just an example. My answer was just an example of the principle as I see it: if there's a dependency, it's just a sequence. If you really need to document those to get them out of your head, you can add a "Start install-cool-software" task at the end of your install-Server-OS project. If your dependencies are really more complicated than that, you would need project management software that maps the graph of dependencies -- lists simply won't cut it in that case.

This is one thing I run into often, When does a project become it's own separate project. When one project depends on another part of another project to be completed first, do I move the entire project into the first project? It becomes extremely unwieldy and the projects quickly loose their boundaries.

I'm not sure why you are offering me solutions that I have already tried in this post. I'm not asking for help here, I'm trying to brainstorm on something I see as a weak point in GTD type software.

My hope is the OmniFocus software will develop software that will be a clear cut system. Not one that is extremely flexible for anyone to put their own system into. All the other GTD type software out there does that already, offering their users 'suggestions' for 'workarounds' to make the software work for them.

OmniFocus needs to be one thing... not try to be everything to everyone. But in being one thing, they need to think about all the issues that come up when working with a GTD system.

For example...
what if a piece of software had a way to have repeating appointments, but didn't think about all the different ways to repeat an appointment and only provided a user with... repeat daily, weekly, monthly.

Users would write in saying... I want something to repeat on Monday, Wed Fri.

And the software company would say, well... you can't do that with our software, here is the workaround. Create three repeating appointments that repeat every week.

My point is... the software company should have thought of that and created a way to repeat an appointment every week on whatever days they wanted.

kGTD is an inventive piece of software... especially because it used applescripts to tap into the outline. But it's far from unique in what it did. There are at least 5 other applications out there that have been doing the same thing for longer than kGTD.

But for some reason, all these applications fall short. Why is it the essence of GTD seems to fall through the cracks? GTD was designed on pieces of paper and started as lists of items on paper in different folders labeled with contexts. I don't want to go back to that. The essence of GTD is a good one.

But the computer can offer so much more. Why is it people are so afraid of moving forward? I guess one fear is the tool will become unwieldy and complex. It's one of my fears as well. But I still have the hope that the software can be developed elegantly, meeting the needs of the user without becoming burdensome.

And why is it, so many of these software companies that are so close to a GTD system, do not embrace the GTD system? I still haven't found one that embraces it. It's like they are afraid of people thinking they are a GTD application. And yet people are using GTD in their software.

If an application is too simple you become like basecamp, and it takes more work for a user to enter items into the software and be reminded what the item was for. Thus taxing the user.

If an application is too complex the user is entering too many fields or forced to use the mouse for every data entry. Thus taxing the user.

The purpose of GTD is to think, plan, and then do... crank on items. Not have to look at a list of 100 items and think... okay, what does this relate to? What do I have to do next with this item. Should this item be in this context?

Simple is good, but we do not strive for simplicity. Because simplicity is as much work as complex... we strive for

Elegance...
pleasingly ingenious and simple : the grand unified theory is compact and elegant in mathematical terms.