• If you are new to these Forums, please take a moment to register using the fields above.


No announcement yet.

Disconnect between Projects and Next Actions

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by BrianK View Post
    I will tell you from my experience that when I'm doing a weekly review weekly, that pulls it all together. If the last time that you made a mental connection between a project and a next action was within the previous week, when you look at the next action, your mind will (in almost all cases) make the instantaneous connection with the project.
    I've been doing very regular weekly review, weekly, and yet I still need the connection of actions to projects or I get lost. Just reviewing the projects once a week isn't enough for me. Fortunately Omnifocus keeps the links easy to see and also easy to hide if you choose to.


    • #17
      Tweaking the GTD system.

      Originally posted by Oogiem View Post
      Tweak my GTD system has for me become almost an area of focus. I keep getting more and more refinements and better and better at using it the longer I work in this mode.
      For some people tweaking the GTD system is the only project managed by their GTD system.


      • #18
        Are next actions project actions?

        First off, excellent topic. I've been struggling with this exact same question. I actually solved it using Toodledoo. I created each new project as a folder. I then brainstormed a list of actions (project plan) which I added as tasks to this folder. For actions that could be performed right away, I starred them. The "starred" list then became my list of next actions. This is a similar solution to the forum member that used Onenote. Thus, I had the holy grail of a list of next actions tied to projects.

        However, I am slowly coming to the realisation that Next Actions are not necessarily the same as project actions, an assumption that seems to be present in most of the posts on this topic.

        Eg, I have to organise a birthday party (for yours truly). Now my project plan contains actions such as:

        "Confirm attendee availability"
        "Find venue"
        "Book venue"

        None of the above project plan steps are physical, granular actions. "Confirm attendee's availability" is actually a next action of "Call Mike, Sue, Fred to see if the 15th March suits". "Find venue" is "Speak to Bob about recommending his work Christmas party's venue"... etc.

        My reasoning behind separating next actions and project actions is as follows:
        1. Often you won't know all of the next actions, as they may change. Eg "Book venue" actually may have a Next Action of "Call Clapham Grand to book" as it's dependent on the previous "Find venue" step

        2. If you define next actions with the right level of granularity as required by GTD - i.e., so that you don't need to even think about them - your project plan (list of project actions) will become too detailed and cumbersome if you use NAs to represent it.

        I think part of the disconnect is that people view the perfect Next Action list as a chain with interlinked actions that make up a project from start to finish - a sort of chronological to-do list. So you complete the current 'starred' Next Action X, then you 'star' Next Action Y and complete, then you 'star' Next Action Z and complete, and so on. I don't believe that GTD intends NAs to be a roadmap to be continuously followed. I think you complete the NA you have for a project to kick start,and continue to work on that project (without creating or ticking off NAs the whole time) and then at the end of the day, and latest as a part of your weekly review, you look over the project plan, and identify if there are any NAs to move it forward.

        So for my birthday example, I'll have an NA of "Call Mike, Sue, etc to determine availability" sitting on my NA list. When I get to that item on the list, I'll go ahead and call them. If the response is positive, I'll research venues. Let's say I find one, just as the boss walks in to have an informal chat for an hour, then I go to lunch, then I have to deal with an urgent query when I return to my desk. By the end of the day, I'll review my projects, and add a NA of "Book Clapham Grand" for the Organise Birthday project, to identify where I left off and what still needs to be done.

        I really think this is an easier process than trying to brainstorm all of the NAs, as in next physical granular actions for a project (which may change) and tracking as I go through them, ticking off lists.

        Sorry this turned into a long rant, but just putting it in writing has been very useful for me.


        • #19
          That's why they are called Next Actions. They are actions, clear and visualizable, not just steps as they would occur in a project plan. The "Next" stands for *only next*, nothing beyond. Planning an entire project to the granularity of next actions would be (in most cases) counterproductive. It's in our nature to be adaptive rather than following a strict plan. (Project plan is not a computer program; it's rather a direction as we thought while planning the project.)

          I may have an action such as "write to X re ...", and in the moment I may decide to call the person instead of write. Or if I bump into somebody else who may be equally relevant, I may as well talk to that person regarding that thing. But in case none of these things happen, I have a perfectly clear action on my lists, which will get done as I thought originally. This would be very difficult if I just had a to-do item like "handle ...".

          Regarding the disconnect between projects and actions, some examples of actions and their corresponding projects would be nice for us to see where is this disconnect arising. Typing/writing a little more detail in the action is usually easy and enough of a clue.



          • #20
            I agree. The "next" in next action is important to remember. I believe that next actions should be decided as close to their execution as possible. So an NA is the next physical action you intend to perform the very next time you are in the proper context. Otherwise you run the risk of filling up your next action lists with obsolete decisions, which will cause you to lose confidence in your lists and stop using them.

            This also can help to reduce the purported "disconnect" between next actions and projects, since you reduce the time between the project planning and the associated next action decision.


            • #21
              Originally posted by matt156 View Post
              My reasoning behind separating next actions and project actions is as follows:
              1. Often you won't know all of the next actions, as they may change.

              2. If you define next actions with the right level of granularity as required by GTD - i.e., so that you don't need to even think about them - your project plan (list of project actions) will become too detailed and cumbersome if you use NAs to represent it.
              I think that all depends on the types of projects you work with and the time frames.

              Relating to your number 1:
              In my world next actions hardly ever change once they are determined. I've been working a single project and its associated next actions for over 10 years now. The initial planning and project documentation I did has stayed basically the same through that whole time.

              I will agree that for some projects the actions will change as I do them. For example I had an idea that I'd like to do a 5-7 year rotation of crops on our 2 main fields. However 3 years into the rotation it became obvious that every time we plowed we plowed up more rocks so the project got stopped and we put both fields back into permanent pasture. Crop rotation is inappropriate for our farm but we'd have never known that until we tried. That sort of change is very rare in my world. For me the critical part of that project was the full documentation of why it got stopped and scrapbooks of the issues. No reason for the farmers who come after me to have to re-learn the lesson I just learned. Unless I document it they are likely to make the same mistakes over and over again.

              For number 2:
              In my world next actions to move projects forward can be separated in time by months or years or can take months or years to complete. Once you have done the thinking about the project during the natural planning model you have to capture it. Most of that thinking is actually a clean next action and no they don't take up much space in project support. In fact it's critical that they be stored there so that someone else can pick up the projects where you left off.

              Examples are a project to clear and re-plant the lower front field. Actions include burn brush pile from clearing dead trees, move rocks to rock wall from between trees, a sub project of plowing, land planing, planting and marking the new field where the detail actions are not defined yet and so on. In that case some are well defined and some are just mini-projects waiting for us to move forward. Now we haven't moved forward on this project for several years because the combination of time, weather and help avail to burn the brush pile hasn't been there. But there is no reason to lose the thinking that went on even to the description of the new plants to use so that once we do get this going we can move forward faster.

              Even my most complex projects can typically fit all the next actions and mini-projects on 2-3 sheets of paper. That is not too much to keep in a project plan at all.


              • #22
                Originally posted by invisik View Post
                I find a huge disconnect, between the Projects and the child Next Actions. I having trouble getting into having the Next Actions sitting there on their own with no real big picture of what they are for.
                I've been struggling with this same concept myself. I just posted a similar question, but as a separate thread since our situations seem to differ.

                In your case it seems like you're mapping out as many Next Actions as possible ahead of time, instead of taking this approach:
                1) There's one action defined. Do it.
                2) Analyze next action based on the current situation, list it.
                3) Go to step 1.

                But as others have pointed out, trying to plan with that much granularity so far ahead must reduce your flexibility -- or force you to rewrite your planned actions list frequently.

                Have you been using this system or is this just the planning stage? If you've been using it, how would you say that approach helps? (if it does?)


                • #23

                  In your estimation, how has the ability of Omnifocus to "see" NA's by both Context and Project helped in this area?

                  As I have mentioned elsewhere, I am contemplating testing Omnifocus on an iPod Touch and (soon) on an iPad. Meanwhile (and for now) I am using Outlook 2007 and a Blackberry, in conjunction with a small, Junior-sized Levenger Circa notebook (which I would still use, even if I switched digital applications.



                  • #24
                    Originally posted by rdgeorge View Post
                    In your estimation, how has the ability of Omnifocus to "see" NA's by both Context and Project helped in this area?
                    As I work my lists I can easily flip back and forth between seeing the action in context, and also seeing where that action fits within my entire project plan. If I'm at my mac it's a set of hot keys to see where an action is in the project view and vice versa. I can keep track of projects more easily and also see what's coming up. Working by context reduces the time to re-think when I switch gears but there I times I really have to work by project and for that seeing the actions in order in project helps.

                    Again though, I put nearly all my project planning into Omnifocus. There are very few where I have outside OF support materials.