emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Pete Phillips <pete@smtl.co.uk>
To: Adam Spiers <orgmode@adamspiers.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: SOMEDAY/MAYBE vs. low priorities
Date: Mon, 31 Dec 2007 19:01:26 +0000	[thread overview]
Message-ID: <22876.1199127686@localhost> (raw)
In-Reply-To: Your message of "Mon, 31 Dec 2007 14:44:14 GMT." <20071231144414.GM20947@atlantic.linksys.moosehall>

>>>>> "Adam" == Adam Spiers <orgmode@adamspiers.org> writes:

    Adam> Thanks a lot for the feedback.  I have read the book several
    Adam> times but it was great to be reminded of his views on
    Adam> priorities.  Having said that, I think I would really struggle
    Adam> to review on a regularly basis without some kind of
    Adam> prioritisation, since at the time of writing I have 324 NEXT
    Adam> actions and 82 PROJECTs.  Surely that's way too many to review
    Adam> all of them within the reasonable timeframe of a weekly review
    Adam> (which I imagine would be 30-120 minutes)?  

I have over 200 projects, and goodness knows how many next actions.  I
can do the weekly review in about 2 hours, sometimes 3.

I work my way through each project, expanding it up fully, have a quick
glance, at everything. If I have been maintaining the project as I do
tasks during the week, then there shouldn't be much tinkering with
tasks. Collapse that project and move onto the next. 

I check my org agenda for the next month before I review the
projects. As I go through the projects, I therefore know what meetings,
deadlines etc I need to deal with, and whether there are days I need to
schedule to deal with certain tasks. 

Any SOMETIME projects will get the once-over and I will make a decision
as to whether I need or *want* to start to do anything on this. If not,
leave it as it is. 

However, the key thing is to make sure you are happy you have identified
the NEXT ACTION. With 324 of these to do, you are probably only going to
get 10-50 done in the next week. That means lots of these projects and
actions are going to get the quick scan from you, ensure you are happy
with the NA, and move on. Sometimes you will find that you forgot to
change the status of a task when you completed it, so you mark it as
done, decide the next action, and move on.

Don't forget that the weekly review is where you are planning your
strategy for the next week, so it is a good use of your time.

    Adam> So at very least I really need a good way of marking a huge
    Adam> chunk of them as "someday/maybe" so that they don't clutter up
    Adam> the weekly review but are still available for say, a monthly
    Adam> review.  

Well I look at ALL of my projects in the weekly review. For some of
them, I probably don't spend more than 2 seconds on them though, as they
are no brainers. 

An example.  At the moment I have

*** SOMETIME Defect Report - to include trust breakdown (need to edit the perl script) - just do last 12 months :Laptop:

This is a report I send out every 1/4, and someone once asked if we
could break it down by hospital reporters for the last 12 months. It is
probably 30-60 minutes perl programming for me, although my experience
is that sometimes a short programming task can expand! However, nobody
else has asked for it since, so when I see it I'm happy to move on. It's
been there for about 2 years.  I haven't got rid of it as I think it
would be a nice addition, and don't want to forget about it.

If you're anything like me, you probably have loads of similar projects
- people who ask for things because they think it is a good idea at the
time or ideas you have had which you don't want to forget about, but you
also don't want to do anything about at the moment. My view is that once
a week I am smart enough to decide whether I need to move on such
SOMETIME projects, because I also understand what the rest of my
workload is like, so am unlikely to make them current unless there is a
pressing need to do so.

So I agree with you about making many of them SOMETIME (or whatever todo
status works for you). You can do this in the comfort and knowledge that
once a week you will check them over, and decide if that is still the
appropriate status. I find that this is the only way to keep sane in
fact!  

The point I'm making here is that the weekly review shouldn't be a
mammoth issue just because you have lots of projects. Yes, the first
time may take a while (I fell off the GTD wagon earlier this year, and
it took me about 5 hours on the train to work my way through the whole
lot). List maintenance during the working day is vital to this.

    Adam> Hmm.  So you have WAITING and DELEGATED both meaning that you
    Adam> cannot proceed until an external action is completed by
    Adam> someone else - what's the difference?  

DELEGATED are things I can do something about - go and stand in front of
someone and ask why they haven't delivered.  WAITING is different - I
may be relying on someone's goodwill for example, or a reply from a
manufacturer, which probably needs a different way of moving it
forward. I find that it works for me.  YMMV

    Adam> And what do you mean by "not as yet decided to move on them"?

There are lots of things where, to paraphrase DA's words, 'there will be
a time in the future when I will be smarter, and able to make a decision
on this'. The example above is this sort of project - something I don't
want to forget about but I don't have the time or incentive at the
moment. However, a phone call from our paymasters asking for this in the
next report would move it onto the active list.

    Adam> Is that waiting on an internal action to be completed by
    Adam> yourself, or that you haven't decided what to do next (a la
    Adam> "stuck projects", and will at the next review?

I only use SOMETIME for something which is not yet active.  An internal
action which is to be completed by me would be marked as NEXT.  

I don't use the 'stuck project' concept myself.  Because GTD requires
checking each project regularly, you are making a conscious decision
about whether it has a NA or not.

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

As I hope i explain above, I think the weekly review is manageable as
long as you have maintained the lists through the week.  Each day, I
scan my agenda buffer, check for appointments, SCHEDULED stuff or
approaching DEADLINES, and then generate the list for the appropriate
context (i.e., in the lab that would be NEXT actions for Office and
Laptop contexts). Looking at that list, it is usually clear to me what I
need to do. At this stage it is about making appropriate choices, based
on your gut instinct, or other knowledge (such as a phonecall you may
just have had, or an email). 

I also use the 48 folders concept, so my choice of task may also be
driven by what pops out of that days folder, or what turns up in my
in-tray.

Once I have decided what to do, I do it, then mark that task as done. At
the same time I will decide what the next task on that project should
be.  Then I look at the list again.

I have tried dabbling with priorities in org-mode, but they didn't work
for me. 

In your other post you say:

    * PROJECT [#A] This is an urgent project
    ** but it's stuck since we don't have any NEXT actions yet.
    ** However we do have:
    *** SOMEDAY some ideas about what might need doing later on
    *** MAYBE here's another idea we're not sure about yet

I would deal with this in a different manner. I don't use the
SOMEDAY/MAYBE (I'll call it S&M here for brevity!) status for active
projects. If a project is active, and there are some ideas I have, I
just give them a child header with no status and no context. Then I know
they won't pop up on any of my context lists, but I will scan them in my
weekly review.

So my version would probably look something like this:

    * PROJECT This is an urgent project  DEADLINE: [XXXX-XX-XX XXX]
    ** some ideas about what might need doing later on
    ** here's another idea we're not sure about yet

In the weekly review, I would then make sure I added a NEXT action.

For this example:

    * SOMEDAY This is an unimportant project
    ** Our NEXT actions are still SOMEDAY/MAYBE actions
    ** so is it stuck or not?
    ** Technically yes, but do we care?
       since the whole project is only a SOMEDAY.
    *** SOMEDAY when the project comes alive, this becomes a NEXT
    *** MAYBE here's another idea we're not sure about yet

If the project is a SOMEDAY, then you should not have any NEXT actions
associated with it. You may have a list of actions you would take if you
decided to move on this, but until the project moves off your SOMEDAY
list, there should be no NEXT actions. Honestly.

Mine would be something like:

    * SOMEDAY This is an unimportant project
    ** this would be the first step  
    ** probably want to talk to these people
    *** Jim
    *** John
    *** Sarah

So, happy new year to you all.  Best wishes for a well org-anised New
Year!

Pete

      parent reply	other threads:[~2007-12-31 19:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-30 18:11 SOMEDAY/MAYBE vs. low priorities Adam Spiers
2007-12-30 21:10 ` Eddward DeVilla
2007-12-30 22:44 ` Pete Phillips
2007-12-31 14:44   ` Adam Spiers
2007-12-31 17:09     ` Adam Spiers
2007-12-31 17:15     ` Adam Spiers
2007-12-31 17:25       ` Manish
2007-12-31 19:01     ` Pete Phillips [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22876.1199127686@localhost \
    --to=pete@smtl.co.uk \
    --cc=emacs-orgmode@gnu.org \
    --cc=orgmode@adamspiers.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).