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.
Keeping NA List in Sync with Projects Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Keeping NA List in Sync with Projects

    I've only been using the GTD process for a few days now, but already I'm noticing an improvement in my comfort level with the things I'm doing. It's great to be able to see, at a single glance, all the balls I've got in the air, and all the things I could be doing right now.

    I've got a question about how people manage "Next Actions" that are attached to projects. Having a next action for all of your projects seems like a great idea, but once I've completed that action, then what? It seems to me that ensuring every project has a next action is a task for the Weekly Review, but I find I don't want to wait until then to move forward.

    Here's an example: one of my projects is "Create program X". The next action associated with that project is "Define potential inputs and outputs for program X". Once I complete that task, I find myself thinking if there's something else I should be doing on that project, and if there is, I add it to the NA list.

    This process is functional thus far, but it feels kind of clumsy. Does anyone have any better suggestions on keeping my NA list in sync with my projects?

  • #2
    NA's

    Define the NA(s) at the point of completing the previous one. If its a priority now or takes less than 2 mins do it. Then define the next one. Think of an NA as a stake in the ground so you know where you are with your project next time you look at it.

    Comment


    • #3
      How do you synch up or link projects & next actions? Your mind does that and no software or artificial intelliegence (yet) will do it for you. I'm paraphrasing David here and I believe it's true.

      From my experience, most of the time the next action is obviously tied to the project. Example, if a next action is "Surf the web for new tire information" your mind will go "oh, yeah that's the 'New tires on car' project".

      One technology solution is the Find feature - e.g. Palm or Outlook. For me, that synchs up projects & next actions well. Find "tires" and I've got my project and next action and maybe even a few other trigger reminders.

      I've seen many thoughtful people describe more complicated (to me) solutions, but I really wonder if the effort vs. payoff is worth it. But I'm attracted to the GTD methodology largely because of the "lazy" aspect, "how to get as much done with as little effort as possible".

      Mark

      Comment


      • #4
        dgorley, in my experience this is one of the most frequently asked questions about implementing GTD. The answer is dependent on what tool(s) you use to maintain your lists: your choice of tool will dictate a lot of what you have to do to keep actions and projects synced. There are many approaches that have been discussed at length on the forum, such as the projects-as-contacts method which uses Outlook.

        If you are not yet committed to a tool, you may want to search the forum to read about the many ways of syncing projects and actions with different tools. If you are committed to a tool, you may want to search on the name of the tool to read about how other people implement GTD with that tool.

        I too find maintaining separate projects and actions lists clumsy. It is natural to think of actions as subordinate to projects, just as David Allen in the book describes outlining a project using Microsoft Word. There are much better outliners than Word, though -- including some specifically designed for projects and actions. I use an outliner that also shows the actions, which are at the bottom of the hierarchy, in a separate context-based NA-list view. There is no need to sync projects and actions since the NA lists are just a different view of the same data. The outlining tool for me eliminates the tedious aspect of syncing projects and actions, frees me to think of my projects at a higher level much more easily, and does not constrain me to have only one NA per project. Most importantly, it does not require me to maintain the connections between projects and actions in my head.

        Comment


        • #5
          Originally posted by Mark Jantzen
          How do you synch up or link projects & next actions? Your mind does that and no software or artificial intelliegence (yet) will do it for you. I'm paraphrasing David here and I believe it's true.
          How can you know that "no software will do X" unless you have personally investigated every piece of software out there? And kept up with that investigation because software development is an constantly changing landscape. There is no logical reason to believe in universal negatives, especially in the constantly-changing landscape of software and technology development.

          I have used at least two software products that will sync/link projects with actions for you so that you don't have to do it in your mind. I have read about a third here on this forum. Not everyone may want to use them, but they do exist.

          Comment


          • #6
            The way that I overcame this very thing was I stopped associating Next Actions with "To Do's". I came to the realization that rather than To Do's, Next Actions were simply reminders of what the next physical action is to move something forward. I believe that is an important distinction, and once realized, will help you get past the need to "sync" in some sort of artificial fashion all of your projects and their related NA's.

            Using your example: one of my projects is "Create program X". The next action associated with that project is "Define potential inputs and outputs for program X". Once I complete that task, I find myself thinking if there's something else I should be doing on that project, and if there is, I add it to the NA list.

            The time that you would need to figure out what the next action is (the "something else I should be doing") is when you stop working on project "X" and need to put a stake in the ground to remind you where you left off, or you could just catch this at the weekly review.

            You wouldn't necessarily, upon the completion of "Define potential inputs and outputs for program X", stop what you're doing, think of the NA, write that NA down and then keep working... Instead, you'd just keep working.

            When you reach a stooping point, you'd either:

            1) Put the project aside and move on to something else (and catch the NA at your weekly review), or
            2) at that point think of what the NA is and write it in the appropriate list as a reminder for when you pick up the project again to start working.

            At least, that's how I'd do it.
            Last edited by jkgrossi; 10-06-2005, 08:09 AM.

            Comment


            • #7
              Originally posted by andersons
              How can you know that "no software will do X" unless you have personally investigated every piece of software out there? And kept up with that investigation because software development is an constantly changing landscape. There is no logical reason to believe in universal negatives, especially in the constantly-changing landscape of software and technology development.

              I have used at least two software products that will sync/link projects with actions for you so that you don't have to do it in your mind. I have read about a third here on this forum. Not everyone may want to use them, but they do exist.
              Well, I think that what DA means is that he doesn't believe that the technology exists currently that can do the job as elegantly as the human brain.

              Even though the software may exist that is capable of accomplishing the task, it's still more cumbersome that just using your brain to do the job...

              I think that's the spirit of what Da was trying to say.

              Comment


              • #8
                Originally posted by jkgrossi
                Well, I think that what DA means is that he doesn't believe that the technology exists currently that can do the job as elegantly as the human brain.

                Even though the software may exist that is capable of accomplishing the task, it's still more cumbersome that just using your brain to do the job...

                I think that's the spirit of what Da was trying to say.
                But DA has also said that you should get things out of your brain and into a trusted system whenever possible.

                As I see it, "keeping NA list in sync with projects" means making sure that you know where you are with each project and what you need to do to move forward. But that's really two different tasks. The first is planning: actually deciding what the actions required to complete the project are. And you're right, the human brain is the best tool for planning.

                But the second task is housekeeping: making sure that the results of your planning are captured somewhere that allows you to find them again. There are lots and lots of tools that can (and should, IMO) handle the housekeeping component.

                So many, in fact, that I have trouble understanding why this question keeps coming up. IMO, if "syncing tasks and projects" is difficult, there is a serious problem with your system.

                All you're doing, really, is creating an outline. The projects are the top level, subprojects are the second level, and next actions are the bottom level. Thus, you need a tool that lets you
                * collapse the outline so that you only see the top level, also known as the project list
                * expand each individual project so that you can see the actions associated with it
                * sort the next actions by other criteria, such as context or date, without losing their association with their parent project

                Note that I'm using the term "outline" in its most general sense. You can actually capture the structure however you want, from a formal outline in a word processing file to post-it notes stuck to a wall. The important point is that the entire structure, including the relationships between projects and actions, must be captured by your system. If it isn't, the system can never be trustworthy.

                Katherine

                Comment


                • #9
                  Originally posted by kewms
                  The important point is that the entire structure, including the relationships between projects and actions, must be captured by your system. If it isn't, the system can never be trustworthy.

                  Katherine
                  I don't know if I agree.... capturing the entire structure in your system may make it easier to review, but I don't think that it necessarily makes it more trustworthy. I don't link them as you describe, and I trust my system completely (and rightfully so).

                  I know that at least once per week, I'll review my projects and make sure that each one has an action associated with it. If an NA gets completed during the week, and a subsequent NA isn't created on the spot, I don't fret over it (i.e. it's off my mind) because I know that a NA will be created at the very least during my weekly review.

                  So, I don't necessarily see the need to "link" projects and tasks via an outline. In fact, I think that I'd find this level of structure burdensome.

                  In my opinion, the more you try to structure something, the more you restrict it. My system would move way too slow for me if I had to maintain the links as you describe.

                  Jim
                  Last edited by jkgrossi; 10-06-2005, 09:55 AM.

                  Comment


                  • #10
                    Originally posted by jkgrossi
                    I know that at least once per week, I'll review my projects and make sure that each one has an action associated with it. If an NA gets completed during the week, and a subsequent NA isn't created on the spot, I don't fret over it (i.e. it's off my mind) because I know that a NA will be created at the very least during my weekly review.

                    So, I don't necessarily see the need to "link" projects and tasks via an outline. In fact, I think that I'd find this level of structure burdensome.
                    I guess I wasn't clear, because it sounds to me like your system does *exactly* what I describe. You clearly are able to keep track of what your projects are, and the status of each. If you can do that, your system works, regardless of what the implementation actually looks like.

                    Katherine

                    Comment


                    • #11
                      Well, that's why I wasn't *sure* if I agreed .

                      It *sounded* to me like we were saying the same thing... (and I had a nagging feeling in my gut that we were ). I just wanted to be clear that IMHO an actual hierarchy wasn't necessary.

                      Others mileage may vary...

                      Jim

                      Comment


                      • #12
                        I think that projects have to be reviewed more often than just weekly in order to do the proper planning. There may be one next action, there may be simultaneous next actions. There may be next actions that you can do today that you couldn't do yesterday. Thus I try to review my projects at least as often as I progress on them. In other words, if I work on it every day, I review it once a day to make sure I'm doing everything I can be. But if I work on it once a week, then I only review it once a week. So I guess you could say, every time I finish taking action on a project, I do a quick review to make sure everything is in order for the next time I come back to it.

                        Comment


                        • #13
                          Originally posted by kewms
                          So many, in fact, that I have trouble understanding why this question keeps coming up. IMO, if "syncing tasks and projects" is difficult, there is a serious problem with your system.

                          All you're doing, really, is creating an outline. The projects are the top level, subprojects are the second level, and next actions are the bottom level. Thus, you need a tool that lets you
                          * collapse the outline so that you only see the top level, also known as the project list
                          * expand each individual project so that you can see the actions associated with it
                          * sort the next actions by other criteria, such as context or date, without losing their association with their parent project
                          Beautiful post. Wow.

                          I think the syncing question comes up because the true hierarchical structure of actions and projects is not made explicit in GTD. If you follow the book, there's a list of projects. And several separate lists of NAs. So for a beginner, you look at your long list of projects and longer list of actions and don't see all the relationships. (Or at least, some people might, but other people don't.) You can even look at an individual NA on your list and wonder what the heck it's about, if its relationship to its parent project isn't immediately obvious in your mind. If the connection IS obvious, it's because you remember it -- it's in your head.

                          It's true that you can maintain these separate lists, which do not explicitly or visually show the structure, and if you keep reviewing them, your mind WILL create the structure for you. The brain's learning mechanism is essentially to create hierarchical structure. And you may help your mind out by using naming conventions, codes, symbols, etc. to create and remember that structure more easily. But the structure visualized in the expanded outline view Katherine described will exist only in your mind.

                          But if you make the structure explicit by writing it down, it doesn't restrict you. (If you don't like the word 'structure,' maybe think of 'relationships.') The structure already exists; you're only making it explicit and visual and therefore easier to remember. You're just writing it down.

                          So why write it down? Well, why write anything down? Writing down the structure has a similar benefit to writing down anything else, like a list of stuff that's on your mind. Writing things down actually encodes a stronger, more organized memory. And the written reminder serves as a trigger to recall the previously encoded memory. Without the encoding and trigger, you need a lot of rehearsal to remember stuff.

                          Therefore I think that the expanded outline view Katherine describes adds value to GTD and takes it to the next level (literally -- pun not intended!). If it's good to get all your commitments down in lists, rather than keeping them in your head or in scattered physical reminders, then why isn't it good to get the structure of projects and actions down visually in one place too.

                          And yes, there are many ways to visualize hierarchies. Outlines are just compact and familiar.

                          Comment


                          • #14
                            Originally posted by andersons
                            Therefore I think that the expanded outline view Katherine describes adds value to GTD and takes it to the next level (literally -- pun not intended!). If it's good to get all your commitments down in lists, rather than keeping them in your head or in scattered physical reminders, then why isn't it good to get the structure of projects and actions down visually in one place too.
                            Thank you for the kind words, but please remember one of the points you deleted: it doesn't matter how you capture the structure, as long as you do. Any system that reliably captures and retrieves the information is fine. That includes stacks of index cards and other tools that don't look like hierarchical outlines, but turn out to capture the same information.

                            I emphasize this point because I've seen so many posts obsessing about tools. Though there are many excellent tools out there, the One Perfect System doesn't exist, and looking for it can easily get in the way of getting things done.

                            Katherine
                            Last edited by kewms; 10-06-2005, 06:57 PM.

                            Comment


                            • #15
                              Originally posted by kewms
                              . . .please remember one of the points you deleted: it doesn't matter how you capture the structure, as long as you do. . .That includes stacks of index cards and other tools that don't look like hierarchical outlines, but turn out to capture the same information.
                              Yup. I thought I got it with the last line "there are many ways to visualize hierarchies. Outlines are just compact and familiar."

                              And my point was that you can capture and retrieve the structure entirely in your mind, without any external tools, but it's advantageous to write it down somehow. I'm making a case for the usefulness of visualization.

                              I agree that the most important thing is to capture the structure somehow, and that the traditional outline is not the only way. I might add that some people I have taught just don't see relationships when they look at an outline, but will see them readily if I use boxes and arrows. Many people are comfortable with outlines, but some people are not.

                              However, I don't agree that the how doesn't matter at all. In 10 years of teaching, I have seen huge differences in learning and memory of depending on the visual structure of information. In one class, I taught 6 different ways to organize information, as well as how to determine which way(s) worked best for which kinds of information. (I didn't invent those 6 ways, BTW. I'm sure there are many more.)

                              Originally posted by kewms
                              I emphasize this point because I've seen so many posts obsessing about tools. Though there are many excellent tools out there, the One Perfect System doesn't exist, and looking for it can easily get in the way of getting things done.
                              Yes. But not all tools help you do the 3 things you listed -- collapse the outline for a project list, expand the outline to see project-action relationships, and show you actions by context. Some tools really help with this housekeeping, others don't. The ones that don't, IMO, are not well suited to GTD and cause more obsessing than the ones that do. (Not to say they cannot be used and sometimes have to be.) People do have legitimate problems with tools not being suited for the information they want to track. For me, the value of changing my tool was immense. I really did get more done with less stress.

                              Obsessing about tools can surely be a means to avoid work, but don't people know that even while they obsess? Do people really believe that a perfect tool will help them get more done? Are we so in the dark about how unproductive our tools can make us? That would be ironic! If not obsessing about tools, wouldn't we be obsessing about something else or finding other means to procrastinate? (Like organizing other stuff, not just project and action information.)

                              I kinda think of GTD as being a bit obsessive in general. Collect everything, process everything -- even if it takes you 2 days initially -- keep everything organized, review. . .

                              Comment

                              Working...
                              X