How many N/A's under a project?

D

dsmccormick

0
I have been wondering how many Next Actions people use under their projects at any given time.

I have a MS Outlook based GTD setup with the NetCentrics add-in.

For a given project do you have one and only one Next Action (assuming the project involves one-after-another steps, rather than multiple threads running in parallel)? I saw someone who had the next Next Action (NA2) in either the subject line or the body of the task (NA1), which allowed them to create the Next Action quickly.

Should one just enumerate the list of serial Next Actions in the Project list, then use that for the cut-and-paste operation to create next Next Actions?

Just curious.

Thanks, David.
 
Projects as NA Dispensers

Certain projects are a simple sequence of actions, not likely to change as the project unfolds. For these projects, it might be useful to have a queue of potential next actions and then pop the next one out and make it an actual NA. You could think of your project note as like a Pez dispenser of the NAs. To save time, but give up some documentation and motivational advantages, the whole remaining queue could be kept in the NA itself.

Many projects aren't simple sequences. GTD posits that for efficient task completion we self are essentially serial processors. But David's writings also seem to say that our intuition (whole brain thinking) is the best generator of the sequence of next actions for complex real projects. That is consistent with my understanding of what our brain is good at and how it works.

I note that there are those who are attempting to construct systems that will propose specific candidate next actions automatically from projects that have been appropriately specified. This sounds like a neat idea, but possibly unrealistic in most cases. I think "Life Balance" and "My Life Organized" attempt this. I really don't think that it is easy to fully specify the sequence of all aspects of a project. For example, how do you factor in team-building. What do you do if the usual team-building steps don't seem to lead to team cohesion ? It seems to me that this is a kind of uncertainty that is harder to deal with than not knowing when the lumberyard is going to deliver the shingles.

There is other software that allows you to outline a project and then, when you finally specify things down to actionable, to designate them as tasks. A mirror of these lowest level pieces of the outline then become tasks in, say, a Palm OS PDA. I like that approach, especially implemented on a Palm, because one can spend some bits of free time to partially structure a project . Even if one doesn't get very far, the fruits of the effort remain for the next time you want to think about a project. That still leaves plenty of need and room for intuition.
 
So one or many NA's?

That was very interesting and meshes with my experience.

However, I need to reiterate my original question: do GTD practioners have one and only one NA for a given project, or do you have multiple NA's? If it's a project with parallel activity threads, do you keep only one NA or do you have a NA per thread of the project?
 
All immediately doable actions associated with the project appear on my NA lists. I'll often have several parallel tasks that all need to be done but don't depend on each other. Putting them all on the list lets me move the project forward even if I can't or don't want to do the "first" of these tasks. If I have five phone calls to make, I don't want to be blocked just because the first person doesn't answer.

I'll also list tasks I'll need to do at some future date in the project support materials, but they don't go on the NA list until all prerequisites have been met.

Katherine
 
A Straight Answer

Your question deserves a straight answer.

I definitely have multiple NAs on a project, but usually only one on a branch. If I have 5 50K-ft goals, then 20 40k-ft macro projects, etc., by the time I get to 10K-ft sub-projects, I only have one NA per sub-project. Not that everything is quite that systematic.

I HOPE that's a straight answer. :))
 
If there are several next actions that can be done on a project and none of these actions is dependent on anything else happening first, then they all appear as next actions on my lists. Most of my projects have only one or two next actions, but I currently have a one or two projects with ten or more next actions.

I don't feel comfortable with only one action per project in cases where I know there are several actions that are doable independently of one another.

Hope this helps.
 
Parallel next actions that can be done now go on the action lists, serial next actions with dependencies go on my project plans and get filed as project support material. The action lists lose their power as a focus tool when combined with non-actionable items -- or as DA says, "Anytime you blend actionable and non-actionable things in the same area, you go numb to the area." I don't want to see anything I can't do on my action lists, nor do I want to see them subset on my project list. The project list simply identifies what my projects are, and shouldn't become the electronic equivalent of using piles to remind me I have projects.
 
dsmccormick said:
do GTD practioners have one and only one NA for a given project, or do you have multiple NA's? If it's a project with parallel activity threads, do you keep only one NA or do you have a NA per thread of the project?
Click to expand...

I wondered this myself, but I now look at it as a tradeoff, like this.

Each time I revisit the project, with a view to creating one or more NAs (or, moving pre-identified N/As into one of my NA lists), I take time. In other words, merely revisiting the project - pulling the file, reading it, doing the context switch required to remember what the status is - takes some time. So on the one hand, that creates a case for visiting as infrequently as possible and, as a result, having as many NAs as possible already inserted into the appropriate NA list (e.g. an @context lists if you use that approach).

ON THE OTHER HAND, the extreme case of visiting infrequently would be to have a single planning session at the start of the project at which all the NAs were identified, and inserted into their appropriate NA lists. And for large projects (i.e. real projects, as opposed to GTD's "aynthing that contains more than one NA" [I paraphrase])you *cannot* identify all NAs up front.

So the tradeoff is responsiveness in choosing NAs, versus time saved reviewing the project.

My resolution of that tradeoff is to review projects once a week, and to use that time to identify possible NAs (not moving them to @context lists yet), deciding if already-placed-in-their-@context-list NAs are still relevant, and so on. And I then put into my @context lists enough NAs so that I won't run out between now and the next review period.

--
 
Project next actions...

My understanding is this: Project names/outcomes on a list are "bookmarks" to remind you of what you have committed to, so nothing falls through the cracks.

Project next actions are also bookmarks. David's system is designed for the middle ground of project managment - things that are not hugely complex but do require more than a few quick steps. You can work then out roughly in your head or on the back of an envelope (brainstorming), but don't need to plan it all out in detail. You would enter your steps in project support material or notes, but not work from them in any rigid or strictly sequential fashion. In practice, you might knock off a bunch of project-related next actions in a sitting, but you would only record the NEXT action on your list when you shift your focus to another area. This is so you can easily pickup where you left off - a bookmark.

Best wishes,
Gordon
 
Project Next Actions

I ponder about this. I have several clients for whom I provide a service involving contact management, sometimes by mail sometimes by phone. It seems more efficient to block off time to deal with one client's work, while I have their support materials out and my brain is engaged with their business, even if that involves different 'contexts', than to concentrate on, say, all NA@phone for different clients.

As such, I find myself making a list of NAs for each client, which might encompass different types of task.

I don't think this is the GTD way, and I'd welcome suggestions from others who deal with this sort of situation.

Thanks,
Bron
 
Bron,

David has nothing against blocking off time to concentrate on a particular client as far as I can tell. There are many situations where you can do more than one type of "batch processing" or context related activity. Next Actions grouped by context are not designed to be rigidly enforced - the law was made for the man, not the man for the law. Rather, they are designed to allow you to continue moving projects forward in situations David calls "weird time" - those times when you are very limited in what you can do because of your context, or when your time itself is limited. They are not supposed to PREVENT you from doing other things when you are "in the zone" with a particular project, or when a number of other things are possible in your context.

Regards,
Gordon
 
"Quality work time" as a distinct context for professionals ?

Professionals, as opposed to managers, spend a significant amount of their time gathering information and producing documents (in an office context: words, numbers, graphical representations, mixed media). Managers spend much more time communicating orally, in meetings, large and small. Producing documents often requires thought and engagement in a problem. This requires "quality time".

I would think that a professional could easily justify establishing "quality time" as a distinct context in a GTD system. It isn't a place as much as a set of conditions (few external interruptions; all required info, supplies, and equipment handy; suitable surroundings; emotional and cognitive readiness). "Quality time" would seem to be what "Bron" would need to get himself into each client's problem so that he could make a component of a document or something else that would enable the solution of the client's problem. The NAs that Bron describes seem to be relatively big actions, taking hours, say.

How many of us are in Bron's shoes in this regard ? How many of our NAs need "Quality work time" ?
 
RE: "Quality work time" as a distinct context for professionals ?

ProfDD said:
Professionals, as opposed to managers, spend a significant amount of their time gathering information and producing documents [...] This requires "quality time". [...] I would think that a professional could easily justify establishing "quality time" as a distinct context in a GTD system. It isn't a place as much as a set of conditions [...]
Click to expand...
This idea intrigues me a lot! I am a professional who runs a consulting business from my home office. Writing reports is one of the most typical project types of my business.

I have been struggling with how to apply the NA concept to report-writing. By its nature, report-writing tends to flow from one step to the next when you are in the "zone", but I often have problem getting there in my work environment. Unlike some NAs that you can just "knock off", it seems inefficient for me to work on report-writing NAs during periods of time when there are a lot of interruptions from family members. Perhaps establishing an @qualitytime context would encourage me to use those occasional blocks of quiet on projects that are most efficiently completed in larger blocks of time...

I would love to read more about what GTD vets think of the idea of an @qualitytime context for professionals who are implementing GTD.

Ksenia
...a GTD newbie who is very enthusiastic about the benefits of even an incomplete GTD implementation!
 
You must log in or register to reply here.
Top