advice on my GTD method

[Longstreet]

As I am leaving the public forums and staying within the Connect forums, I will simply state that I maintain my position vehemently just as you maintain your position. As I said, enjoy the forums and best wishes.

 

[Gardener]

As I am leaving the public forums and staying within the Connect forums, I will simply state that I maintain my position vehemently just as you maintain your position. As I said, enjoy the forums and best wishes.

I didn't think that we had any actual disagreement, beyond the inappropriate use of the word "cult", so your maintaining your position doesn't really seem relevant to the discussion. But, OK, have fun over there.

 

[Longstreet]

Maintaining my position is relevant. My modified practices are within a good GTD approach. Period. You call it whatever you want. That my friend is me maintaining my position.

 

[Folke]

Edit: Oh holy horse, when I wrote this I had not realized this thread had turned into a new whole discussion with many new posts. This is in response to Garderener's post http://gettingthingsdone.com/forum/...0-advice-on-my-gtd-method?p=179406#post179406

I understand and agree, Gardener. I would do the same - and actually do the same. I think there is actually a "hard landscape" link here somewhere, even if it is a bit difficult to put the GTD finger on it. Your sewing table can hold only one sewing project. Your seedlings will die if you buy more than you have time to plant etc. That's hard, external, objective, not just your own "planning" or "preference" or "prioritization". It is "hard landscape" kind of thinking, as far as I can see, but more complex than the vanilla GTD teachings. And the same goes for many business projects and other projects - you simply have to keep up some certain momentum in each project; otherwise they will fail. So you cannot allow everything onto your current lists even if you would "want" to do them. And for me, that makes them Maybe - if I cannot commit to them now I do not know whether I will ever be able to commit to them; they usually are Someday/Maybe in my world. (I keep different attention levels even for Someday/Maybe; some are "hotter" than others ;-) ) (Or they could be treated as dependent subprojects etc within a larger project, if your app can handle that and if you think it is worth the effort to define that, but I usually do not.)

Edit: Longstreet, you really are very temperamental - JC; you should become an actor and a movie star ;-) ! I really hope to see you again one day. It has always been fun (Nirvana, Zendone, here ...)! My very best to you.

 

[Gardener]

I understand and agree, Gardener. I would do the same - and actually do the same. I think there is actually a "hard landscape" link here somewhere, even if it is a bit difficult to put the GTD finger on it. Your sewing table can hold only one sewing project. Your seedlings will die if you buy more than you have time to plant etc. That's hard, external, objective, not just your own "planning" or "preference" or "prioritization". It is "hard landscape" kind of thinking, as far as I can see, but more complex than the vanilla GTD teachings. And the same goes for many business projects and other projects - you simply have to keep up some certain momentum in each project; otherwise they will fail. So you cannot allow everything onto your current lists even if you would "want" to do them. And for me, that makes them Maybe - if I cannot commit to them now I do not know whether I will ever be able to commit to them; they usually are Someday/Maybe in my world. (I keep different attention levels even for Someday/Maybe; some are "hotter" than others ;-) ) (Or they could be treated as dependent subprojects etc within a larger project, if your app can handle that and if you think it is worth the effort to define that, but I usually do not.)

Thanks for going into this much detail; I like to know the source of a difference of opinion. It sounds like the difference here is to some substantial extent, though not entirely, the definition of "maybe". So our practices are probably less different than our descriptions of our practices would suggest.

 

[Gardener]

Edit: Oh holy horse, when I wrote this I had not realized this thread had turned into a new whole discussion with many new posts. This is in response to Garderener's post http://gettingthingsdone.com/forum/...0-advice-on-my-gtd-method?p=179406#post179406

Heh. I assumed you were responding to my response to you, not the squabble. I assume everyone assumed the same.

 

[Longstreet]

@Folke: Maybe temperamental...or passionate about what I do. Who knows? Thanks for the very kind words, though. No time for being an actor. My position as a professor and scientist takes most of my free time.

 

[Oogiem]

Part of the difference could possibly be that you have fewer projects that require pre-prep, or at least not a lot of projects that require mutually exclusive pre-prep. For example, there's no point in my pre-soaking more square feet of ground than I can dig before it dries out, or buying more seedlings than I can plant before they die. My cutting table can only hold one sewing project. My den can hold only so many sewing projects. And so on..

EXACTLY! You and I have a lot fo the same types of someday/maybe Projects. Ic an't be working on a Moy Gown and an Elizabethan and a quilt at the same time, even as big as my sewing room/fleece prep area is there isn't enough room. I can't have more things warped than I have looms so if I have projects waiting for the tool of the big Glimakra I can't be working on them. So they properly belong in Someday/Maybe even though I sure plan on doing them, Someday.

 

[Folke]

larsonec, are you still there? Or have we bored you to death with our other conversations? I thought my initial, fleeting advice to you was quite correct, but here is a more detailed answer:

I'd love to get some advice on my method for Getting Things Done. For the past few years I have used Remember the Milk to catalog most of my one-step tasks and have gotten into a pretty good habit of using it as my "mind dump" whenever I think of something that needs to get finished. I was having a hard time figuring out how to organize my larger projects within Remember the Milk so recently I started keeping multistep projects and their next actions in OmniFocus.

I’ve used Remember the Milk to varying success during the day to get various tasks done at work. Under the category of “work” for example I have three priority designations (i.e., 1-3). If I have some open time at work I will try to go to my list and see what I should be working on next (I tend to dread going to the list, but that's probably a different post for a different day).

Why are you using so many different apps? If you have to, you have to, but if you do not have to, then why? And why do you dread the stuff on one of the apps (RTM)? Because the app is bad or because you put all the boring stuff in that one?

What I'm having the most trouble with now is integrating the projects and their next actions into my daily schedule. I have taken various times during the week and blocked them off for things like writing, memory training, meditate, learn FileMaker, etc. The only problem is when it comes to those times during the week, I don't do what I have scheduled for myself. It seems like there's always something else at work that I need to attend to at the time, and it feels somewhat aversive to change my train of thought away from what I'm doing and onto another topic.

Well, despite the discussion in this thread about certain "advanced" variations of GTD, scheduling and time blocking is not the main approach of GTD. The GTD approach is (primarily) based on selecting what to do now based on context, time, energy and priority. Personally, I am not at all surprised that you did not find time blocking to work for you. And it is not a core GTD method.

I’m considering instead keeping a checklist of my various projects and when I have time available simply go to the next project on the list and see if the next action is something that I can get done feasibly at that time.

I would appreciate any critique of my current setup and to hear about how other people get their next actions for projects built into their schedules?

That is closer to the GTD approach. You should keep all your projects clearly identified. Above all, the GTD approach is to indicate which context each task requires in order to be doable. Does it need to be done in a certain place (office, supermarket)? With a certain tool (computer, jackhammer, dancing shoes)? With a certain person? You need to be able to view the tasks by context - to see which task you can do now.

 

[Longstreet]

You know what....I have decided to conduct an experiment. For one month, I am going to follow standard GTD practices to the letter. No deviation whatsoever in David's teachings. I need to be fair and open-minded that David Allen put a LOT of thought and has thousands of success stories around the world following his best practices. So I begin now. GTD as outlined in his 2015 book, which I just re-read carefully. I will keep everyone posted on how this works out. Wish me luck.

 

[GTD-Sweden]

That sound like a fascinating and rewarding experiment - will be great to get updates

 

[Folke]

It sounds like the difference here is to some substantial extent, though not entirely, the definition of "maybe". So our practices are probably less different than our descriptions of our practices would suggest.

That is a very interesting remark, and I think you probably have a very valid point. Let me philosophize a bit about that, but first:

Do you think it would be correct to describe, say, your future sewing projects as "dependent subprojects" etc within a larger project or effort, in other words as something analogous to dependent actions in a regular project? If I understand you correctly you have no doubt that you will do them, so there is no element of "maybe"; the only problem is that you are unable to start them until some other such project (that uses the same resources etc) has been completed first. These are normally (in paper GTD) kept outside of the lists (in "support material"), but in some apps you can line them up as "sequentially on hold" etc even within the list app itself. Could that be a viable approach for you?

But now back to how we may think differently about Maybe. For me "maybe" is a nice feeling. It means it is totally up to me, like an à la carte menu. I do not have to do any of those things if I don't want to, and can disregard them all or can select to do as many as I want, whenever I want, even now if should have a sudden epiphany that I should do some of them. So I do not mind keeping good things in Someday/Maybe - as long as I have not decided that I will do them, because in that case I do not want them mixed up with things that I have not yet made a decision about. For me Someday/Maybe means "not yet decided". I often prefer to keep things open and undecided unless I must commit.

Perhaps for you and others it is more like this?: You perhaps do not care so much whether it is decided or not. Perhaps the important aspect for you is whether it can happen reasonably soon or much later - if the answer is "much later" you use Someday/Maybe, especially if you do not have a date (or the app capability) to be able to tickle these projects. (Nor perhaps the ability or inclination to keep them as "support material" somewhere). But you are totally convinced that you will do them some day, and therefore would have a very strange feeling about using the term "maybe" for them.

For the other word in that pair, Someday, maybe we have similar differences of interpretation? For me, the word someday means very little, as almost everything in GTD has an undetermined date. Even for my hottest next actions the eventual execution date is unknown until that moment comes. It could be sooner or it could be later. So I almost ignore the word Someday and distinguish between Maybe vs "Decidedly" (Next, Waiting, Calendar etc). Maybe for you and others there is little or no relevance in keeping "undecided" things on your lists at all, so all are "decided" in some sense, it is just a matter whether it will be Someday Sooner (Next, Waiting etc) or Someday Later (Someday/Maybe.) So the word Someday, the time aspect, is the key word for you - correct?

 

[Gardener]

Do you think it would be correct to describe, say, your future sewing projects as "dependent subprojects" etc within a larger project or effort

Yes, quite often. However, that is true for both committed and "would be nice" projects. I think that I miscommunicated and gave the impression that most of my projects are committed. My sewing projects tend to be "would be nice", while far more of my gardening projects tend to be committed.

Though I'm seeing "committed" as a fuzzy concept, which I'll get into further down in this post.

but in some apps you can line them up as "sequentially on hold" etc even within the list app itself. Could that be a viable approach for you?

The fact of sequential dependence is true, but I don't think that I could usefully record that fact in software, because the plan often changes, irrespective of my intent. Plants die, sewing supplies become unavailable, skills turn out to be insufficient. Even if I'm firmly committed to a goal, the path that I take to get there is quite likely to change, especially if that goal is several dependencies away. I used to plan further ahead than I do now, and I usually found that those plans weighed me down, rather than helping me. I would return to a project that had been idle for a while, and I'd spend time untangling plans that no longer made sense.

You perhaps do not care so much whether it is decided or not. Perhaps the important aspect for you is whether it can happen reasonably soon or much later

Yep, yep. This is accurate. If it's not moderately likely to happen soon, I don't want it in my lists.

But you are totally convinced that you will do them some day, and therefore would have a very strange feeling about using the term "maybe" for them.

No, this doesn't bother me. With all my talk about "Somedaying" I may have incorrectly communicated a distaste for "Maybe" that I don't feel. I'm OK with "Maybe". When I "Someday" something I do think of it as being in "Someday/Maybe", and I'm not terribly worried about the distinction between the two.

For me, the word someday means very little, as almost everything in GTD has an undetermined date.

That is probably one of our big differences. For me, "Someday" doesn't mean "I don't know when." It primarily means, "Not soon." Sometimes it means "Not next"--I don't like to have more than a few projects in a given category (Gardening, Sewing, Writing, Programming, whatever) active at a given time. So a sparse category may have an active project that won't see significant progress for a year, while a busy category may see all of its active projects finished and replaced with other projects from Someday/Maybe in a month.

When I typed that last sentence my brain tried to say, "Other projects from the backlog." And I think that is how I think of it. There's a big body of possible work, some of it committed and some of it whimsical, and the majority of both categories is in "backlog."

I think, come to think of it, that there may be useful GTD concepts in Agile programming. I suspect that at any given time, my active GTD lists are defining "sprints". Sort of. All of my examples are from my personal life because I always worry about saying something about work that I shouldn't have, but at work I'm a programmer, and a backlog of things that really should be done, and will be done, but aren't being done today and aren't even being allowed to occupy brainspace today, is a comfortable concept for me.

Maybe for you and others there is little or no relevance in keeping "undecided" things on your lists at all, so all are "decided" in some sense, it is just a matter whether it will be Someday Sooner (Next, Waiting etc) or Someday Later (Someday/Maybe.)

I keep undecided things, lots of them, but the "decided" factor is not that important to me.

So the word Someday, the time aspect, is the key word for you - correct?

So, yes, this is the key concept.

But thinking about this has raised a different but related concept for me: That of...OK, I'm struggling to put a name to it. Precision? Accuracy? Models?

I'll just describe it by examples. It's related to the coinflip concept.

You include in your lists next actions for all of the projects that you have committed to, that can reasonably be active. Part of our discussion is the "reasonably be active" part, but that aside, I'm seeing this as you wanting to have as much information as possible, at the moment of choosing the task to do. You see everything you could do, and that makes you maximally informed in the moment of making the decision. You give yourself more information, in that moment, than I do in similar moments. This is a conscious decision on both of our parts--I deliberately choose to have LESS information available to me in that moment. I deliberately embrace the coinflip rather than the maximally informed decision.

To me, this means that your system is modeling the idea that that information is useful, and my system is modeling the idea that it is not--or at least not useful enough to be worth the scanning time.

At this point I raise the idea of significant digits. Let's say that someone is choosing an apple for lunch. That person weighs both of them and says, "This apple is 68.74534 grams and this apple is 108.89763 grams. I'm not very hungry, so I will take the one that weighs 68.74534 grams."

Neither of us would do that. But in looking at our systems, let's imagine that you might weigh the apples ("about seventy grams...about a hundred grams...") and I would just say, "I'll take the little one." My decision is less informed, because I believe that the extra information won't be useful.

I see a similar difference in the committed/uncommitted difference. Your system sees this as binary--you're committed, or you're not. I'm not saying that you're inflexible--if it becomes clear that a decision was a bad idea, you change the decision. But you model that decision as firm.

I see it as a spectrum, especially when we add the delay of "someday." I'm going to plant a raspberry bed--unless I develop a sudden allergy to raspberries. I'm going to fix this bug in the Widget Analyzer--unless I'm told that the company has sold off the whole Widget business. All projects are maybe, just some are more maybe than others.

Your system MODELS a cleaner, more straightforward world, while mine models a fuzzier one and consciously accepts a margin of error.

Except, of course, that I put maybes in my active lists. When I do that I am temporarily modeling a clear acknowldged maybe, as a commitment.

Anyway. That is all. Until I come up with more.

 

[Folke]

Though I'm seeing "committed" as a fuzzy concept, which I'll get into further down in this post.

I see a similar difference in the committed/uncommitted difference. Your system sees this as binary--you're committed, or you're not. I'm not saying that you're inflexible--if it becomes clear that a decision was a bad idea, you change the decision. But you model that decision as firm.

I see it as a spectrum, especially when we add the delay of "someday." I'm going to plant a raspberry bed--unless I develop a sudden allergy to raspberries. I'm going to fix this bug in the Widget Analyzer--unless I'm told that the company has sold off the whole Widget business. All projects are maybe, just some are more maybe than others.

Your system MODELS a cleaner, more straightforward world, while mine models a fuzzier one and consciously accepts a margin of error.

Except, of course, that I put maybes in my active lists. When I do that I am temporarily modeling a clear acknowldged maybe, as a commitment.

I too actually do not like to use the word "committed". If I did (did I really?) it is usually just an attempt on my part to latch on to something that I believe that most people can relate to, without creating a new discussion. But "commitment" is indeed a fuzzy concept - meaningless to use as a hard distinction, IMO.

The "question" (the criteria) that I actually ask myself when deciding whether to put something down as Next or Someday is "Would it be okay for me to go ahead with this task in the event that an opportunity comes up?". If yes, it is a Next action, if no, it is a Someday, if there is some doubt I usually still keep it in Someday (or I might make a next action of analyzing or researching it - I have a context called @Clearheaded where I then usually put these.)

Things that I put in Someday are not only wild dreams, they can sometimes be very "committed" in an emotional sense. I may really, really want to do it and be convinced it would be worthwhile, but I may see it as unwise to start with this now, because when I start it, if I ever do, it must happen with a certain momentum and "spare capacity" that I cannot guarantee right now. It will likely be a loss of time and money, and might even backfire, if I attempted to start this now. In a way you could see this kind of Someday as a kind of "context" at a higher level - you will do this only if you have more "free capacity" overall some day. Since I do not have that now, I am not prepared to even lift a finger yet, and therefore I do not keep it among my next actions. And I am not sure I ever will, since the "free capacity" may never be available. (So it definitely is a Maybe for me, but it could be a relatively "hot" Maybe - I use my attention colors for Someday, too, with the same type of definition: "How often do I want to look at this?").

And, of course, as you say, whenever we need to change something we just change it - that's what the reviews are for - but we both want it to be stable, reliable and "objective" to the extent possible. And as useful as possible in between reviews.

Your system sees this as binary--you're committed, or you're not.

Your system MODELS a cleaner, more straightforward world, while mine models a fuzzier one and consciously accepts a margin of error.

Frankly, I disagree that one use of a two-bucket system is more binary than the other, or that they embrace fuzziness to a different degree. The subject matter is inherently fuzzy, and we have two buckets, so things will sometimes end up a bit too cleanly in one of the buckets when in fact it was a close call.

The two possible uses that we have discussed of these two buckets is either 1) Sooner vs Later or 2) Yes vs Maybe. With the Sooner vs Later approach you shorten your next action lists and thereby make them more easily scannable. The downside is that you may sometimes lose a good opportunity. With Yes vs Maybe the pros and cons are the reverse.

In both cases we can use tricks that are complementary to GTD to enhance readability and our ability to quickly find things. Some use dates, some use color coding, some use tags etc.

At the end of the day I think maybe it boils down to how we want to deal with the very important factor time. Time is extremely important to all of us. Time can be described with ridiculous precision (just like the weight of apples). Time requirement very often have considerable fuzziness about them.

When it comes to dealing with time, some people choose to use time-based definitions, probably because that feels natural (use time to deal with time). I and some others think time is so important and cannot be accurately modeled, so we prefer to use whatever other, "firmer"/"harder" distinctions that we can come up with and leave the timing decision further towards the end. This is why I would not consider using the Sooner vs Later distinction myself - because it attempts to make a premature decision about when, which is a path that leads in the "wrong" direction, IMO. It does not feel right for me, anyway.

The distinction Yes vs Maybe is also fuzzy, I would definitely agree, but at least it attempts to distinguish something less fickle, namely an "all systems online?" type of objective condition that is not likely to change everytime I have a change of heart.

 

[devon.marie]

One reason why I do not like the idea of putting some Next Actions into my Someday/Maybe list is because it gives me a false sense of commitment. When a co-worker comes to me with a project idea and I check my Next Actions list, if I see a list of 20 or so items I subconsciously think "I've got time to take on that project!" I end up over-committing without fail. Every project I commit to (and it's a very hard definition at my workplace because most projects involve others), gets at least 1 Next Action in my Next Action list. So when someone comes up to me and suggests a project, I can see EVERY next step I've committed to without having to complete a full review. I can decide whether the first step of the new project is more or less valuable than the other first steps on my list. And if it's not, I have a very clear and precise answer to give the fellow staff member.

One thing I've always struggled with GTD and priorities is with regards to Contexts (which is unfortunate as it's a core philosophy). GTD advocates doing the actions that can be completed in the current Context in which you reside. But what if that's not the best use of your time? What if, upon looking at every task on every list, I should NOT be sitting at my computer, but rather out running those errands for tonight's supper ingredients? There's no quick and easy way to decide with which Context I should engage at this moment. GTD tends to advocate using the Context you're IN, as opposed to the Context you SHOULD be in. This has led to quite a few late nighters for myself. So, I mark those high-priority tasks with a color marker when they should help me decide in which priority I should engage, and it's been incredibly helpful.

 

[Gardener]

I too actually do not like to use the word "committed". If I did (did I really?)

If you don't think you did, you probably didn't. I'm probably paraphrasing based in an incorrect understanding of what you've said.

The "question" (the criteria) that I actually ask myself when deciding whether to put something down as Next or Someday is "Would it be okay for me to go ahead with this task in the event that an opportunity comes up?".

Oh, that's interesting. Our practices seem to be getting closer and closer together, the differences more and more in how we describe them.

The difference may come down to a different level of tolerance for long lists. My tolerance for long lists is very, very low. So even if it's OK for me to do a task, it may not be OK for that task and the six dozen others like it to appear in my lists. Your "OK", as I understand your post, is at the task level, and in the interaction of that task/project and your free capacity. My "OK" accounts for those things, but it also accounts for list length.

 

[bcmyers2112]

I don't think the issue is whether to schedule tasks but rather whether larsonec had captured, processed, and organized all of his or her commitments, both internal and external. After all, if other things were taking precedence over the ones he or she scheduled, the scheduled actions weren't the right choices. Even if you adhere to the "rule" (in quotes because I don't think it's an inviolable rule -- we all get to choose how we organize ourselves) to reserve the calendar for the hard landscape, you still can't trust your choices about what to do if your inventory of possible actions isn't complete and current.

Frankly I can see Longstreet's point even if I disagree with the way he expressed it. If he is reviewing all of his options and then scheduling a few of those choices in his or her calendar I can see how that could work, even if I don't think it would work for me. I can also see that being consistent with a good GTD practice.

I think the most important thing about GTD isn't avoiding scheduling anything that isn't "hard landscape" but instead the practice of capturing and clarifying all of your commitments rather than just "the most important ones," and having them in a format that is easy to review at a moment's notice. That is what allows you to trust your choices from moment to moment.

As for the issue about GTD not providing an adequate mechanism for prioritizing, after doing my first weekly review in two weeks I am feeling fine even though I actually have 80 work-related calls in my next actions list. One review of my NAs list today following that review and my priorities were quite apparent.

I have personally found the challenge with GTD is not so much having trouble identifying higher vs. lower priority tasks. It's just been an issue of how to remember the choices I've made after reviewing a lengthy list. But I just fall back on flagging the choices I've made upon reviewing the list -- and unflagging any un-done ones at the end of the day. For me that has proven effective. I don't feel the additional need to add priority codes or, as Folke has done, colors for review frequency. If that works for Folke, great, but I have found my priorities can vary too much for that to work for me.

larsonec, I hope we haven't scared you away. There is a lot of disagreement here. On the other hand it can't hurt to be exposed to different points of view. I think I've learned a thing or two myself from a couple of response in this thread.

(BTW I apologize for my last few somewhat rambling posts. It is amazing to me what a good weekly review can do to clear my head!)

 

[bcmyers2112]

Aw, geez, that last post of mine sucked as bad as the few before it. I don't think it matters whether my interpretation of GTD is better or worse than anyone else's. I think the only thing that matters is what works well for an individual and what doesn't. larsonec reached out because scheduling hasn't worked for him or her. What works for me is keeping a complete inventory of my commitments, with actions sorted by the person, place or tool I need to get them done. That reduces my stress, enhances my focus and makes me feel more confident in my choices. If only I had thought to say THAT before writing 10 million words worth of drivel...

 

[Folke]

One reason why I do not like the idea of putting some Next Actions into my Someday/Maybe list is because ... I end up over-committing without fail.

That's certainly a danger, and is one good reason to avoid placing next actions in Someday.

(And the Someday list also gets muddled if you start to put next actions in there.)

One thing I've always struggled with GTD and priorities is with regards to Contexts (which is unfortunate as it's a core philosophy). GTD advocates doing the actions that can be completed in the current Context in which you reside. But what if that's not the best use of your time? What if, upon looking at every task on every list, I should NOT be sitting at my computer, but rather out running those errands for tonight's supper ingredients? There's no quick and easy way to decide with which Context I should engage at this moment. GTD tends to advocate using the Context you're IN, as opposed to the Context you SHOULD be in. This has led to quite a few late nighters for myself. So, I mark those high-priority tasks with a color marker when they should help me decide in which priority I should engage, and it's been incredibly helpful.

Yes, I agree and I do the same. Color coding for "frequent attention required" is a great way to solve it. It is not a fickle assessment that needs to be changed all the time - it is fairly objective ("hard") and usually very stable.

And I think it needs to be said openly that GTD simply lacks a prescribed way for ensuring you pick un-calendared tasks with the same ease and objectivity as appointments etc. GTD does say that you should check your calendar in the morning for appointments, and it also describes in detail how and why you should be cautious about putting most types of other stuff on your calendar, so that does indeed create a vacuum.

Color coding next actions for "review attention" does not impose a priority order (execution sequence), nor does it impose a date, both of which GTD cautions against, and it does tally with GTD's emphasis on reviewing, so I'll stick out my neck and say that among all the "complementary tricks" I think this kind of color coding is the "most GTD" way of solving the issue.

Our practices seem to be getting closer and closer together, the differences more and more in how we describe them.
...
The difference may come down to a different level of tolerance for long lists. My tolerance for long lists is very, very low.

So is mine - haha - no difference there either

But I also have a very, very low tolerance for muddling my Someday list, and a very, very low tolerance for needlessly missing out on a good opportunity to knock off a few additional perfect next actions tasks, and a very, very low tolerance for not seeing the whole picture, so perhaps the difference between us is in choosing the lesser of these evils?

I have found "salvation" in color coding. Maybe some of the things you put in Someday are the same as those I put as "low attention Next"? That way I can easily ignore them in my morning scan, but have them handy when I pursue a given project/area or want to make the most of a context I am in. Before I adopted color coding I used to manually sort my next actions such that the more "needy" were at the top, but that became too unwieldy.

... you still can't trust your choices about what to do if your inventory of possible actions isn't complete and current.
...
... the practice of capturing and clarifying all of your commitments rather than just "the most important ones," and having them in a format that is easy to review at a moment's notice. That is what allows you to trust your choices from moment to moment.

Totally agreed. If this is not done properly nothing else will work, and you will not trust your system no matter what.

I have personally found the challenge with GTD is not so much having trouble identifying higher vs. lower priority tasks. It's just been an issue of how to remember the choices I've made after reviewing a lengthy list.

Also totally agreed. It is very easy to understand everything and anything about a task once you take the trouble to read it. The question here is how to quickly spot the ones that you need to read yet another time.

I don't feel the additional need to add priority codes or, as Folke has done, colors for review frequency. If that works for Folke, great, but I have found my priorities can vary too much for that to work for me.

Yes, "priorities" in David Allen's sense of the word do change rapidly for us all. There will be different things we want to do first of all, right now, when we are standing in the office a few minutes before a meeting, and when we are sitting at home with a child or grandchild on our lap. You simply cannot code for that in advance even if you wanted to.

Flagging your "current tentative task selection" is a method we apparently both use for keeping a few good choices handy. Those tasks can be big, important, urgent, anything ... or puny, trivial, unimportant, whatever. This selection represents our choice of what would be the "best" things to consider doing in this very moment ("priority now"). I find it very useful, and apparently so do you.

What I had been lacking for many years, in addition to that, and unrelated to that, was a slightly longer-term (days, not moments) and very stable and reliable approach to "navigate" my next actions list, such that I would not have to needlessly scan the entire list every single time, perhaps many times per day, and such that I would feel safe that I would not overlook anything that could hurt me. By default, my actions are "normal" (just like yours, since you do not use this distinction). When I notice that an action does not really require "mandatory" daily scanning I instead mark it as "low attention". This takes pressure off me (and I usually get to see it a lot anyway, more randomly, as a result of looking into a particular area or context etc during the day), and if nothing else I will definitely see it again in my next weekly review. This assessment does not change rapidly. It hardly ever changes.

Conversely, if I see that a certain task is in the "danger zone", objectively speaking, for example, it has no agreed deadline but would have been expected by a client today, yesterday, tomorrow, next few days ... "soonish", and I have not done it, I will change the "review attention" to the higher bracket. This decision is usually very stable. It happens extremely rarely that a task that has reached this level of "attention required" can be reduced to normal again (but could happen if, say, the client had some disaster with something and had to postpone everything else). The required attention usually stays put as a "hard fact" about the action itself even if at one moment I am dashing off into some meeting or at another moment am reading a book to a child. The task is still "objectively" in the "danger zone" even if I have chosen to do something entirely different right now. This is why the color marker can be trusted and can be used to safely and quickly navigate the list.

I am not asking you to adopt color coding or anything. I just wanted to explain that the required attention levels (as I define them) certainly do not change rapidly. The whole argument about priorities changing too rapidly applies mainly to "priority now", i.e. what you might also call "current task selection", i.e. what you choose to do right now or today in view of context, energy, time, priority etc.

 

[TesTeq]

Important message from David Allen:

Hey folks, great discussion. My take on all of this is simply do what you need to do, to get the commitments of your life off your mind. If you want to block out the next six years of your life, day by day, hour by hour, in order to tuck your kids into bed tonight in full presence, then, that's GTD. If you create that plan and structure, and don't recalibrate that part of your external mind when something disrupts it, that's not GTD.