Re: SOMEDAY/MAYBE vs. low priorities

[Adam Spiers <orgmode@adamspiers.org>]

Pete Phillips (pete@smtl.co.uk) wrote:
> >>>>> "Adam" == Adam Spiers <orgmode@adamspiers.org> writes:
> 
>     Adam> GTD methodology suggests having "someday" and "maybe" task
>     Adam> buckets for things which you want to remember to do at some
>     Adam> undetermined point in the future.
> 
>     Adam> So far I have implemented this in org-mode by using SOMEDAY
>     Adam> and MAYBE keywords.  However I have been deliberating whether
>     Adam> in fact these states are simply low priorities in disguise,
>     Adam> and whether as a result it would make more sense to use [#D]
>     Adam> for "someday" and [#E] for "maybe", on the grounds that
>     Adam> "someday" implies that you really do want to accomplish the
>     Adam> task eventually, whereas "maybe" implies that you're not yet
>     Adam> decided whether you care too much if it ever gets
>     Adam> accomplished, and is hence lower priority than "someday" (and
>     Adam> probably the lowest priority imaginable, in fact).
> 
> I disagree. They are not priorities. In fact, David Allen doesn't put
> any store by priorities anyway. His view is that priorities are dynamic,
> not static, and that any priorities you set now will change tomorrow
> when you get into your office.
> 
> I used to use a dayrunner, using the classical time planning
> priorities. In retrospect, it never really helped me (although it was
> clearly better than the totally ad-hoc way I used to manage things
> before!). In fact I think it makes things too complex.  I find that the
> GTD approach of reviewing my projects on a regular basis, in conjunction
> with checking my diary for the next month, helps me decide what i should
> do next. It also reduces the workload in terms of having to
> re-prioritise.
> 
> This is what DA says:
> 
> 	"And daily to-do lists and simplified priority coding have proven
> 	inadequate to deal with the volume and variable nature of the
> 	average professional's workload. More and more people's jobs are
> 	made up of dozens or even hundreds of e-mails a day, with no
> 	latitude left to ignore a single request, complaint, or
> 	order. There are few people who can (or even should) expect to
> 	code everything an "A," a "B," or a "C" priority, or who can
> 	maintain some predetermined list of to-dos that the first
> 	telephone call or interruption from their boss won't totally
> 	undo."
> 
> Now, you may or may not agree with this, but personally I would try to
> avoid using priorities *if you are using GTD methodology*.  If you are
> using some other system, then it may work. However, GTD doesn't need
> priorities because (quoting DA again):
> 
> 	"As I've said, you shouldn't bother to create some external
> 	structuring of the priorities on your lists that you'll then
> 	have to rearrange or rewrite as things change. Attempting to
> 	impose such scaffolding has been a big source of frustration in
> 	many people's organizing. You'll be prioritizing more
> 	intuitively as you see the whole list, against quite a number of
> 	shifting variables. The list is just a way for you to keep track
> 	of the total inventory of active things to which you have made a
> 	commitment, and to have that inventory available for review."
> 
> Also in the book, he says that your priority is dependant on context,
> time, and energy available.  So for example, you have an hour until a
> meeting, you are pretty knackered, and have a phone and computer
> available. Do you try to do the priority A item on your list ? What if
> your priority A item is to write your business plan for the year ? With
> an hour, and feeling knackered, you are probably better off dealing with
> a bunch of phone calls, or processing emails. What if you have 10
> minutes ?  What if you have an unbroken 8 hours ?
> 
> The point about this is that your priorities change constantly, you
> don't have time to keep rearranging them, and you will make choices
> based on other factors other than the priority you gave an item a few
> weeks ago. In fact, you are likely to ignore the priority in the above
> situation, so save yourself the bother.

Thanks a lot for the feedback.  I have read the book several times but
it was great to be reminded of his views on priorities.  Having said
that, I think I would really struggle to review on a regularly basis
without some kind of prioritisation, since at the time of writing I
have 324 NEXT actions and 82 PROJECTs.  Surely that's way too many to
review all of them within the reasonable timeframe of a weekly review
(which I imagine would be 30-120 minutes)?  Likewise, with this amount
of "stuff" to deal with, I think I would struggle by using his
4-critera (context/time/energy available/priority) and 6-level (ground
to 50,000ft) models alone for deciding what to do next - and that's
even with having all the org-agenda-custom-commands already in place
for viewing tasks by context, time, and energy available.

So at very least I really need a good way of marking a huge chunk of
them as "someday/maybe" so that they don't clutter up the weekly
review but are still available for say, a monthly review.  And on top
of that, I need a way of marking a "someday" or "maybe" task/project
as already STARTED or WAITING etc., which is why I wrote:

>     Adam>   - Priorities become truly orthogonal to workflow, e.g. if
>     Adam> your workflow keywords are PROJECT, PROJDONE, NEXT, STARTED,
>     Adam> WAITING, DONE etc. then you can mark any of these as
>     Adam> someday/maybe priority.  This is quite a big advantage AFAICS.
> 
> Hmmm. I don't quite get how this works. Why mark something as a PROJECT?
> What is the difference between PROJDONE and DONE ?

DONE is for completed NEXT actions, whereas PROJDONE is for completed
projects: I will have to change several actions from NEXT to DONE
before I can change the containing PROJECT to PROJDONE.  However when
archiving completed projects, I wanted to maintain the distinction
between projects and next actions, which is why I didn't overload the
meaning of DONE.

> Let me briefly explain my system with a snippet of my org-mode file:
> 
> * Projects
> ** ------A------
> *** Annual Report  DEADLINE: <2008-04-11 Fri>
> **** NEXT email tech staff for summary of main projects completed this year :Laptop:
> **** NEXT speak to finance accountant - need summary of years income :Phone:Office:Jason:
> **** NEXT Write annual report SCHEDULED: <2008-03-14 Fri> :Laptop:
> **** Email report off :Laptop:
> ** ------G------
> *** Glove Friction testing 
> **** DELEGATED Ask John to get 2 brands of gloves tested for friction data :Office:John:
> **** NEXT Check with John whether the test data is now ready :Office:John:
> **** WAITING [2007-09-12 Wed] Emailed Acme Corp to see if they are interested in commercial friction testing. :Laptop:
> **** Write paper for publication
> ** ------W------
> *** SOMETIME write research bid for effect of gels on exam gloves 
> **** Discuss with Sam or Jim. 
> 
> Basically, I have part of my file for Projects, and underneath that the
> two star levels are just letters, so that I can group all projects
> starting with that letter together (if you have dozens or hundreds of
> projects, this helps a *lot*.

Doesn't isearch-forward/backward accomplish the same thing?

> Projects are three stars, and tasks/next actions are underneath those.

OK.  My setup is similar except that I allow for sub-projects -
projects within projects.  As a result, projects are not uniquely
identified by their star level, so I explicitly mark them with PROJECT
which means I retain the ability to do keyword searches on them.  This
also has the advantage that I can include items for reference within
the project as sub-headings, and they won't have a keyword so they
won't show up in searches.

> Anyway, with the basic structure out of the way, each task/NA may have a
> context associated with it (using org tags). So the next action of
> "speaking to the accountant" can be done over the phone, when I'm in the
> office, or when I actually see the guy (Jason).

Similar to what I do.

> Some actions don't have an org-mode todo keyword. That means that I have
> not as yet decided to move on them. When I do my regular review, I check
> whether I am ready to associate a todo keyword with them.
> 
> My main point here is that these should tell you the stage of this
> project or task.  I use:
> 
>  "NEXT" "WAITING" "DELEGATED" "SOMETIME" "DONE"
> 
> Either I need to do something (NEXT), or I have asked someone outside
> our lab for something, written a letter etc (WAITING), asked someone in
> the lab to do something (DELEGATED), done it (DONE) or decided I want to
> make a decision about this sometime in the future (SOMETIME).

Hmm.  So you have WAITING and DELEGATED both meaning that you cannot
proceed until an external action is completed by someone else - what's
the difference?  And what do you mean by "not as yet decided to move
on them"?  Is that waiting on an internal action to be completed by
yourself, or that you haven't decided what to do next (a la "stuck
projects", and will at the next review?

> I then have my customised agenda searches set up so that for example,
> ^C-a-l will show me all NEXT actions with the context of Laptop, and
> ^C-a-L will show me *all* items which are labelled with the Laptop
> context. I use the ^C-a-l when deciding what to do next when I'm at my
> laptop, and ^C-a-L when I want to look at *everything* (DONE, SOMETIME
> etc).
> 
> I also use DEADLINE for things that I want to appear in my agenda so I
> know when I have to have them done by, and SCHEDULED for things I hope
> to work on on a certain day.

Yep, almost identical here too.

>     Adam> What do people think?  Are there other pros/cons, and is there
>     Adam> a clean solution to "generally" restricting TODO views to #C
>     Adam> or higher priority?
> 
> Hmm. I guess my answer to this is that there is a *different* solution.
> 
> 	:-)

I think this is where I am currently struggling with GTD.  When I have
so many NEXT actions and PROJECTs, how can I manageably review them on
a weekly basis, and how can I make quick but reliable decisions
several times a day as to what to do next?