GTD If/Then Questions/Examples

[David_H]

I am refining my GTD methods and would like input on a number of scenarios. Rather than list a bunch of them, I thought I'd start with one and move on from there if necessary. David Allen defines work as:

Collect
Process
Do

So here is a common scenario.

1. I take a telephone call from a Client. We discuss an entire host of issues and I have a full page of notes on the computer by the time I am done. Some of the notes will end up being entered in our CRM program as a record. Some of them will be converted into tasks. I hang up the phone and I have exactly 60 seconds to do something with these notes before I must quickly move on to another scheduled task. So at this moment what is/do I do with this page of notes?

A. Did I already "collect" by taking the phone call and notes? Or am I now "collecting" by dragging the notes it into a folder named "inbox" (or something similar) so that it is something "collected and waiting for processing"? And then I process it later when I have time?
B. It does not seem like I have time to "process it". So it seems to me it is either in the "collect" or "do" stage?
C. Processing seems to me to often be a task in and of itself. So do I create a task named "process client meeting notes?" in which case the notes are now actually at the "do" state?

Thanks and I much appreciate everyone's input.

[mcogilvie]

1. Your notes go into an in box recognized as such by you, which you process regularly (at least daily in most circumstances). Then you are entitled to say that you have (A) collected it. Because you have collected but not processed, guess where you are with your notes: processing (B). The answer to (C) is: probably not. Your in boxes will accumulate stuff, and you will take the time (on the order of an hour a day for many people) to process. If an item is urgent or very large, then you may choose to process that item by itself, e.g., President Obama has offered you a government post, and you have 24 hours to accept or not. Once your notes are processed, they might be filed or thrown away. You don't do notes, you do next actions. Hope this helps.

[MarinaMartin]

Do you not have access to the CRM program? I would enter the notes directly into the CRM while you are on the phone, and then self-assign a task to "Identify Next Actions" with a due date of tomorrow.

This is if you truly only have 60 seconds. The ideal scenario would give you 2-3 minutes post-call to review the notes and identify all of the next steps, and then add those tasks to your regular system.

If you are a salesperson with an auto-call system or similar workflow so you really can't spend more than 60 seconds after the call before the next one, I encourage you to discuss this with your manager. It's much faster to process the notes into tasks while the conversation is fresh on your mind, and that leads to better productivity overall. I've consulted with a number of call center/sales environments and there is measurable improvement when each person can take up to three minutes after a call to clean up the notes and identify tasks.

Marina

[David_H]

1. Your notes go into an in box recognized as such by you, which you process regularly (at least daily in most circumstances). Then you are entitled to say that you have (A) collected it. Because you have collected but not processed, guess where you are with your notes: processing (B). The answer to (C) is: probably not. Your in boxes will accumulate stuff, and you will take the time (on the order of an hour a day for many people) to process. If an item is urgent or very large, then you may choose to process that item by itself, e.g., President Obama has offered you a government post, and you have 24 hours to accept or not. Once your notes are processed, they might be filed or thrown away. You don't do notes, you do next actions. Hope this helps.
Thanks. Let me play devils advocate, which if I do a lot in this thread is not because I am discounting peoples opinions, but to help me better understand how different people handle these issues.

If someone sends me an email, let's say an email that consists of a large body of meeting notes that need to be reviewed and acted on, isn't the GTD rule that if it is going to take more than 2 minutes to deal with that Email, that I am supposed to delegate/defer that email into a task? In fact, on the advanced GTD diagram is shows that processing an item should take between 10-40 seconds.

So in this instance, once I've created those discussion notes and I've thrown them into my inbox, it seems to me they are no different than that email. And the moment I process them and realize it's going to take a lot more than 10-40 seconds to do so, isn't the next step to simply make out a task that says "process client notes"? Because reading through and processing the types of notes I am talking about is not going to take 10-40 seconds, it's more likely going to take 10-40 minutes.

[dschaffner]

I hang up the phone and I have exactly 60 seconds to do something with these notes before I must quickly move on to another scheduled task. So at this moment what is/do I do with this page of notes?

Throw them in your inbox. Now you have 59 more seconds to do something else :)

Later, when you PROCESS your inbox, you can parse the tasks, CRM items etc. into your system.

You don't need a task called "process notes from XYZ phone call" (having the inbox takes are of that), but you might want to have a recurring daily task call "process inbox to zero".

- Don

[TesTeq]

If someone sends me an email, let's say an email that consists of a large body of meeting notes that need to be reviewed and acted on, isn't the GTD rule that if it is going to take more than 2 minutes to deal with that Email, that I am supposed to delegate/defer that email into a task? In fact, on the advanced GTD diagram is shows that processing an item should take between 10-40 seconds.

On the other hand if the e-mail contains the following message:

"FIRE ALARM!"

will you calculate the time needed for evacuation and then decide what to do - according to the result of this calculation (if it takes more than 2 minutes you will defer the action? :-) )?

My point is - your action depends on the e-mail contents - GTD rules should be used as hints only.

[mcogilvie]

If someone sends me an email, let's say an email that consists of a large body of meeting notes that need to be reviewed and acted on, isn't the GTD rule that if it is going to take more than 2 minutes to deal with that Email, that I am supposed to delegate/defer that email into a task? In fact, on the advanced GTD diagram is shows that processing an item should take between 10-40 seconds.

So in this instance, once I've created those discussion notes and I've thrown them into my inbox, it seems to me they are no different than that email. And the moment I process them and realize it's going to take a lot more than 10-40 seconds to do so, isn't the next step to simply make out a task that says "process client notes"? Because reading through and processing the types of notes I am talking about is not going to take 10-40 seconds, it's more likely going to take 10-40 minutes.

Let me begin by saying that if you have meeting notes that take 40 minutes to process, then either a) you are recording the minutes, b) you have really long meetings, or c) your meetings are a lot more productive than the ones I'm in. Let's suppose you have a meeting about a project, and you have a lot of action items from it. If you have the time to do so, it's perfectly ok to put your notes in a project folder, and put a next action to process them on a list. But you must do both! If you start putting potential action items into reference files without the habit of writing down a next action to review those items, you will sooner rather than later let some things slip by. You could also schedule time to review those notes on your calendar, perhaps with others. However, when things are busy, the inbox is the safest way to go.

p.s. I think the Advanced Workflow Diagram was originally contributed by someone outside Davidco. As with all of GTD, it's not sacred, and Your Mileage May Vary.

[David_H]

Thanks guys (and gals :)). To clarify, my mention of the 10-40- second rule was merely meant to be illustrative, trust me, I'll modify anything and everything to meet my needs.

mcogilvie, I think you summed up my issues well. I often work on very large projects. I don't have lots of meetings for meetings sake, but when I do have project meetings or calls, it's not unusual that at the end of the call I have a large list items that need to be addressed/processed. And it seems to me that when the processing is going to take a fair amount of time, let's say 15-30 minutes, that that is when I might want to create a next action for it.

However in the end, as I am looking at this, I honestly don't think it matters that much where I put it ("in" or "do") as long as it's part of the trusted workflow and going to be addressed.

[jesig]

David, if I may be forward, it seems to me like you're confusing the GTD "process" step with having fully dispatched with the notes from your call or meeting. Once you've decided that you need to deal with those notes, put the appropriate reminder to do so in your system and put the notes themselves in a place where you can get them easily, then you're done with "process" in the GTD sense. That's the 10-40 second part.

Per your 10-40 minute problem of actually wading through the notes, might I also suggest that it would be beneficial to your time in dealing fully with these if you make some distinctions on the front end of your notetaking? If most of your calls generate "things to enter into CRM" and "next actions," can you take notes in such a way that these two things are (mostly) separated from the outset? I'm an academic, so I am entirely unfamiliar with how call centers work, but if your notetaking method is not prescribed by your employer, it might make sense to figure out a way distinguish the different types of data in your notes as it comes so that when you go to review them, it's easier to separate NAs from CRM input from other stuff.


However in the end, as I am looking at this, I honestly don't think it matters that much where I put it ("in" or "do") as long as it's part of the trusted workflow and going to be addressed.

And of course, that's the point of everything right there. :D

[David_H]

jesig,

Thanks for your response. I will respond later but I just want to clarify since you are the second person that has said it that I do not work for a call center and my employer is me, I own a business that manages fairly large projects (large of course is in the eye of the beholder, using time as an example they typically span 1-3 years). I mentioned being on the phone earlier and then having 60 seconds to jump to another meeting and I guess someone concluded from that I work in a call center. If i worked in a call center I would shoot myself :mrgreen: and beside I could be wrong, but I think most people who work in a call center have everything sooo structured for them that they do not have to worry about GTD.

[ellobogrande]

My rule of thumb for processing long e-mails or pages of notes:

If more than two minutes pass while I'm answering the questions in the processing workflow on a particular item, I stop processing it. By default my next action is to read and review the item when I have discretionary time.

I find that when I'm processing my inboxes to zero, if I spend more 2-3 minutes on a particular item I lose momentum, get side tracked, or run out of time and have to leave my inbox partially unprocessed (for now).

I sometimes print out long e-mails or documents and add them to my "Read & Review" folder in my briefcase. It's easier to make notes on a paper article, and I can take it anywhere (the dentist's office, the lunch room, the mens room, etc).

[David_H]

I find that when I'm processing my inboxes to zero, I find that if I spend more 2-3 minutes on a particular item I lose momentum, get side tracked, or run out of time and have to leave my inbox partially unprocessed (for now).

BINGO! That is me and why I started this thread. I found myself leaving things in my inbox that required too much time to process.

[Brent]

There's nothing wrong with filing an unprocessed email and creating a Next Action to process it.

[David_H]

There's nothing wrong with filing an unprocessed email and creating a Next Action to process it.
Are you sure it's not a sin or anything :D? I won't go to GTD hell :mrgreen:?

[dschaffner]

Are you sure it's not a sin or anything :D? I won't go to GTD hell :mrgreen:?

Uh. No. That's GTD.

[sdann]

BINGO! That is me and why I started this thread. I found myself leaving things in my inbox that required too much time to process.

Don't put things back into your inbox. If you can't take care of it then, make a decision about the next action, write it down and move on. Or else, your inbox will be filled with items which you have picked up, quickly reviewed, but not made a decision on.

[cornell]

I wrote about this a while ago, and covered most of the excellent issues you discovered: Dealing With Meeting Notes - GTD To The Rescue!
http://matthewcornell.org/blog/2005/09/dealing-with-meeting-notes-gtd-to.html

Cheers!

[David_H]

There's nothing wrong with filing an unprocessed email and creating a Next Action to process it.

BTW, following up on this thread, this is exactly what I have started to do and it's working beautifully for me (and I see from Cornell's article he does something similar). In fact, for certain tasks I sometimes create a task for "deciding on the next action".

Now obviously I only do this for some tasks, otherwise one would just end up with a huge task list consisting of "decide on next action". BUT it's an excellent method for dealing with the small number of tasks where the end goal is known but the next action is not clear because more input or research or answers are required. So instead of polluting my inbox with them I realize that the next action in such instances truly is to spend some time "deciding on the next action".

[sdann]

for certain tasks I sometimes create a task for "deciding on the next action".


I fully agree. Making decisions, identifying, NPM activities, brainstorming, reviewing, etc. all move our system forward. Thought-based actions often take more than 2 minutes, "deciding on the next action" included.

[Jon Walthour]

BUT it's an excellent method for dealing with the small number of tasks where the end goal is known but the next action is not clear because more input or research or answers are required. So instead of polluting my inbox with them I realize that the next action in such instances truly is to spend some time "deciding on the next action".

I follow DA's advice on this and put that decision-making down as a Next Action called "R&D".

[clango]

Don't put things back into your inbox. If you can't take care of it then, make a decision about the next action, write it down and move on. Or else, your inbox will be filled with items which you have picked up, quickly reviewed, but not made a decision on.

How often can you take a decision so quickly?
How can you try to avoid to procastinate...something like Print it...could be a procastination. Take time to decide

In other terms how do you approach, what's the logic you use for complex emails with several included NA like the chinese boxes?

...and what do you do, when you realize that if happen something after that the NA will be...? Do you consider them as a @SOMEDAY?

[Gardener]

How often can you take a decision so quickly?
How can you try to avoid to procastinate...something like Print it...could be a procastination. Take time to decide

In other terms how do you approach, what's the logic you use for complex emails with several included NA like the chinese boxes?

...and what do you do, when you realize that if happen something after that the NA will be...? Do you consider them as a @SOMEDAY?

Myself, I don't worry about avoiding procrastination. In fact, to some extent I embrace GTD's support of structured procrastination. With GTD, I can come up with a little, un-scarey Next Action, and I know that I'll get to that Next Action, I'll do it, and I'll have to design another Next Action. And eventually I'll probably actually do something. So the project is started down its track, even if it's going very, very slowly. I combat procrastination by forcing myself to continue to write and execute Actions, not by trying to make sure that those Actions are productive.

So if my Next Action is Print It, and that's procrastination, so be it. I'll get to the Action, I'll print the thing, and then I'll need to write another Action. That will probably be Read It. Possible procrastination again. I'll get it read, and then there's a moderate chance that there's _some_ truly productive Next Action, however tiny, that I could then write. If I'm deeply lost? I'll write a Next Action telling me to write a Next Action.

On a set of notes that are full of nested Actions, I'll convert as many as I can into Actions, crossing them off from notes on paper or deleting them from a copy of electronic notes, as I go. The ones with nested Actions may end up being separate projects on their own, with placeholders left in the original project.

If I can't figure out how to transform some of the notes into Actions, I may write an Action to figure out the rest, and file the unprocessed notes somewhere that I can find them again. (I'll usually record the location in the Action itself.)

I'm not sure that I follow your last question. If you're asking, what do you do if you can see past the Next Action - in my case, I just write as many Actions as are in my head, until they no longer want to come out. Then I re-order them into a logical order of execution if necessary - or, if some of them are so big that they will require several Actions of their own, I may make them into projects.

Gardener

[clango]

...and what do you do, when you realize that if happen something after that the NA will be...? Do you consider them as a @SOMEDAY?

@Gardener Thank you so much. I really appreciate your open answers. I see your answers and my questions as the possibility to go more in deep.

I think you are right.

If a NA doesn't come out naturally...maybe there is a reason....so it's reasonable to take a step forward even if very short.

About the last questions, I think it could come out when I delegate something.

Example....When Alain will present the business plan of the new product A, I need to do this and that.

So in my outlook tasks I could write:
@WAITING FOR
Alain 31/03/09 Business plan A

@ .......where??
When Business plan A is presented by Alain do this
When Business plan A is presented by Alain do that

[Gardener]

About the last questions, I think it could come out when I delegate something.

Example....When Alain will present the business plan of the new product A, I need to do this and that.

So in my outlook tasks I could write:
@WAITING FOR
Alain 31/03/09 Business plan A

@ .......where??
When Business plan A is presented by Alain do this
When Business plan A is presented by Alain do that

Hmmm. I might have to know more about the situation, to figure out what I'd do about this.

I guess that one question is, what's the goal of Alain's presentation? Is it to get the business plan approved by upper management?

in that case, I could imagine an earlier project:

Project: Implement New Business Plan
Action: (A whole bunch of completed actions that got the business plan written.)
Action: Open and complete Get Business Plan Approved project.
Action: (A whole bunch of future actions that you anticipate doing once the plan is approved. With something as big as a business plan, these will probably be actions that trigger new projects.)

Project: Get Business Plan Approved
Action: Complete peer review of business plan. (A past action.)
Action: Polish business plan for submittal to Alain. (A past action.)
Action: (Start date 3/31) Follow up on status of Alain's presentation.
Action: (Repeating, weekly) Follow up on upper management response to Alain's presentation.
Action: (At this point you may be almost done, or you may create and work a bunch of tasks resulting from upper management changes to the plan. In fact, you may even create new projects with placeholders, just like the placeholder above.)
Action: When business plan is approved by upper management, close this and return to Implement New Business Plan project. (This is the last action for the project, but it was probably defined as soon as this project was created. It's just a placeholder, in case you forgot where you were when you branched out to this project.)

Gardener

[abhay]

I fully agree. Making decisions, identifying, NPM activities, brainstorming, reviewing, etc. all move our system forward. Thought-based actions often take more than 2 minutes, "deciding on the next action" included.

To add to what sdann said: It is a good idea to defer "deciding on the next action", but I would refrain from writing that action down as "decide the next action". In such situations, it usually means that one of the phases of the natural planning model is not yet clear. Now that can be quickly identified. The next actions are obvious if project notes are organized. Is it ready? If not, organize project ideas is the action. But to organize, one needs ideas. So has brainstorming/webstorming been done? Ideas won't come out in a flow unless the outcome picture is not clear. And the picture will not be clear if the purpose of this stuff is not clear.

It is usually easy to identify where one is stuck up, in case the next action is not clear. Then the next action is work that phase of natural planning model. So depending upon where one is, the next actions would look like one of these:
Clarify the purpose of this
Visualize the the outcome of this
Brainstorm / websearch / [find information otherwise] re this
Organize the ideas re this

More details in GTD, chapter 3 and 10.

[clango]

Hmmm. I might have to know more about the situation, to figure out what I'd do about this.

I'm thinking to an easier situation. For example applyng the two minutes rule, you send me an email and I answer to you.

In my answer, for example, I propose you to have a meeting together (for the first time in our life!) for something.

Suddenly it come out some ideas....if he 'll accept this meeting I need to organize it in Boston, I need to use music to relax the environment.....

[Gardener]

In my answer, for example, I propose you to have a meeting together (for the first time in our life!) for something.

Suddenly it come out some ideas....if he 'll accept this meeting I need to organize it in Boston, I need to use music to relax the environment.....

I'd probably go ahead and create a project for the meeting. The first action would be a repeating "Follow up with (whoever) about meeting." The Boston location, music, etc., would be subsequent actions in that project. If he refuses the meeting, then I just cancel the project and delete those actions.

Gardener

[clango]

Myself, I don't worry about avoiding procrastination. In fact, to some extent I embrace GTD's support of structured procrastination. With GTD, I can come up with a little, un-scarey Next Action, and I know that I'll get to that Next Action, I'll do it, and I'll have to design another Next Action. And eventually I'll probably actually do something. So the project is started down its track, even if it's going very, very slowly. I combat procrastination by forcing myself to continue to write and execute Actions, not by trying to make sure that those Actions are productive.

I'm thinking to what we shared in these days....and what you wrote. In my situation what you wrote is an important reason why I don't have my inbox always at zero.

Sometimes I remain a little blocked to think which is the more convenient NA, but now I realize, thanks to this thread, that is a mistake. It could be enough put it in the appropriate list, print it as we said, do something even if a little step!

Thanks. :D