How do you know a next action is going to be a project? What if you finish that NA and find out that another NA would be required to finish it? Do you go to the trouble of making it a project and tracking it or do you simply do the next NA after the original and don't track it is a project?
Quick question about NAs and projects
- Thread starter AdamB
- Start date
I think there're not too many NAs on their own without a project. But I'm usually too lazy to assign a new project for "small" next actions. Maybe that's not the right way but I'm ready to change that if there're any arguments. When done I just assign a new Next Action and put it into the system.
Regards,
Eugene.
Regards,
Eugene.
I
Ivy
Guest
If I remember correctly from the book:
Any NA that's lingering on your list should be evaluated as a project. Say you have a NA "get PO box" that just doesn't seem to be getting done. That's because it's actually a small project with actions like: "Find nearest post office" (@Computer), "Call for rates and sizes" (@Phone), "Discuss the kind of box you need w/ spouse" (@Agenda), "Go to post office and get box" (@Errands), and so on.
That said, my impression from the book was that these kinds of small, obvious projects don't have to be tracked as a separate project folder (file/memo/whatever). Because they have such a discrete and obvious list of steps, you just need to come up with the real NA ("Find nearest post office" @Computer) and place it on your list. When you finish that, you can immediately come up with the next obvious NA and add it. This works especially well if your system has a way of attaching a note to the NA (a post-it note in a planner, a note for the todo on your Palm, etc.) with "project support" material like the address of the post office.
It's just such a small project that: a) the goal is obvious, b) the support material is minimum, and c) the next NA is self evident. Many projects will fall under this category. Again, I'm remembering this from the book.
My policy is to only create a project when a) it starts collecting a mass of support material b) I can't keep track of my goal enough to actually accomplish my NAs c) there are multiple potential NAs with various dependencies d) the NAs are part of a larger subset. If "Get PO Box" was really a part of "Start homebased business" then, yeah, the whole thing would be a big project.
Any NA that's lingering on your list should be evaluated as a project. Say you have a NA "get PO box" that just doesn't seem to be getting done. That's because it's actually a small project with actions like: "Find nearest post office" (@Computer), "Call for rates and sizes" (@Phone), "Discuss the kind of box you need w/ spouse" (@Agenda), "Go to post office and get box" (@Errands), and so on.
That said, my impression from the book was that these kinds of small, obvious projects don't have to be tracked as a separate project folder (file/memo/whatever). Because they have such a discrete and obvious list of steps, you just need to come up with the real NA ("Find nearest post office" @Computer) and place it on your list. When you finish that, you can immediately come up with the next obvious NA and add it. This works especially well if your system has a way of attaching a note to the NA (a post-it note in a planner, a note for the todo on your Palm, etc.) with "project support" material like the address of the post office.
It's just such a small project that: a) the goal is obvious, b) the support material is minimum, and c) the next NA is self evident. Many projects will fall under this category. Again, I'm remembering this from the book.
My policy is to only create a project when a) it starts collecting a mass of support material b) I can't keep track of my goal enough to actually accomplish my NAs c) there are multiple potential NAs with various dependencies d) the NAs are part of a larger subset. If "Get PO Box" was really a part of "Start homebased business" then, yeah, the whole thing would be a big project.