Forum

  • If you are new to these Forums, please take a moment to register using the fields above.
Announcement Announcement Module
Collapse
No announcement yet.
How do I get next actions to play well with projects? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How do I get next actions to play well with projects?

    Iím experiencing a series of issues around organizing tasks versus projects properly. I would appreciate any feedback or advice. Not that it matters too much, but to give you an idea of my system Iím using a Moleskine large ruled notebook (the one with the hardback cover).

    1. As we know, many projects require only two or three tasks to complete. It seems wasteful to use an entire page in a Moleskine notebook (or any other notebook for that matter) to track such projects. Some options Iíve considered:
    • Track more than one project on a single page... but the problem is I would need more space in case the scope of the project changes.
    • Use Post-It notes and stick Ďem into my notebook.
    • Any additional ideas that you may have.
    2. I find that projects -- not just next actions -- belong in many context-based lists. This presents a problem because it seems that GTD calls for restricting each list to tracking either a project or next action (not both)Ŗ. For example, I created a context-based list called @Lamborghini to track anything to do with my car (a Pinto). One of my list items is ďget car serviced,Ē which requires more than one task and thus constitutes a project (I have to call the dealer/local repair guy to compare quotes, work it out with my carpooling partner, etc.). But I also have tasks, such as ďget car washed.Ē Questions:
    • Would I perhaps gain more efficiency by creating a separate list called ď@Car serviceĒ? If so, I would definitely run into the problem described in item #1 above: having to document a project with only two or three next actions.
    • Might it be better to create two context-based lists with the same name -- one for projects, the other for next actions?
    • Okay, I was kidding about the Lamboghini/Pinto thing. (I have a RAV4 (and my list is so named.)
    3. When Iím capturing stuff to my system, I find that I tend to get bogged down in thoughts of ďnow where should I put this?Ē instead of focusing just on capturing. Any advice here?
    • One option I thought of is to create a ďbrainstormĒ list that I can use as a draft of ideas and then transfer items as necessary to my system.
    • Another thing I had considered was that as I get more seriously into using my system (Iím relatively new to this), I find that I will be creating lists on an as-needed basis -- in other words, perhaps over time, my needs will help create the system.
    Once again, Iím grateful for any feedback.

  • #2
    Answers to questions 2 & 3.

    Originally posted by gernblanston View Post
    2. I find that projects -- not just next actions -- belong in many context-based lists. This presents a problem because it seems that GTD calls for restricting each list to tracking either a project or next action (not both)Ŗ. For example, I created a context-based list called @Lamborghini to track anything to do with my car (a Pinto). One of my list items is “get car serviced,” which requires more than one task and thus constitutes a project (I have to call the dealer/local repair guy to compare quotes, work it out with my carpooling partner, etc.). But I also have tasks, such as “get car washed.”
    Projects do not belong to contexts! They may belong to areas of responsibility/interest/focus (20K level). @Lamborghini is your area of focus and it should not contain any Next Actions.

    Originally posted by gernblanston View Post
    3. When I’m capturing stuff to my system, I find that I tend to get bogged down in thoughts of “now where should I put this?” instead of focusing just on capturing. Any advice here?
    It's easy. Just put your notes in your inbox and forget about them until the processing time.

    Comment


    • #3
      You absolutely do not need to use an entire sheet of paper to for each project name. You can simply create a list of projects on one page. Some projects will require additional support material, which you can create (and reuse) a simple file folder for. As you do your weekly review, scan the list of projects and pull (at least) one next action for each project on the list. Put the next action in the appropriate Context list. Then when you're in that context look at that context list. You're overthinking this.

      Comment


      • #4
        Reply to TesTeq

        Originally posted by TesTeq View Post
        Projects do not belong to contexts! They may belong to areas of responsibility/interest/focus (20K level). @Lamborghini is your area of focus and it should not contain any Next Actions.
        TesTeq,

        I'm a little more confused now. If @Lamborghini is an area of focus and should not contain any Next Actions, where do I keep the list of Next Actions associated with my car? In other words, how can @Lamborghini not be a context list based on my car?
        Last edited by gernblanston; 05-17-2008, 02:47 PM. Reason: Named header

        Comment


        • #5
          Just want to make a quick comment here as I had a similar problem.

          First, DA suggest that you have one list of Projects. It's a simple list of all your projects and what I find helpful is to group things together by Areas of Focus or the 20K level. For example, I have a Home and Car Area of Focus where I list all the projects that pertain to my house and car.

          I use a software program called OmniFocus as it helps me organize my projects into these "Areas of Focus folder.

          Second, I believe that you should only have your active projects for the week (or until your next weekly review) on your projects list. Everything else can go into your Someday/Maybe list.

          Not to steal from the Weekly Review CD that DavidCo sells but there was a specific section where they talked about how many people have many different Someday/Maybe list for all the different areas of their life. Perhaps you can have one for Future Car Maintenance....

          Third, your context really should reflect the physical item or location you must have to complete the action. In your example, @Lamborghini would only work if your NA was, "Wash Car" or "Change Oil" ect.

          However in your specific example there are many different contexts. Here is what I would have done... I have to call the dealer @Phone/ local repair guy to compare quotes @phone, work it out with my carpooling partner @partners name, take car to shop @errands etc.

          If you think about it the only one that requires @Lamborghini is taking the car to the shop...but what's needed to make that next action successful...the shop..which is the context.

          I hope I didn't confuse you to much.

          Comment


          • #6
            Originally posted by aaronmclay View Post
            Just want to make a quick comment here as I had a similar problem.

            First, DA suggest that you have one list of Projects. It's a simple list of all your projects and what I find helpful is to group things together by Areas of Focus or the 20K level. For example, I have a Home and Car Area of Focus where I list all the projects that pertain to my house and car...

            Second, I believe that you should only have your active projects for the week (or until your next weekly review) on your projects list. Everything else can go into your Someday/Maybe list...

            Third, your context really should reflect the physical item or location you must have to complete the action. In your example, @Lamborghini would only work if your NA was, "Wash Car" or "Change Oil" ect.

            However in your specific example there are many different contexts. Here is what I would have done... I have to call the dealer @Phone/ local repair guy to compare quotes @phone, work it out with my carpooling partner @partners name, take car to shop @errands etc.

            If you think about it the only one that requires @Lamborghini is taking the car to the shop...but what's needed to make that next action successful...the shop..which is the context.

            I hope I didn't confuse you to much.
            No, you didnít confuse me at all -- in fact, youíve clarified something that I think I may have misunderstood the first time I read the book: the idea that context-based lists are theoretically supposed to be based on a location. Iíve been thinking of context lists in much broader terms: more as projects.

            Iíve been using the GTD principles for some months now at work, with great success. What I do is fairly simple: in Outlook, I create a Task folder for each project Iím working on. So for example, I might have Task folders called, ďBook 1,Ē Book 2,ď and so on. Iíve read postings from people on this site and others that talk about keeping all of their tasks in the same Outlook Task folder and then categorizing them... Iíve tried that and I find itís time-consuming and crowded. My solution has worked very well and increased my productivity tenfold. Iím also a lot calmer when Iím at work. For the purposes of Outlook, I donít really need an @Computer list because Iím always at my computer. So I just organize everything by project.

            To keep to the point, I mention my Outlook system because it works very well for me. I donít like electronic organizers, so Iíve resorted to using a Moleskine lined journal for my personal GTD. But thatís where the way it works breaks down.

            At the beginning of this response, I wrote that I may have misunderstood context lists the first time I read Davidís book. Iíve been thinking of lists more as project-based than context-based. I think this is one of the issues I have with GTD. Donít me wrong -- itís changed my life for the better. Maybe this is sacrilegious, but it seems counterintuitive to me spread related tasks across different lists. It seems far more intuitive to group my car servicing into a project-based task list.

            Consider the following two sets of lists:

            Set 1:
            Project List of Next Actions: Get Car Serviced
            - Call Toyota to get info on 10k mileage servicing/estimate.
            - Call local repair shop for estimate.
            - Decide and schedule service.
            - Call carpooling partner.
            - Drop car off.
            - Pick car up.
            Set 2:
            @Phone
            - Call Toyota to get info on 10k mileage servicing/estimate.
            - Call local repair shop for estimate.
            - Decide and schedule service.
            - Call carpooling partner.
            - [Other phone-related tasks sprinkled throughout this list]

            @Errands
            - Drop car off.
            - Pick car up.
            - [Other errand-related tasks sprinkled throughout this list]
            Am I misunderstanding the purpose of context lists, or did I get it right? It seems to me that Set 1 is a lot easier to follow.

            Comment


            • #7
              Originally posted by gernblanston View Post
              No, you didnít confuse me at all -- in fact, youíve clarified something that I think I may have misunderstood the first time I read the book: the idea that context-based lists are theoretically supposed to be based on a location. Iíve been thinking of context lists in much broader terms: more as projects.
              To be precise, contexts are based on available resources. @Phone items, for instance, are calls that can be made from any phone. That's the list you look at while you kill time waiting for your flight, because you know you can do everything on it.

              At the beginning of this response, I wrote that I may have misunderstood context lists the first time I read Davidís book. Iíve been thinking of lists more as project-based than context-based. I think this is one of the issues I have with GTD. Donít me wrong -- itís changed my life for the better. Maybe this is sacrilegious, but it seems counterintuitive to me spread related tasks across different lists. It seems far more intuitive to group my car servicing into a project-based task list.

              Consider the following two sets of lists:

              Set 1:
              Project List of Next Actions: Get Car Serviced
              - Call Toyota to get info on 10k mileage servicing/estimate.
              - Call local repair shop for estimate.
              - Decide and schedule service.
              - Call carpooling partner.
              - Drop car off.
              - Pick car up.
              Set 2:
              @Phone
              - Call Toyota to get info on 10k mileage servicing/estimate.
              - Call local repair shop for estimate.
              - Decide and schedule service.
              - Call carpooling partner.
              - [Other phone-related tasks sprinkled throughout this list]

              @Errands
              - Drop car off.
              - Pick car up.
              - [Other errand-related tasks sprinkled throughout this list]
              Am I misunderstanding the purpose of context lists, or did I get it right? It seems to me that Set 1 is a lot easier to follow.
              The first issue is that neither Set 1 nor Set 2 contains Next Actions. A Next Action is immediately doable, with no dependencies. But you can't call the repair shop for an estimate until you know what work you want done, and you can't arrange alternative transportation until you know when you need it. So calling Toyota is the *only* Next Action for this project. Everything else is project support.

              Second, Set 1 *is* easier to follow if that's all you have to do, or if you're working consecutively through the car service project. (Which is why this list is project support material.) But if you have 20 different phone calls to make for several different projects, it might be helpful to have all of those phone calls in a single list where you can just crank through them. Similarly, if you have big chunks of reading to do for five or six different projects, it might be nice to have a complete @Reading list to help you decide what to read given the amount of time you have. That's where context lists come in handy.

              Hope this helps,

              Katherine

              Comment


              • #8
                Seems Like Overplanning

                That's too much work for me.

                I put this on my Project list: Get Car Serviced

                I put this on my @Calls list: Toyota re: service estimate ###-###-####
                (don't underestimate the value of the phone no.!)

                The other stuff sounds like too much work and would clutter my next action lists. I personally keep a page of notes in an ACTION SUPPORT folder with all the other thoughts or ways to clarify the initiative.

                I might put the second call (local garage) on my action list but I'm not going to put, "Drop off car" until I've decided where and when I'm going to do that. I want the flexibility to deal with changes that happen along the way and not have to renegotiate much more than my next action.

                My $0.015

                Comment


                • #9
                  it seems counterintuitive to me spread related tasks across different lists. It seems far more intuitive to group my car servicing into a project-based task list.
                  1) I want to say, that you have to find out what works for you. Hey, you may make some mistakes but do what feels best.

                  2)I'm going to reference the "Productive Talk" Podcasts that David and Merlin Man at 43Folders.com did 2 years ago AND the Weekly Review Audio CD....

                  Both of these program, David has said, numerous times, referencing concerns about spreading NA over different context list (away from the project parent), "In the 20 or so years since I've developed this program, anyone who does the weekly review never has the problem of connecting next actions to projects or vise versa."

                  I'm paraphrasing and this isn't exactly your issue. However, in the GTD book David mentions that when you decide what NA you want to take action on you can choose by the Context you're in and then decide based on priority, energy, etc...

                  The benefit may not be self evident at first. For me, it turns my 130 NA list down to 20 NA to be done @home or 30 NA's @Computer...etc. How much easier is that!

                  I used Outlook for a long time until I moved to the Mac. You're system sounds a lot like Sally McGhee's which is like GTD but slightly different words and a heavy focus on Outlook.


                  Consider the following two sets of lists:

                  Set 1:
                  Project List of Next Actions: Get Car Serviced
                  - Call Toyota to get info on 10k mileage servicing/estimate.
                  - Call local repair shop for estimate.
                  - Decide and schedule service.
                  - Call carpooling partner.
                  - Drop car off.
                  - Pick car up.
                  Set 2:
                  @Phone
                  - Call Toyota to get info on 10k mileage servicing/estimate.
                  - Call local repair shop for estimate.
                  - Decide and schedule service.
                  - Call carpooling partner.
                  - [Other phone-related tasks sprinkled throughout this list]

                  @Errands
                  - Drop car off.
                  - Pick car up.
                  - [Other errand-related tasks sprinkled throughout this list]
                  Am I misunderstanding the purpose of context lists, or did I get it right? It seems to me that Set 1 is a lot easier to follow.
                  Actually, in my system I have both! =) I think you're right on target. In your Moleskin you may just want to carry NA's with you and leave your Project Support Material or Set 1 in Outlook.

                  However, when creating your next Actions list I would structure it a bit like this...

                  @Phone
                  - Call Toyota Maintenance Department (###-####) to get info on 10k mileage servicing/estimate.

                  Wait?!?! Where are all the other steps...well, Next Actions are the physical next step that advances the project. As Katherine stated, you all that other stuff is all dependent on what Toyota tells you.
                  Here's a quick tip about small project planning...
                  For my small project I don't plan anything but the next action I need to take on it. So many thing change because of the new information you get from completing a next action. As soon as I've completed the next action I immediately process that information and create a new next action for that project...if I have the time, energy, and I'm at the write context I do it. If I'm not then the NA goes on the appropriate context list and I merge the NA with my project during my next weekly review or when necessary.
                  Here's a great example that happened to me today.

                  Project: Change Porch Lights to Energy Saving Bulb
                  NA: Find 4 Energy Saving Bulbs and take Downstairs [Done]
                  NA: Get Ladder from Utility Closet and place under first Porch Light [Done]
                  NA: Find a freaking screwdriver [Done]
                  NA: Remove Old Bulbs from Porch Light - Not Done

                  * The home builder decided to use apoxy to glue the porch lights down. Now, if I had planned that project out instead of just doing NA after NA I would of had to go back and replan and replan and then I wouldn't trust my system.

                  Instead there is a big stinkin' NA on my @email to the Home Builder on why they did this...

                  Regardless of all that chatter I just typed above, I suggest you take a 30 minutes tomorrow and just create a system for your Next Actions and use it for a couple of weeks and see what happened and what did you learn. Keep trying new techniques/software/hardware until you find what works. =) I wish you the best of luck.

                  Comment


                  • #10
                    How about...

                    Hi Gern,

                    If you are at Outlook everyday, then why don't you just print out your next actions and toss the sheet into your Moleskine. You can use your Moleskine as an "inbox" or portable capture device.

                    Remember that next actions can kick you off, but you don't have to stop there. If you pick up the phone and call Toyota, and they tell you what you need to know, then you can simply do the next thing(s) if you want to keep running. When you have gone as far as you can or want, to go, just put the next action on your list and move on.

                    Many small projects don't need to be "Planned" past some quick brainstorming; you know the steps in your head faster than you can write them down, just as long as you don't forget the project itself. What you do need is 1. An outcome on you project list so the project doesn't slip through the cracks, 2. A next action in the proper context list so that if you are knocking off "calls" you can move the project forward an inch at least, and so you know where to pick up when you leave off.

                    Best Wishes,
                    Gordon

                    Comment


                    • #11
                      A couple of random thoughts on this topic:

                      First of all, I heartily concur with the comments about only writing down your next Next Action for any given project. I'll bend this sometimes and have multiple NAs for a project, under two circumstances:
                      1. They don't depend on each other. For example, if I have to call Joe about project XYZ and I have to update the XYZ Wiki, the actions can go on my @Call and @Computer lists as long as the Wiki update isn't dependent on what Joe tells me. In this case, I limit myself to one NA per context, so that when I'm making phone calls, I only have one choice from my @Call list for the XYZ project.
                      2. If I'm waiting for things from multiple people to move a project forward, I can put multiple items on my @Waiting list.

                      I've found, for my work (writing, photography and Web stuff) that mapping out the chain of possible future NAs I might take is usually not helpful. For example, I might list out a whole chain of actions that revolves around taking my Scion to the Toyota dealer for an oil change. But if I call the Toyota dealer and the next appointment they have isn't for six months, then my new NA becomes "Find a new dealer to service the Scion" and all that other planning goes out the window. So, when I brainstorm out that stuff, it goes in my project support folder for future reference, but not on my NA lists.

                      The other problem with maintaining project/next action linkages is that, if your tool provides any friction at all in terms of managing the linkage, you'll tend to resist doing it. My GTD system (using the now-orphanware NoteStudio Wiki) does a fair job of maintaining these links, but only because I've created a structure that automatically builds several kinds of indexes to let me see my lists in different ways. On the other hand, I found with both outliner-based systems and the NetCentrics GTD addin for Outlook, that maintaining the linkages was too much effort. And, too, if you can't tell from looking at your NA which project it goes with, that ought to be a warning sign that you don't have a good handle on what's on your project list.

                      Comment


                      • #12
                        Originally posted by wordsofwonder View Post
                        I've found, for my work (writing, photography and Web stuff) that mapping out the chain of possible future NAs I might take is usually not helpful.
                        Instead, mapping out the chain of (almost) definitive future, uh, milestones / sub-projects / deliverables, can be an awesome thing (for larger projects at least).

                        Comment


                        • #13
                          Originally posted by Cpu_Modern View Post
                          Instead, mapping out the chain of (almost) definitive future, uh, milestones / sub-projects / deliverables, can be an awesome thing (for larger projects at least).
                          Very true...and I often do that. I guess the point I was trying to make was that it seemed the original poster was getting bogged down in mapping out the future at too low a level of focus. I think that's where the trap lies.

                          I have about a dozen higher-level "meta-projects" on my list right now, each of which could (over its execution) spawn several projects. Having those longer-term goals mapped out definitely helps me execute on them - and, in fact, I've brought several of them to completion over the past few years.

                          But there's a difference, I think, between that and "map out the next 10 possible NAs that it might take to get my car's oil changed."

                          Comment


                          • #14
                            possible confusion of terms...

                            I think that there may be some confusion of terms. Just how close to GTD my definitions are, I don't know, but I am going to give you My capsule summary of terms for what it is worth....

                            Calendar= Basically a reference list of ordered dates with known date-related info such as deadlines, lead times, and appointments and other time-related information (holidays). Can also be a communication device and tool for looking into the future.

                            Context or next action lists= Lists by location or other limiting factor (such as a machine or a person) of activites that are reasonably specificied and that for you are a single action and that will move a defined project along or just have to done in your life. Sometimes these refer to or include a checklist.

                            Project List= The names of each project you are currently taking active steps on plus a brief description of desired outcome, and possibly purpose and due date to which you are commited. Some people have these in order by area of focus. This is not necessary but may have merits for some.

                            Currently = intention/hope/wish/necessity to take at least one action between your weekly reviews + probable opportunity given your various resources (including time not allocated to pinned down commitments and routine tasks). So get these on your calendar and review it before you make your action lists.

                            Project Support Page and/or File:

                            Support page = rough or summarized information that you need to have handy to manage your project or think your project through or carry out your project's actions, this can include lists of people, stuff, specs, ideas, timeline etc. Why might you need this? Your next actions might be occuring in various contexts and you might want to have "specs" at hand (phone numbers, sizes, names of key players). Also, as you complete one action on an active project you should create the next one and put it on a context list. You might need to refer to a mini-outline of your project to figure out the n/a. I find I need to do this in projects that are novel to me or have a lot of details. Remember that sometimes the n/a is "analyze pros and cons" or determine the n/a, not to worry, just be sure to write this down in the context list that corresponds to where you think can perform this.

                            If you are a student, an annotated syllabus and course bibliography is a great support page. But you will need to work with this with a calendar.

                            Support File = could be any combination of a folder, a note book, a textbook with sticky notes, a whole drawer if need be, or a computer file.

                            Work style and situation(s) will help you decide if you should just have all the active projects on a list, and/or a single page for each (or most) with some notes. Some people do not use a single page per project but refer to their support file. Where you are most of the time and the kind of informtion you need to create your description of your n/a will be factors in what you choose.

                            Sometimes the support page is a checklist.

                            SDMB Project List: List or list of projects in various states of description and actuality. What they have in common in that no action is planned at this time and you will not consciously plan an action, if you plan any at all, until the next weekly review. There will be a huge variation in degree to which these are described and defined. Some are projects you have started and really worked out in detail but you are settting them aside for some reason, possibly with a calendared note as to when you want to do something on them. Some are just little wishes or wisps of ideas but you want to look at them and mull them over. Some people divide these into real projects that are underway but they won't be taking an action on until a specific dates (SomeDayForSure) and those that are still wishes or even ones you hope might go away.

                            I hope this helps and I hope that if someone defines these more usefully they will feel free to commnet.

                            Comment


                            • #15
                              Fog has cleared re context v. projects, but now murky on project support

                              When I started this thread, I misunderstood the definition/purpose of a context list. My mistake, according to the responses here, was in forcing the project itself to be the context.

                              Well, Iíve seen the light. At least, dimly. (Thank you.)

                              Thereís another issue, however, that I havenít really been able to wrap my mind around.

                              I mentioned earlier that I have implemented, very successfully, an Outlook-based GTD system at the office. When I went back and studied my system through the prism of this thread, it occurred to me that Iím probably not using context lists as theyíre strictly defined. If I understand the definition of ďproject supportĒ lists (thank you Jamie Elis), I think Iím employing those in the form of checklists.

                              Hereís my method, in a nutshell. As a technical writer, I often work on five or more projects (manuals) at a time. Each of these documents has a myriad of details that require tracking. Most (if not all) are non-sequential; there is, 98% of the time, no specific ďnext actionĒ -- itís just a task. It can be done now, in fifteen minutes, or anytime before the end of the project. It doesnít usually matter.

                              For the two percent of project-related tasks that need to be done in a certain order, I tend to place them in a hierarchical order in my Outlook task list. I get them out of the way.

                              To track tasks for each project, Iíve created a single task folder for each project in Outlook. I check off each task as I complete it. When a new task pops up, I plug it into the list appropriate to the project. At the end of the project, I know Iím done because Iím staring into an empty task list.

                              This method works for me brilliantly, and I can honestly say that I have increased my productivity about 500 percent since implementing it.

                              It would not make sense for me to separate all of these tasks into ďcontext-specificĒ folders (that is, if you define ďcontext foldersĒ as strictly as has been done here). There are, of course, cases in which context does apply. But those are rare, especially with most of my projects lately -- since I am currently working with overseas engineers, I work at a single workstation almost 100 percent of the time.

                              Given both the success of my current method and the realization Iíve had about context, Iím now puzzled: how might David Allen characterize these task lists? Are they indeed ďproject support checklists?Ē Is it normal for such lists to be employed more than context-based lists? Or would you consider them ďcontext-based lists?Ē (@Manual1, @Manual2, etc.)

                              Or, does it really even matter?

                              Comment

                              Working...
                              X