From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pete Phillips Subject: Re: SOMEDAY/MAYBE vs. low priorities Date: Mon, 31 Dec 2007 19:01:26 +0000 Message-ID: <22876.1199127686@localhost> References: <20071230181116.GE20947@atlantic.linksys.moosehall> <26163.1199054673@localhost> <20071231144414.GM20947@atlantic.linksys.moosehall> Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J9PtG-0004UL-39 for emacs-orgmode@gnu.org; Mon, 31 Dec 2007 14:01:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J9PtF-0004Sz-AG for emacs-orgmode@gnu.org; Mon, 31 Dec 2007 14:01:33 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9PtF-0004Sl-5l for emacs-orgmode@gnu.org; Mon, 31 Dec 2007 14:01:33 -0500 Received: from mailhost.smtl.co.uk ([193.131.77.174]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J9PtE-00014h-0F for emacs-orgmode@gnu.org; Mon, 31 Dec 2007 14:01:32 -0500 In-reply-to: Your message of "Mon, 31 Dec 2007 14:44:14 GMT." <20071231144414.GM20947@atlantic.linksys.moosehall> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Adam Spiers Cc: emacs-orgmode@gnu.org >>>>> "Adam" == Adam Spiers 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