Can anybody point me to any of David Allen's quotes regarding prioritization (or lack of prioritization) among our context lists? Like many of you, I'm researching this subject a bit more deeply myself!!

And I'd like to start my research by looking directly into the horse's mouth!

Can anybody point me to any of David Allen's quotes regarding prioritization (or lack of prioritization) among our context lists? Like many of you, I'm researching this subject a bit more deeply myself!!

And I'd like to start my research by looking directly into the horse's mouth!

Thanks so much, cwoodgold. I have read David's and your posts, and I can see valid viewpoints in each. I am currently undecided as to what to do about prioritization.

If you don't need it - don't use it. I see no benefit in using more priority levels than Active and Someday/Maybe in my system. I've tried to use ABCs and found that it was just another way to procrastinate - to fill my time with a fake instead of productive activity.

Comment

If you don't need it - don't use it. I see no benefit in using more priority levels than Active and Someday/Maybe in my system. I've tried to use ABCs and found that it was just another way to procrastinate - to fill my time with a fake instead of productive activity.

Also do not forget that your *principles*, those ideas and goals that are at the core of your life are, perhaps the most important prioritizations you can place on your lists.

I agree with TestTeq, if one feels the need to prioritize @someday lists then I believe the process is now a distraction rather than a way to simply Get Things Done. It seems to me that the addition of priority codes will themselves require another layer of attention and are in effect a distraction. I believe Meg's comments about time scales are there to prevent one from getting stuck in the *current* workflow process so one does not become slavishly devoted to having to consider and commit to those items in @someday. I think one must read more into her statement about the time of what projects and tasks should go into ones lists. TestTeq made two of the most salient remarks regarding the *need* to revise GTD. Reread them, they are pithy but they contain a deep understanding of GTD.

GTD lists (projects and NAs) are there to do one thing and one thing only: ease your mind to enable you to respond with relaxed focus to what is presented to you at the moment. The addition of a project to @someday should not cause you dis-ease since there is no real commitment to devoting any resources and energy to the project. You just have to ask yourself in the weekly review two questions: (1) Is this project in alignment with my principles and 50k foot goals in life, AND (2) Do I have the resources and energy, at present, to move this project closer to completion with the next action? Answer Yes to (1) and No to (2) keeps it on the list and you move on. Answer NO to (1) OR YES to both moves it off @someday to either the rubbish bin or onto an active project.

Just keep it simple and Get Things Done!

Comment

This is a very interesting post and the one element of GTD that I do not follow, as outlined in the book, is the idea of adding time frames to my next actions. I use the term time frames because I don't prioritize things by day (that's my hard landscape or calendar) but I do add time frames in three buckets: 1. This Week, 2. Next Week, 3. This Month. All of my other next actions are still listed as a next action but are not given a time frame.

Originally, I had seven categories instead of 3 and as you can imaging it just became to cumbersome to review and manage. I originally based it on the Secret Weapon Method but paired it down.

I have some key projects that are time sensitive and the actions within those are time sensitive and I find it useful to have these time frames.

I think the thing we all need to keep in mind is that our system should be as useful as possible without being overly complex. The important thing is to train yourself to collect and process your stuff in the most efficient and effective way, and to organize the results of that in some way.

If you have found yourself even intrigued by this level of discussion or thinking, I say congrats to you! You are likely on a path to a level of productive living most people do not aspire to

Comment

When I first read this thread I was a bit turned off by the mention of timelines. I am a bit allergic to timelines, you see, and I inadvertently read more into "GTD 2.0" than I should.

I have now reread the thread a bit more carefully, and I notice that I actually agree with almost everything in the original post - the description of the problem, someday vs maybe, the temporal aspect and almost everything.

I most certainly agree that temporal categories are key, and I also agree that the priority field, if your app has one, is an excellent choice of feature to use, and it certainly is essential to be able manage the reviewing efficiently. This is my conclusion, too, and is what I do.

The only real difference that I can see now between my approach and that of moises is the exact interpretation of the temporal categories (A, B, C). I am reluctant to set up timelines for the actual doing of the tasks. Instead I use the temporal categories as the frequency of the reviewing of the tasks. But the end result is very similar - the As tend to get done sooner than the Bs. If I review a task more often, the likelihood of it getting it done increases. It is easier for me to commit to a review frequency than to a timeline.

Comment

Excellent post, Folke. I agree with your last point. I've started using A, B, and C to signify "Extremely soon", "Soon", and "Relatively soon". But the A's don't necessarily get completed before the B's, and the B's don't necessarily get completed before the C's.

--Chas29

Comment

Week 1 you set a priority for project A for 3 wks
Week 2 you set a priority for project B for 3 wks
Week 3 you set a priority for project C for 3 wks but project A hasn't been started yet... So now you have two projects with a 3 week priority but one is six weeks old and..

I suppose you could solve this by giving a DATE name to the grouping folder. Instead of "List for the next 3 weeks", you could have "list until Oct30". Then it will become a bit like the rolling effect of a tickler file.