In general, two or three. Lately, though, I have been working from my projects list as much as anything else. It doesn't take long for me to answer, "What is the next physical action that will move this project forward?" IF it requires some metaplanning, then that is the next action.

The rule is at least one action per project should be active. Beyond that, you're allowed activating more at once, if you're comfortable with being committed to making them all happen. For some, adding additional actions for the same project causes overload - there are enough with just *one* per project!

If you do have multiple actions active from the same project, they should be independent (i.e., you have everything you need to do any of them).

This is one of my problems with the concept of the weekly review. I can't see how having one NA per project and reviewing weekly can get anything done at all. Depending on how granular a NA is for a project and how many steps a project is, it could take months to get a project done at this rate.

I think this is one of the most important things I have heard about NA's. No sense putting a phone call on your list for which you would have to look up the number first. Maybe the definition of a NA should be adjusted to be, "Any physical action that you can take to move the project forward" rather than "The very next physical action..." so that the definition leaves some lattitude for operation.

This really made me think. Shouldn't you (well, I) be doing a daily mini-review of all NAs and projects? Otherwise, really, if you have a NA completed, how else would you add a new NA for a particular project, so that it is going forward, unless you review your projects list? Of course, if the project is nagging you in some way, because it is urgent, etc, then you'll remember that you need a new NA -- but that is basically the same as keeping it in mind, which is heretic to GTD.

Maybe the definition of a project should be refined a little. If you can choose two next actions for a project, then you (may) actually have two small projects. So a project in this sense would be a sequence of NAs that are linearly dependent on each other (ie. you can do them only in a particular sequence, and it does not depend on anything else).

I tend to keep actions I can't do yet attached to a project, but with a different todo keyword (this is in emacs org-mode) such as WAITING or NEEDSPREREQ. Normally these actions get added to a project during Inbox processing. When I mark an action as DONE, I do a mini-review of that project to see if any non-doable actions have become doable, in which case they get marked as NEXTACTION. New actions that I think of, doable or not, get thrown in the Inbox (with org-remember).

I also keep all independent actions that move a project forward marked as NEXTACTION, not just one. In my opinion, that would just be an arbitrary restriction that's not related to the primary feature of Next Actions, which is that they are concrete things that can be done immediately in the right context.

The key I try to use is to ensure that I'm choosing the next NA when I complete one. If not, I try to do the daily mini-review. I think the other key to GTD is that yes, you must do the weekly review, but DA also states that you should be reviewing your system often enough that you are confident that you've got everything under control. Now, for some people who might be really good at always righting the next NA after completing one, then that could be just the weekly review. For people who can't for various reasons (time, location, etc), then perhaps a quick daily review of completed NAs and Project status might be beneficial in addition to the larger weekly review.

Cheers,

Adam

If you're using a paper system, you can use some sort of dual marking to ensure that you think of a next action. E.g., checkbox for when you complete the action, strikethrough when you've considered the subsequent next action. This could speed up the daily reviews.

Also, I'm beginning to realize the value of temporary lists/brainstorming. If you really want to get a project kickstarted, then do a quick brainstorming session to come up with 3-4 independent next actions and put these on your lists. Or narrow your focus to that one project and try to get several actions done on it.

I definitely think that you should review your project list almost as often as your actions lists (and certainly not once a week, as the book recommends). If there's one fault I have with the book, it's that it separates projects from actions too sharply, when you really need an organic back-and-forth. Unless you don't have a lot going on, checking your project list once a week is a recipe for disaster--e.g., forgetting to work on that major project that the boss needs done ASAP. If I focus just on my actions lists, I tend to lose a sense of priority and/or meaning in my work. Cranking widgets is great, but you have to make sure you're cranking the right widgets. And, for me at least, this requires a lot of double-checking.

I try to have at least one, and as many as can be done in parallel.

Andy

Thanks, mdl. This works very well for me. I use DIYPlanner hPDA templates for my NA list. A checkmarked box means "action done but with an open loop" and a colored-in box means "action done" AND I've moved the project forward.

Between 1 and 3, depending on the complexity of the tasks.

For a paper, "create file" is usually the first, but since that's SO simple, I usually add a few more things so that I don't have to go back and spend more time adding an NA than it took to actually complete that action...