Managing duplicated actions

[apgold]

Can anyone offer some insight or best practices on how to manage the case where multiple, nearly duplicate, actions get entered for the same topic? For instance, when processing my Inbox, a next action very well may be that it will take longer than two minutes just to read the thread and determine what I want to do. Therefore, I will file that in my Read/Review folder (so my next action is to read the item). Then, before I get around to processing that particlar Read/Review item, I get another email on the same topic (perhaps a few days later, so I don't recall that I've already filed a version of this in Read/Review), which, since it will take longer than two minutes, again goes into Read/Review. Then, when I get to processing Read/Review, I find several duplicates at different points in the email thread. If I had waited for multiple messages to queue up in my Inbox (which I do not want to do), I would have been able to sort by conversation and delete all the older versions of the thread prior to entering it into Read/Review. Obviously that's not ideal either, so I'm asking if anyone has had similar experiences and some best practice thoughts on how to manage. Thanks much.

 

[kewms]

I'm not sure I see the issue....

As soon as you discover a duplicate on your NA list, just delete it.

Having duplicate items in your Read/Review folder sounds like an email software issue, not a GTD issue. One answer might be to create a topical subfolder under Read/Review, and then write an email filter to send all related messages to that subfolder for later handling.

Katherine

 

[apgold]

Thanks for the reply Katherine, but the issue is that mail threads are not duplicates of one another ... they start from a common base but then diverge as various people add comments. So, the question I have around "best practices" centers around handling the following scenario:

-Receive an email message that is quite long in length and will take greater than two minutes to process, so file into Read/Review folder with the Next Action being to read the mail to then determine the subsequent NA.

-After some time (several hours), go back and process my Inbox, and find another message that will take me much more than two minutes to read, so again file into the Read/Review folder. However, unbeknownst (sp?) to me at the time was that this message that I just filed is another version of the prior message, only much later in the thread (ie many more people have commented on the topic).

Now, what I have in my Read/Review folder are potentially several tasks that are for the exact same topic, but at different points in the mail thread. Had I not filed them into my Read/Review folder but rather left them in my Inbox, then when I processed my Inbox (having sorted it first based on Conversation), it would have been easy to delete all those messages that were early on in the thread and just keep the latest and filed that into Read/Review.

So, my question centers around "best practices" on how others handle this situation.

 

[Brent]

One of the aspects of GTD that appeals to me most is its guise as a martial art. GTD allows you to offset work for later, and know that you will get to it. This allows you to deal with whatever needs to be done right now.

As I understand it, apgold, you get version 1 of a thread, set it aside because it'll take too long to read, then you get version 2 of a thread, set it aside because it'll take too long to read, then come back to read threads and find that thread 1 can just be deleted.

However, when you received version 1, you couldn't know when version 2 would come. You also chose to not read version 1 then, so you filed it. When you received version 2, presumably you didn't necessarily remember that version 1 was filed away and you chose to not read version 2 then, so you filed away version 2.

All of these actions are good. You are offsetting action until you have time to deal with it. The fact that you had multiple versions of the same thread to read simply means that the discussion continued apace while you were away from it, and you chose not to deal with it until a later point. As I see it, this isn't a failure of GTD or yourself at any point.

 

[spectecGTD]

Brent nails it.
GTD wont' solve all your input problems, but it provides a framework for dealing with input in a focused, organized manner.

Maybe I misunderstood this, but you mentioned that you can sort your inbox by "Conversation". Why can't you set up a temporary folder for each group of emails which would meet this sort criterion and move them from your inbox in the appropriate folder as they arrive. Once each folder is no longer needed (ie there is no more input expected and you have gone back & read the appropriate emails), it can be deleted or renamed.

 

[kewms]

-After some time (several hours), go back and process my Inbox, and find another message that will take me much more than two minutes to read, so again file into the Read/Review folder. However, unbeknownst (sp?) to me at the time was that this message that I just filed is another version of the prior message, only much later in the thread (ie many more people have commented on the topic).

Now, what I have in my Read/Review folder are potentially several tasks that are for the exact same topic, but at different points in the mail thread. Had I not filed them into my Read/Review folder but rather left them in my Inbox, then when I processed my Inbox (having sorted it first based on Conversation), it would have been easy to delete all those messages that were early on in the thread and just keep the latest and filed that into Read/Review.

Ah, I see.

I'd sort the Read/Review folder by subject, then by date. Read the newest messages on a given subject first, then you can just skim the older ones to make sure nothing important was snipped along the way.

Katherine

 

[apgold]

Except that Read/Review is not a folder per-se, it is an action in the Task list (@Read/Review). The original message gets moved into the @Action folder under Inbox (per the GTD add-in), but the actual processing is within the Task list.

Again, I am not pointing this out as a problem with GTD or my "system", I am more asking as to how others manage this same situation. Thanks.

 

[ko]

I've had a similar situation happen, not with email threads to Read/Review, but with NAs that cropped in my mind at random times. I noted them, through them into the Inbox for later processing, and then placed them in the appropriate NA list when I processed my Inbox.

Usually, I become aware of these duplicates when I'm looking over my NA lists to determine what to work on. The NAs are specific enough that I can see where there are duplicates, and my lists are rarely so long that these aren't readily apparent. In your example, if it were mine, I would notice duplicates and then go to the appropriate action support folder and note the most recent.

If I don't catch the problem then, I will catch it at my weekly review.

 

[severance1970]

Can anyone offer some insight or best practices on how to manage the case where multiple, nearly duplicate, actions get entered for the same topic? For instance, when processing my Inbox, a next action very well may be that it will take longer than two minutes just to read the thread and determine what I want to do. Therefore, I will file that in my Read/Review folder (so my next action is to read the item). Then, before I get around to processing that particlar Read/Review item, I get another email on the same topic (perhaps a few days later, so I don't recall that I've already filed a version of this in Read/Review), which, since it will take longer than two minutes, again goes into Read/Review.

Maybe I'm misreading this, but it sounds to me like you're spreading your inbox rather than processing it: "a next action very well may be that it will take longer than two minutes just to read the thread and determine what I want to do." This suggests that you're trying to determine a next action on an outcome you haven't defined or identified yet.

It might take longer than two minutes to read a document in order to identify what's expected from it, but determining the successful outcome isn't subject to the two-minute rule, because if you throw it into Read/Review before you've made that determination, it's still "stuff" -- you don't know what you've just thrown into Read/Review.

Once you've determined the outcome, the next action may very well be throwing it into Read/Review. For instance, it may only take a few seconds to look at a document and say, "This is a contract I'm supposed to sign" (Project: Sign Acme contract); but it might take 20 minutes to read it well enough to know if you should be signing it (Next action: Read Acme contract). If you have multiple inputs related to the same project, then it's time to create a project folder (Acme Contract) and file it appropriately.

 

[ProfDD]

E-Mail Handling

I don't think I get enough substantive e-mail to fully identify with the original question. I try to filter as much incoming e-mail as possible into various reading folders (by subject for more important things that might have news or data for an active project, by class [ads, event announcements, passwords and account number info] for other reading.

But it seems that one might want to defer acting on e-mails that might generate multiple responses until one has a few of the responses in hand. I find that I usually have an "@Waitingfor" NA connected with e-mails that I send.
It doesn't seem much of a stretch to create a mail folder for responses to such e-mails. When I expect a lot of them in response to a single e-mail or groups thereof, I create a separate folder.

For me it would be a waste of time to create separate tasks for most individual e-mails.

 

[apgold]

Maybe I'm misreading this, but it sounds to me like you're spreading your inbox rather than processing it: "a next action very well may be that it will take longer than two minutes just to read the thread and determine what I want to do." This suggests that you're trying to determine a next action on an outcome you haven't defined or identified yet.

Excellent point, well taken. Thank you.

 

[apgold]

It might take longer than two minutes to read a document in order to identify what's expected from it, but determining the successful outcome isn't subject to the two-minute rule, because if you throw it into Read/Review before you've made that determination, it's still "stuff" -- you don't know what you've just thrown into Read/Review.

Could you elaborate on "determining the successful outcome" point? If it isn't subject to the 2-minute rule, it could take quite a long time for my initial "getting to empty".

 

[kewms]

"What will have happened when this can be successfully checked off?"

If there's a long email (or thread) in your inbox, what needs to happen to make it disappear? Do you need to review and comment on a contract or action plan? Do you need to approve a course of action decided by someone else? Do you need to sign up for a project or a piece of a project?

Or, phrased another way, "Why do I care about this email?"

The answer to that question defines the Next Action, so the item is still "stuff" until the question is answered.

Answering the question should take much less than two minutes in most cases, and is *not* the same as actually doing the action.

Looking at it another way, if you can't quickly figure out why you should care about a piece of email, why are you keeping it at all? Why are you receiving it at all?

Katherine

 

[severance1970]

Could you elaborate on "determining the successful outcome" point? If it isn't subject to the 2-minute rule, it could take quite a long time for my initial "getting to empty".

There's no way to know whether or not you have a 2-minute action if you don't know what the action is supposed to accomplish.

Call up the image of the Workflow Diagram and the 2-Minute Rule's place on it. From In you ask, "What is it?", then "Is it actionable?", then "What's the next action?" Then you do the action if it takes less than two minutes. If you haven't decided what "it" is, then it's still effectively in your inbox, even if you've put it in another bucket. That's why I said that it sounded like you're spreading your inbox rather than processing it.

If that's true, then there's probably some confusion between indentifying the nature of the input, and understanding it. Initially you need to identify it. So even a complex legal document will have a heading like "Cease and Desist."

Except for "In," it's important to avoid blending actionable items with non-actionable items in the same bucket, because the distinction between the two starts to blur. Then you'll have to rethink everything you tossed in Read/Review to decide what to do with it, which is what you should've have done what you pulled it from In. Personally, I only put articles, reference material, and someday/maybe material in Read/Review. Project-driven material is organized into a project folder.

One place you can blend actionable and reference paperwork is in project support folder (paper or electronic) as long as you've clearly identified the project the folder supports and have the next actions on your action lists -- instead of using the folder itself at the action trigger. You work from the action list rather than the folder to avoid wading through non-actionable paperwork just to decide what your next actions are.

 

[ProfDD]

"Spreading the Inbox" to Read/Review

If you haven't decided what "it" is, then it's still effectively in your inbox, even if you've put it in another bucket. That's why I said that it sounded like you're spreading your inbox rather than processing it.

If that's true, then there's probably some confusion between indentifying the nature of the input, and understanding it. Initially you need to identify it. So even a complex legal document will have a heading like "Cease and Desist."

In a better world, every document would make it clear in the heading what it was. In our world, the product of our schools often bury the relevant point where it is hard to find. In addition, even with the best of intentions and skills, implications for our projects my not be clear. If that means "spreading the inbox", so be it. I would have viewed it that the unclear communication requires an NA of "Reading", with possibly high urgency.

Where does one put the document to be read ? In a project folder ? If it clearly belongs to an existing project, then that's clear. If it isn't clear which project or multiple projects are involved, then what ? Create a new project folder ? I've already have enough projects and this is just a single action so far. Put it in my files ? Not if it has some urgency to it. I think that this is what Read/Review is for. There are times when my Read/Review has only low-priority general reading material. But if I have important things to read, they have to go in there too. The Read NA is the only GTD way to remind me of what is important. A read NA may or may not be associated with a project.

Except for "In," it's important to avoid blending actionable items with non-actionable items in the same bucket, because the distinction between the two starts to blur. Then you'll have to rethink everything you tossed in Read/Review to decide what to do with it, which is what you should've have done what you pulled it from In. Personally, I only put articles, reference material, and someday/maybe material in Read/Review. Project-driven material is organized into a project folder.

One place you can blend actionable and reference paperwork is in project support folder (paper or electronic) as long as you've clearly identified the project the folder supports and have the next actions on your action lists -- instead of using the folder itself at the action trigger. You work from the action list rather than the folder to avoid wading through non-actionable paperwork just to decide what your next actions are.

Yes, but another place is the Read/Review pile.

 

[severance1970]

In a better world, every document would make it clear in the heading what it was. In our world, the product of our schools often bury the relevant point where it is hard to find. In addition, even with the best of intentions and skills, implications for our projects my not be clear. If that means "spreading the inbox", so be it. I would have viewed it that the unclear communication requires an NA of "Reading", with possibly high urgency.

I have to admit that I'm having a hard time imagining a piece of writing that can't be identified in the most general terms fairly quickly, at least if it's relevant to the reader's job. I'm only talking about terms general enough to answer the question "What is it?" Identifying the document at the thesis level is crucial before trying to read for intricacy (which you will have to do, but not necessarily in the processing phase).

Where does one put the document to be read ? In a project folder ? If it clearly belongs to an existing project, then that's clear. If it isn't clear which project or multiple projects are involved, then what ? Create a new project folder ? I've already have enough projects and this is just a single action so far. Put it in my files ? Not if it has some urgency to it. I think that this is what Read/Review is for. There are times when my Read/Review has only low-priority general reading material. But if I have important things to read, they have to go in there too. The Read NA is the only GTD way to remind me of what is important. A read NA may or may not be associated with a project.

That's why I prefer to identify the document on the front end: to assess its priority and to determine if it's a new project or a subproject of an existing project; or if it's just reference material.

Intellectually I can agree with the need to account for details, but in practice I simply don't find that difficult to scan a document, ask what it is, whether or not its actionable, and what the next action is. And it's much easier for me to look at project and action list items, with support material filed, to gauge which items take priority than it use piles as reminders or action triggers (this is discussed in GTD Fast, as usual, better than the book). That doesn't mean there isn't some (or a lot of) heavy lifting in the doing phase, but the collect/process/organize phase is fairly simple.

Yes, but another place is the Read/Review pile.

I'm no GTD cop. It sounds like you're getting all your reading processed and read.

 

[jpm]

Re-chunking Next Actions

I can identify very much with Apgold's problem. I routinely get e-mail that comes in threads that in one form or another require "re-chunking". This is a problem not just from a read/review perspective but also from a project level activity perspective. The problem is imho a result of poor communications practices that are fostered by the immediacy of e-mail. It's the Type-Send-Think vs. Think-Type-Send approach to e-mail.

I may get a project assignment from my boss for example that comes in the form of multiple e-mails over a period of several days. I'd like to chunk all of those e-mails into a single master project, but my boss sent them to me as separate e-mails.

Assuming I process it correctly with GTD, I've determined that the three e-mails are:

1. Actionable
2. Project Related
3. Next Actions
(or possibly future actions that should go on my project planning list)

The problem arrises when I review the three items the next time I review the project, and they all pop up as actions under the project. My boss thinks differently than I do, and has thought of each item as a separate thing. I've looked at it and have decided that the three combined are really one thing that I can accomplish in about an hour at my desk. I'd prefer to have just one next action.

Same sort of thing applies to the read/review list.

I haven't found a great answer to this (I typically just check off all three).

One thing that helps is that I have a number of outlook views that make this easy to handle from a project perspective. From a read/review perspective I would suggest processing this list not from the task folder, but from the @Action subfolder under your inbox. I would suggest creating a defined view that includes only your @read/review next actions, and group by conversation. This will at least put all of the threads in the same grouping and you can decide how to deal with them when you get to them.

Hope this helps...