GTD, ADD, and Master List Overwhelm

[dal1mdm]

Projects

Reading a book is not a project for me. I consider it a pleasure and so I dont need to check it off on a list - its something I'd like to do enough that I wont need to be reminded to do it, or make a project plan up in order to make it happen most efficiently. This would be way too mechanical for me. Maybe I didnt give a good example.

How about "call Mom"? Should that be part of a larger project called "Love Mother"? Its a single action thats not related to a project.

Another example: update sales CRM (@Laptop). Its not part of a project, but I need to remember to do it, so its a NA.

 

[xoff]

-- what things absolutely have to get done today?
-- what things absolutely have to get done this week?
-- what one item on here is most important to my #1 career goal?

This is a great idea. I have struggled with the traditional: Urgent/Important...urgent...important...non
This approach has created way too many items in the first 2 categories never letting me get to the third.

I like this 'window of time" approach, especially when one reprioritizes on a daily basis.

 

[ProfDD]

How many NAs per Project ?

I think that Brenda and Action Girl deserve a prize for careful reading of DA. I hunted around in the book and found that DA clearly refers to "at least one" NA per project, but also confuses some of us by having a whole chapter on "What's THE next action ?" The chapter was emphasising the importance of having a next action for every project, not limiting us to one NA per project.

I agree that this can be done, and that this can work. However, I think that as a rule, only the single next action should appear in the NA list.

In the situation you provide, I prefer to choose one action and put it on my NA list. The other action goes on a Project list.

I would like to understand why Brent favors having one and only one NA per project. It seems absolutely impossible in some cases. For example, let's say that a project has to be completed before the next weekly review, that several actions are needed to complete it, and that they are independent of each other. I would argue that all of these items should be on the NA list.

To avoid overwhelm, we may need some principles to work the list down to a more manageable size, but I haven't yet heard of a good systematic formulation for doing so.

 

[ProfDD]

Be flexible about defining Contexts for yourself

Hi --

As is true with others who've posted to this forum, I have Attention Deficit Disorder.

I also have ADD and sympathize.

I liked your summary of the benefits of GTD for you and your metaphor of hunting for the weak prey among NAs.

Where I'm having my biggest breakdowns lately has to do with selecting my work. Dividing my list by context doesn't help -- 95% of my work time is spent in front of my computer. I just don't have much of the "15 minutes in an airport" kind of time that appears to make the context lists helpful. I do have my lists sorted by "type of work" -- reading, writing, phone calls, etc. -- which helps me select tasks appropriate to the current levels of energy and ability to focus.

Perhaps you could characterize the NAs by the quality of mental activity (Needs High Focus, Potential Hyperfocus Trap, Normal) that they require from you and match then with the time of day or medication schedule point that makes you most likely to succeed efficiently. Maybe just characterize items as needing "@QualityTime".

I would be very interested to hear what works for you and whether you think this idea would be practical for you.

 

[Brent]

I would like to understand why Brent favors having one and only one NA per project. It seems absolutely impossible in some cases.

Those two statements are not mutually exclusive.

 

[ProfDD]

What are the Advantages of "One NA per Project" Rule ?

Directed to Brent and anyone else who follows this rule:

In your experience, why is it better to adhere to the "One NA per Project Rule" ? DA certainly does not require it. He states only that there should be AT LEAST one NA per Project.

 

[kewms]

Only immediately doable actions should appear on your NA lists. Listing actions that you can't actually do (given the appropriate context) undermines the whole GTD system.

Projects are likely to include many dependent actions, and these dependent actions should certainly be included in your project support materials. But only immediately doable actions should appear on your NA lists.

I don't follow the one NA per project rule myself, since my projects often have parallel tasks. But the purpose of the rule is sound: to limit your NA list to only those actions that you can actually do.

Katherine

 

[ProfDD]

Psychological Advantage of Only One NA per Project ?

Is there some kind of psychological advantage to the "One-NA-per-Project" rule, other than shortening the master NA or context-specific NA lists ?

It always seemed that it would force me to go back to the Project too often during the week if a project needed to be moved along before the next weekly review. I liked the PigPog method for simple sequence projects, though record-keeping on the early steps was either lost or a little awkward.

 

[airolg]

I use David's definition of a project as anything that requires more than one next action to complete, so in my system I'd have a project which would be "Read the book, Freakonomics".
My next action would be on my @ERRANDS list and would be "Visit bookshop to buy or order Freakonomics". Just buying the book is not going to complete the project, so I like to have it on my projects list.

This is really where my attempt to implement GTD fails so often.

I'm just not breaking my stuff down enough and it hurts the entire system...Thank you for pointing out this example of some of the things I'm doing wrongly.

 

[kewms]

Is there some kind of psychological advantage to the "One-NA-per-Project" rule, other than shortening the master NA or context-specific NA lists ?

It always seemed that it would force me to go back to the Project too often during the week if a project needed to be moved along before the next weekly review.

What's wrong with going back to the Project during the week?

There's a lot wrong with having undoable actions on your NA lists. Undoable "stuff" is why a traditional ToDo list is not the same as a GTD NA list.

Katherine

 

[ProfDD]

I use David's definition of a project as anything that requires more than one next action to complete, so in my system I'd have a project which would be "Read the book, Freakonomics".
My next action would be on my @ERRANDS list and would be "Visit bookshop to buy or order Freakonomics". Just buying the book is not going to complete the project, so I like to have it on my projects list.

This looks like an excellent situatioin for using PigPog, perhaps as follows:
"Check Borders store inventory, visit bookstore, read Freakonomics" is the Task entry. It would appear in @Online initially, then @errands, then @Reading, deleting the completed bits as you go.

 

[Brent]

Thank you, ProfDD, for engaging me on this. It's a fascinating line of thought.

Directed to Brent and anyone else who follows this rule:

In your experience, why is it better to adhere to the "One NA per Project Rule" ?

It clears my head and sharpens my focus.

Let's reduce this to a simple case: One project, with three actions. Would you rather have a to-do list with three things on it, or a list with one thing on it? Which would be easier to focus on, the three things or just one thing?

Now multiply that by twenty projects.

Okay, how about the other end of this? Wouldn't adding several possible, non-interdependent actions for the same project increase my efficiency? No, because it clouds my focus with a long list of possible actions. I already have 99 Next Actions on my NA list, just with one NA per project, and each context has at least a dozen NAs each.

It always seemed that it would force me to go back to the Project too often during the week if a project needed to be moved along before the next weekly review.

The real world interferes with my projects too much to allow me to wait until the weekly review to check back with my projects. Also, if I take one action that renders a project unnecessary or requires a major shift in focus, I don't want to have to hunt through my NA list for all the NAs relating to that project to prune them out.

Moreover, I think it's helpful that GTD forces me to revisit my projects as I accomplish a significant amount of work on them (so I can formulate a Next Action). Often, the action I have taken has affected my plan enough that I need to change my plan.

(Also note that I'm not performing Mini Weekly Reviews when I do this; I just spend a few seconds thinking about my project, and figuring out the Next Action.)

How many of your NAs are unnecessary because of actions you've already taken that will require you to change course?

 

[Brent]

Replying to my own post, but:

I just want to make clear: I am not suggesting that your NA list must only have one Action per Project. I am suggesting that "one Action per Project" is a good desired state, and a good general rule to follow, and that it brings deep, significant benefits.

I've certainly had multiple Actions per Project on my NA list. And in fact, I just noticed a couple on there right now. I don't think this is necessarily a good state.

 

[ashraf999]

I have not read any books from GTD but I have learnt alot from reading the threads here. I wonder if it is applicable in GTD system to have multiple NA lists instead of one?. In other words, can you have one NA list for each project?.

 

[kewms]

I have not read any books from GTD but I have learnt alot from reading the threads here. I wonder if it is applicable in GTD system to have multiple NA lists instead of one?. In other words, can you have one NA list for each project?.

You should have one and only one master NA list (sorted by context). Otherwise, you have to look all over the place to figure out what to do next, which misses the point.

However, your project support materials can and should contain as much detail as you want about the actions associated with each project.

Katherine

 

[Brent]

Yes. The major exception to this rule (in my mind) is to keep one NA list at work and another at home. Often, the work/home divide is large enough that this is the most efficient process.

 

[CJSullivan]

I've certainly had multiple Actions per Project on my NA list. And in fact, I just noticed a couple on there right now. I don't think this is necessarily a good state.

I don't believe it's a *bad* state at all to have multiple next actions on a project. There are some projects that will have "dependent" actions, which means I must do action A before I do anything else. But there are plenty of larger projects that have subprojects, and each subproject might have one or more discrete actions that can be done to move things forward. In fact, if you don't capture all of the next actions on all the components of a project, then you're missing out. So, no worries on multiple actions per project in my mind!!

 

[ashraf999]

Thanks for the clarification

 

[ProfDD]

I don't believe it's a *bad* state at all to have multiple next actions on a project. .... In fact, if you don't capture all of the next actions on all the components of a project, then you're missing out.

To reinforce the point, the important thing is to have AT LEAST one NA per project or subproject. I can even cite DA on this, if you'd like. The one-NA-per-project "rule" is not part of GTD.

Common sense would suggest that moving a project along quickly with only weekly project reviews would require completing multiple actions in the week if possible. The "PigPog" (q.v.) method is useful for moving through a simple, linear sequence of NAs that constitute a project or subproject without having to review the project.

 

[Brent]

...there are plenty of larger projects that have subprojects, and each subproject might have one or more discrete actions that can be done to move things forward. In fact, if you don't capture all of the next actions on all the components of a project, then you're missing out.

I think you're confusing my point. I completely agree with you about the importance of capturing all those components of a project, but those belong on the Project's list, not necessarily on the NA list.

There's a danger in having an NA list so large that some actions can get lost.

Computer programming is a good example. In many programming projects, there are many possible NAs that are not dependent on anything else. I could add twenty NAs to my NA list, all related to one project, but that seems not useful to me. Better to choose now which one of those to concentrate on and add that to my NA list.

I want to decrease the amount of mental work I have to do when I look at my NA list. I can more quickly choose one of twenty hand-picked NAs than one of a hundred. It requires a little more up-front work to decide on just one NA per project, but I think it's worthwhile when I'm glancing at my NA list for the tenth time today, and I only have a few seconds in which to choose something.

There's a psychological aspect to this: If I glance at a list in which 50% of its actions relate to one particular project, I'm going to be more likely to work on that project than others. But that's not fair to the other projects. Seems to me that, by having multiple NAs per project on your NA list, then some projects are going to get more of your time than others. I want to make sure all of my projects get equal attention.