Best Practices for Project and NA Naming

[mcogilvie]

I have been exploring the effect of different ways of representing projects and next actions on my lists, e.g., subject-verb, capitalization, et cetera. My current usage is to start projects with a noun describing the project, followed by a capitalized verb. Next Actions start with capitalized verbs, then the object. Thus:

Albanian Invasion- PLAN
BUY Maps & Albanian Language Tapes

I am starting projects with nouns because I store brief project notes with them, and this makes them easier to find in a hurry. If I started projects with a verb, I would have to read whole lines of text to find the item I want, or search for it. On the other hand, I start next actions with a verb, because that seems to be the best way to get right into doing.

My GTD practice is headed these days towards fast, lazy, and simple. I am interested in anyone else's experience in this micro-area of GTD, although I recognize this is an issue of personal preference.

 

[Borisoff]

I used to do the same as you. But decided to experiment with David Allen suggestion: start with verb everything - project and Next Action. Started a week ago. Looks like it motivates more but no confidence if I can find the needed project name when needed

Regards,

Eugene.

 

[severance1970]

I tend to use verb phrases, e.g. "Draft project plan for Albanian invasion." Note that I've reified "plan" into "draft project plan," making it physical/visible, since I prefer to see that example as a subproject, or even a next action, of an actual (well, hypothetical) invasion project.

However, on some errand and computer NAs I'll append the verb phrase to a noun when a specific location is involed, e.g. "Traveller's Bookcase: buy Albanian maps and language CDs" or "Wikipedia: read entry on Albania." I suppose I'm more responsive to that syntax because my familiarity with the location makes the NA seem more inviting.

Recently I've moved away from abbreviations when I realized that I'm less responsive to terse phrasings. I was going numb to all of my "R&D" projects and actions, so I started replacing the term with others which felt more precisely nuanced for each project or action: "research," "google," "investigate," "inquire," "compare," "evaluate," "read," etc.

For projects I always use verb phrases. I use the project list as an inventory of open loops, to review weekly or update when processing, rather than as a filing system, so the problem of looking up notes is handled in my A-to-Z general reference files.

One week I experimented with phrasing projects in "mission accomplished" past-tense, but missed the active voice. "Albanians conquered" just doesn't work for me. It sounds like an affirmation instead of a solid project.

 

[unstuffed]

Verbs and nouns and Albania, oh my

In brief: projects start with nouns, and NAs verbs, absolutely. No other way, I think. But I'd describe the project with a 25-words-or-less summary, just for my own information, and to codify my expectations.

In tedious detail:

However, on some errand and computer NAs I'll append the verb phrase to a noun when a specific location is involed, e.g. "Traveller's Bookcase: buy Albanian maps and language CDs" or "Wikipedia: read entry on Albania." I suppose I'm more responsive to that syntax because my familiarity with the location makes the NA seem more inviting.

It's also more concrete, which makes it easier to do: no thinking or decision-making involved, just wiki away. Pure cranking the widgets.

Recently I've moved away from abbreviations when I realized that I'm less responsive to terse phrasings. I was going numb to all of my "R&D" projects and actions, so I started replacing the term with others which felt more precisely nuanced for each project or action: "research," "google," "investigate," "inquire," "compare," "evaluate," "read," etc.

This is one of the weeny areas of GTD that needs some refinement, I've found. Not in terms of GTD itself, but in the implementation. I started with the more vague, catch-all verbs like you, and had the same experience. That's where we need to develop the habit of being more precise when we formulate the NA. I'm still working on this one. And I've had a bugger of a time trying to convince others to do it, too: people seem to have an innate resistance to writing stuff out in full.

One week I experimented with phrasing projects in "mission accomplished" past-tense, but missed the active voice. "Albanians conquered" just doesn't work for me. It sounds like an affirmation instead of a solid project.

Urk, affirmations. Aside from that, the past tense sounds a bit passive, whereas the present imperative (is that the correct grammatical term?) sounds more active. I'd phrase it as:

Albania: Invade, subjugate inhabitants, grind beneath my iron heel, have lunch of salmon and snow peas.

Just so that I've got the subject (Albania) of my nefarious plans, plus my expectations in enough detail that I'll be able to see when I've achieved the major goals ("Invaded? Check. Inhabitants subjugated? Check. Ground beneath iron heel? Where the hell is my iron heel? Which of you buggers has got my iron heel? Speak up, I don't have all day!").

 

[moises]

I have been exploring the effect of different ways of representing projects and next actions on my lists, e.g., subject-verb, capitalization, et cetera. My current usage is to start projects with a noun describing the project, followed by a capitalized verb. Next Actions start with capitalized verbs, then the object. Thus:

Albanian Invasion- PLAN
BUY Maps & Albanian Language Tapes

I am starting projects with nouns because I store brief project notes with them, and this makes them easier to find in a hurry. If I started projects with a verb, I would have to read whole lines of text to find the item I want, or search for it. On the other hand, I start next actions with a verb, because that seems to be the best way to get right into doing.

My GTD practice is headed these days towards fast, lazy, and simple. I am interested in anyone else's experience in this micro-area of GTD, although I recognize this is an issue of personal preference.

When I first started on this forum, I read here a neat trick that has helped me significantly over the years.

It is based on the fundamental GTD questions: "What is the desired outcome?" and "What is the Next Action." The answer to the first question guides me in creating a well-formulated project title. In answering the first question, I visualize, or feel, or imagine a state of affairs where my desired outcome has been achieved. So I formulate my project by describing that state of affairs. Grammar is not my forte but generally, states of affairs are described using some kind of past participle or other past verb form. Examples:

Albania invaded (or Albania is invaded)
Door closed
Windows washed
Report submitted
Francis evaluated
Tires replaced
Gastroenterologist appointment completed

By forcing myself to formulate the project in this manner, I encourage myself to picture how the world will be when my desired outcome has been achieved. Since words like "completed," "investigated," and others, are common, I make sure that the noun is first, since that usually is my easiest means of differentiating among projects.

As far as the second GTD question goes, "What is the Next Action?", I think that your rule for formulating NAs is excellent. Verbs describe actions. I always start my NAs with verbs in a present tense. Your suggestion to capitalize them provides further reinforcement where it is needed.

Returning to the syntax of project names, I have found that the discipline that this imposes on me is quite beneficial. No, I don't usually have mind like water. But I am much better off by defining well-formulated outcomes. And I can define those outcomes much better by following my rather strict rules of syntax.

Some people do fine in life keeping stuff in their heads, without any particular system. I am not one of them. I see everyday the enormous efficiencies I get from systematizing my commitments. The more seamless my system is, the less I have to think about. I know instinctively where to look for and how to find things.

Rules for formulating NAs and projects is just another step in the process of systematization. Eventually, it becomes second nature for me to formulate a proper NA and Project. It's one less thing to think about and one more thing that makes me more efficient.

 

[AdamMiller81]

Off topic but . . .

Just wanted to throw in a quick note saying I'm loving the examples. This, combined with a previous thread which seemed to allude to planning a dinner to negotiate a treaty with Antarctic penguin terrorists, bring a smile to my face while also providing useful commentary.

Plus, because the projects are light-hearted (well, I guess as lighthearted as conquering Albania can be), in some ways, it gets you to think outside the box of your current day to day, and see if there might be a tidbit of info you can pull out and apply to the regular "mundane" projects.

Thanks!

Adam

 

[Cpu_Modern]

Off topic but . . .

[...] Thanks!

I second that!

 

[ellobogrande]

My New Naming Conventions for Projects & Next Actions

I've been looking for ways to improve my project and someday/maybe lists so that they are complete, clear, and useable. I've been struggling with the topic of naming conventions for some time. I'm a a software developer so naming conventions are very important to me.

Before I go any further, I want to thank everyone who contributed to this thread. This thread provided the insights that I so desperately needed. I've noted the diversity of the opinions on this topic and I've borrowed parts of all of them to formulate a new methodology that I'm going to start using.

To begin, I use Microsoft Outlook without the GTD plug-in on my desktop to keep my vital GTD information and the Palm Tungsten E to carry it with me. I've configured Outlook to implement GTD according to David Allen's official document.

I implement my projects and next actions as Task objects, and in the subject field I start the name with a verb according to David Allen's recommendations.

Common Next Action Verbs

• Call
• Buy
• Read
• Purge
• Print
• Load
• Email
• Organize
• Fill out
• Measure
• Take
• Draft
• Review
• Find
• Talk to
• Gather
• Waiting For

Common Project Verbs

• Finalize
• Look into
• Clarify
• Organize
• Ensure
• Update
• Implement
• Resolve
• Submit
• Reorganize
• Design
• Roll out
• Install
• Handle
• Maximize
• Publish
• Complete
• Set up

For projects, I created a rich-text layout in the Notes field that allows me to document as much or as little about the project as I want.

SUCCESSFUL OUTCOME
What will have happened when you can mark this completed?

MASTER PROJECT
If this is a sub-project, enter the master project name here.
(Also, you can create a link to the object in outlook)

BACKGROUND
Note any background information that will be helpful in reminding you of the project's purpose.

DEPENDENCIES
List all dependencies that affect this project including other projects, people, weather, etc.

RESPONSIBLE
If you have delegated the project to another person or group, list it here.

FUTURE ACTIONS / SUB-PROJECTS
Note any future actions or sub-projects that you may need to track but are not yet ready to add to lists.

COMMENTS / IDEAS
Add comments and random ideas about the project here.

HISTORY

YYYY-MM-DD HH:MM PM
Most recent log entry for this project

YYYY-MM-DD HH:MM AM
Second-most recent log entry for this project

Underneath the SUCCESSFUL OUTCOME heading, I describe in past tense what will have happened when the project is completed. Sometimes I merely rewrite the subject line rewritten in past tense, but other times I may make a list of multiple outcomes.

To use a previous example, if I wanted to conquer Albania (I love the examples, by the way), I would create a project "task" that looks like this:

Subject: Conquer Albania

Notes:

SUCCESSFUL OUTCOME

• Albania invaded
• Albanian government overthrown
• Inhabitants sujugated and ground under iron heel
• Victory lunch eaten

MASTER PROJECT
Conquer the world!!!

FUTURE ACTIONS / SUB-PROJECTS

• Organize a private army
• Kidnap and execute the head of the Albanian government

COMMENTS / IDEAS

• Salmon and snow peas for victory lunch?

HISTORY

2007-03-01
Project launched after reading a book on conquistadors.

Here's one key practice that I intend to start using during weekly reviews. I won't review my project list as a table; I'll physically open the first project "task" and use the navigate next button on the toolbar to go to the next project. This opens all of the details of the project right before my eyes so that I give each project a fair evaluation of outcomes and next actions. Too often I rush through the review of my projects without giving them adequate thought and as a result I fail to generate the next actions that keep projects moving forward.

Thanks again to everyone for providing the insights I needed to develop these ideas. I hope that I was able to provide some help to you in return.

 

[QuestorTheElf]

My GTD practice is headed these days towards fast, lazy, and simple. I am interested in anyone else's experience in this micro-area of GTD, although I recognize this is an issue of personal preference.

In my present life, I'm in Marketing. One lesson I'm continuously reminded of is to distinguish between features and benefits. "Fast, lazy and simple" sound like the seeds of highly marketable benefits.

In my former life, I was in Software Engineering. (Talk about looking at life from both sides now.)

I bring this up because I definitely like your distinction of nouns for Projects and verbs for Next Actions. It brought to mind something I liked from my days of programming. Since GTD has caught on big with software professionals, I thought I'd mention it here. (I also saw the word "object" at the start, so I hope you won't object!)

One popular software methodology is called "object-oriented." At first it sounds scary, yet we've been doing object-oriented things all our lives. It's all about representing a system by finding its objects and stating what they do. (A car is an object, and we drive it, change its oil, and hopefully avoid wrecks.) A common exercise to analyze and design an object-oriented system consists of looking for nouns and verbs too. To figure out what objects exist or are needed, one is told to look at a system's explanation and extract the nouns. To then see what actions those objects need to do (to themselves or to other objects), one is told to look for verbs.

I always liked doing this to the music of Schoolhouse Rocks, e.g., "quite interesting a noun's a person, place or thing."