Project or Multiple NA's

  • Thread starter Thread starter Rniven
  • Start date Start date
R

Rniven

Guest
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.
 
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!
 
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.
 
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
 
Rniven said:
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?
Click to expand...

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.
 
good reasons to create projects

pageta said:
I only create "projects" for projects that actually need extra planning.
Click to expand...
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.
 
kewms said:
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
Click to expand...

I'm curious, how do you do that?
 
thornrise said:
I'm curious, how do you do that?
Click to expand...

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
 
Rniven said:
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?
Click to expand...
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.
 
I'm activating this discussion here. David Allen sees the projects as an anchor so that no open end is lost when the (last) next action is checked off. On the one hand, I understand the sense of this definition. On the other hand, I find it tedious to run projects just for the sake of the anchor. In addition, I would like to have only the more complex projects listed as projects. Moreover, I don't consider the anchor necessary because I never check off an action without thinking about it. Rather, checking off is just an option next to renaming to the next action. I also don't use the pig-pog-method for the same reasons.

What's it like for you guys?

Translated with www.DeepL.com/Translator (free version)
 
One idea might also be to keep two lists: "Projects" for more significant undertakings that require more planning and control. "Anchors" so that uncomplicated projects with multiple actions don't get lost.
 
RomanS said:
One idea might also be to keep two lists
Click to expand...
I do this in my system. I have a paper projects lists with control sheets for each project.

I have a list in my list manager called Quick Wins, where I place these "Anchors". This lightweight list can have DLL statements in the notes and a name in the reminder field.

For two or three next actions for a project, I used to list them separated by semicolons in the order they needed to be completed, placing the item in the appropriate context list for the first action. When the first part was completed, I removed the first part and moved the NA to the appropriate context list for the next step (or marked it complete if it was the last action). I found that this left some ambiguity as to what the actual outcome was (in some cases).

Clayton

Me: I have a fear the floor is lava.
Therapist: walk me through it.
Me: are you insane?
 
I like to use the bullseye emoji on my Mac as my shorthand for DLL. It's the goal or bullseye of what I want to get done. I assigned a text shortcut via the System Preferences>>Text panel. Whenever I type the phrase .goal, it'll immediately replace it with the bullseye emoji.
 

Attachments

  • Screen Shot 2022-10-23 at 14.21.04.png
    Screen Shot 2022-10-23 at 14.21.04.png
    26.4 KB · Views: 29
Last edited:
Wilson Ng said:
I like to use the bullseye emoji
Click to expand...
I created the exact thing right after mlb (i'm makin' like a baby and heading out!) and ssh (Start Shakin' !) and omw (On my way! )
This thought was a

Thanks for the tip.
Clayton

How harmful overspecialization is; it cuts knowledge in 1 million places and leaves it bleeding - Isaac Asimov in Foundation
 
You must log in or register to reply here.
Top