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.
Project or Multiple NA's Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Project or Multiple NA's

    I have, what I am guessing, may be a simple question.

    When should something be a project versus just listing multiple NA's in my tasks list and what determines whether it should be a project or multiple NA's?

    I know a project is anything that requires multiple steps to complete (and takes longer than 2 minutes) but should I take a simple project and list it as a project with multiple NA's or should I just treat them as multiple NA's and not organize it as a project?

    What determines the answer?:
    • How many NA's are involved,
    • When the due date is,
    • If there is a due date,
    • How long does it take to complete a NA, etc.

    Additionally, is it easier to track it as a project or as multiple NA's (and how do you determine this)?

    Any thoughts, suggestions, best practices, and information you provide will be greatly appreciated.

  • #2
    Not all actions are GTD Next Actions.

    GTD Next Action is immediately doable in a given context without any prerequisites.

    If you have a bunch of independent actions you do not have to construct a project from them. You can put them directly on the context lists as Next Actions.

    Actions that depend on completion of other actions are not true GTD Next Actions. In this case the Project should be defined.

    Always define the Succesful Outcome!
    Last edited by TesTeq; 12-14-2005, 10:35 PM.

    Comment


    • #3
      I only create "projects" for projects that actually need extra planning. If the steps are consecutive and I know what they are, I generally just have NA's. But if there is enough complexity to merit planning throughout most of the project or there are multiple NA's that can be completed at once, I will create a project in order to keep everything coordinated.

      Comment


      • #4
        A project is anything that takes more than one step.

        Especially if you are just setting up your system, I would err on the side of sticking to that rule. You can always relax it later, once you have established your GTD habits.

        I would be especially careful about projects that involve parallel NAs. If you have a sequence of dependent tasks -- get tire shop phone number, call tire shop, buy tires, set appointment to install tires, drop car -- there isn't much risk that you'll forget a step. If you have parallel independent tasks -- call plumber, call electrician, call mason, call town re: building permits -- keeping them together under the umbrella of a project helps make sure that they all get done.

        Katherine

        Comment


        • #5
          Originally posted by Rniven
          IWhen should something be a project versus just listing multiple NA's in my tasks list and what determines whether it should be a project or multiple NA's?
          You don't give any examples of what you have in mind, but I think generally you have to decide for yourself. For example, getting your house ready for winter may consist of several totally independent actions. That is, checking the snowblower is not strongly related to checking the furnace. Are they all next actions, parts of projects, items on a checklist? I think it depends on how you work best, and what feels most natural. For example, putting things on a checklist won't work if you don't work the checklist.

          I should mention the "pig-pog method," in which one digital reminder holds the project, the next action, and future next actions. You can find it by Googling "pig-pog gtd." It can easily handle mini-projects with a few sequential next actions. As with any of these techniques, you have to use it often enough that its use becomes instinctive, and I don't do that.

          Comment


          • #6
            good reasons to create projects

            Originally posted by pageta
            I only create "projects" for projects that actually need extra planning.
            I was glad to hear this perspective, because it made me realize I was doing something similar. That said, I think there are advantages to actually writing down every project, even if the steps are known in advance. For example, if you want to track your yearly progress, you might want to know all the projects you completed. Also, there's the "getting it out of your head" angle to GTD, which I find is greatly enhanced when I write *all* projects down, including little ones. Plus, I get to check them off! Finally, seeing the complete list of my commitments gives me information when it comes time to review, including whether I need to re-balance by moving some to my Someday/Maybe list, or whether I need to (politely) say "No" to some opportunities that enter my life.

            Comment


            • #7
              Originally posted by thornrise
              I'm curious, how do you do that?
              Keep related independent tasks together? That depends on your system. I do it with categories: every project-related task has at least two categories, for project and context. I filter by whatever view I want at any given moment.

              Katherine

              Comment


              • #8
                Originally posted by Rniven
                I know a project is anything that requires multiple steps to complete (and takes longer than 2 minutes) but should I take a simple project and list it as a project with multiple NA's or should I just treat them as multiple NA's and not organize it as a project?

                What determines the answer?
                Whether or not there's additional work to be done towards the successful outcome, which is the point of calling an outcome with multiple action steps a "project." It might be useful look at the word "project" strictly as a technical term and forget its legacy in other contexts.

                For example, I recently had "Make miso soup" on my project list. Whether it's big or small outcome makes absolutely no difference. What qualified as a project was that I didn't have the vegetables immedately at hand to make the soup. Defining it as a project tells my brain explicitly that there's an errand I need to make before the conditions to actually make the soup are satisfied. Then it's clear that I need to put the vegetables on my @Errands list. While getting the ingredients first is implicitly obvious, explicitly defining the very next action in the correct list helps eliminate drag. I don't keep looking at "Make miso soup" as a next action wondering why I haven't gotten around to doing it yet.

                I can't "make miso soup" if I don't have the vegetables. Then it's a next action. You can't do any project. You can only do next actions.

                Comment

                Working...
                X