How Do You Make Your Projects Lists?

Hello,

Having bought and read the book, I'm just beginning to implement the GTD system.

I'm not sure how an entry in a Projects list would look, and by extension, how the corresponding next action for the project would be listed in the next actions list. It seems there would be a desire to cross reference one with the other, so that when reviewing projects, you can quickly see if you have already defined a NA for that project in the NA list.

Maybe I just didn't absorb this from the book properly.

For example, do you follow the following format?

Project list entry: Date, Unique number (for referencing in NA list), and Project description (clearly defined outcome)

NA list entry: Date, Unique number (for cross-referencing to project list), and next action.

I'm implementing the lists on paper, and only digitally using a calendar, so I'm also curious as to best practices for space given to each entry (e.g., continuous list with no skipped lines, or one item per page, or list with blank line in between).

Samples entries from projects lists and next actions lists, and how you operate between them (and waiting for lists) would be most appreciated.

Thank you,
David
 
innovyse;84049 said:
For example, do you follow the following format?

Project list entry: Date, Unique number (for referencing in NA list), and Project description (clearly defined outcome)

NA list entry: Date, Unique number (for cross-referencing to project list), and next action.

Hi David,

I use the following format:

Project list: Abbreviated keyword: Outcome, Due date (if there is one)
NA list: Abbreviated keyword: Action, Due date (if there is one)

Here's an example from my current lists:

Project: GDN: Make a garden plan for 2011 and implement it
Next Action: GDN: Read "Your Kitchen Garden Month by Month" to determine actions for the vegetables in my plan

I haven't assigned due dates to either of those because there's no external deadline, and while it would be nice to have it done by the start of the New Year, nothing dreadful will happen if I don't get round to doing it. (It's a sufficiently attractive task that I'm pretty sure I will, though.) Everything to do with the "garden plan" project will have the letters GDN in it (short for Garden). I use Outlook, so to find all the tasks that relate to the garden, I can just search for "GDN". I have also written "GDN" on my project support folder for this project, and for electronic support materials I have a "GDN" folder in My Documents. I find it ties everything together nicely. I think it would be easier to remember than a number, but go with what works for you! David Allen says the keyword approach doesn't work for most people because it requires a lot of discipline to stick to the format, but if it does work for you it's fine to use it. Just make sure you're consistent about it, or else you won't trust your system. I know Kelly, who is one of the Davidco staff members, has mentioned on GTD Connect that she uses it.

Hopefully some of the GTDers who use a paper-based system will be along in a while to answer your specific questions about paper. I've noticed the forums are often quieter at the weekends, so bear with us!
 
I'm not on Paper so....

Take my notes as just another option not what will necessarily work for paper.

My project lists are gathered into folders based on areas of focus. My projects have titles like:

Middle Orchard Divider Fence
Get Hay for the Year
2010 Sheep AI Experiment
6 Pack Carrier Rev 3
Rug on Big Loom

In the notes for those items I put the desired outcome and other information I may need including the links to any computer notes or backup material and the title of the paper file if there is a paper file of data for the project.

I never use dates unless the item has a start date, due date or is a repeating project.

I also do not use any unique number scheme as the project title is good enough for me.

Next actions for those projects are things like:
Remove welded wire panels from upper half of middle orchard fence.
Call X to schedule hay cutting (with a start date of mid June).
Decide on primary frozen semen mates from semen archive for ewes and a secondary backup of fresh semen mates from current rams.
Google how to attach handles to 6 pack carrier
Locate more BWMS rug yarn from Little House to finish last black stripe.

The few times I used paper (not very often and only for a few days at best, I don't work well on paper) I had a single page for each area of focus and the projects listed on it as the first item. Then I had a single page for each context and the next actions listed on it.
 
Thank you for the responses, Liz and Oogie.

I like the idea of a Project Code, though it seems that it may require having a list of used codes and their respective projects, just to avoid overlap and confusion down the road.

If I know a project has three actions, is it best to still just write the first, and only write the next NA when the first is completed? Or write them all out somewhere? The only hesitation I have with the former is that I may think of a particular NA that wasn't completely obvious before when I'm writing the project down, and if I didn't note it somewhere, I might forget it in the process of the project!

This seems like it's a Project support material kind of thing, but I didn't think support material was reviewed every time the next NA was decided, as a general practice.

Which brings me to my last question about Projects lists. Do you refer back to them for any reason once you've completed a NA related to them? Or are they just part of the weekly review to make sure you've defined NA for each? (I think the latter is the book's methodology).

Thanks again!

David
 
Starting a Paper System...

I'm also just starting with a paper system. I purchased the David Allen GTD paper planner. It includes samples for each of the sections: projects, next actions, etc. Found that to be helpful.
 
TesTeq;84081 said:
I thought sheep had some real intelligence!

:-) They do, especially our sheep. But smart sheep isn't always a good thing. There are occasions I long for a flock of the stereotypical stupid sheep, not often but on occasion.

This is an artificial insemination experiment, we're working with out US Dept. of Ag to help develop a non-surgical AI procedure for sheep that the farmer can do. We are in year 5 of the experiment.
 
My project list is:

-on paper
-one item per page
-has a title
-has date of creation

and that's usually pretty much it. For example: "File Taxes 2010 -- 10 June 2010".

Cheers,
Roger
 
innovyse;84066 said:
I like the idea of a Project Code, though it seems that it may require having a list of used codes and their respective projects, just to avoid overlap and confusion down the road.

I don't find I need a separate list for that - the Projects list is sufficient - but it probably helps that I have it in Outlook and can therefore easily choose to look at completed as well as incomplete tasks/projects if I want to.

If I know a project has three actions, is it best to still just write the first, and only write the next NA when the first is completed? Or write them all out somewhere? The only hesitation I have with the former is that I may think of a particular NA that wasn't completely obvious before when I'm writing the project down, and if I didn't note it somewhere, I might forget it in the process of the project!

This seems like it's a Project support material kind of thing, but I didn't think support material was reviewed every time the next NA was decided, as a general practice.

If the three actions can be done independently of each other, then they can all go on your context lists. If they have to be done sequentially, then only the next one goes on your context lists, but you can still record the other two somewhere. With a paper-based system, the usual recommendation is to write them on a piece of paper and put them in a Project Support folder; in Outlook, I write them in the Notes field for the project.

Which brings me to my last question about Projects lists. Do you refer back to them for any reason once you've completed a NA related to them? Or are they just part of the weekly review to make sure you've defined NA for each? (I think the latter is the book's methodology).

You review them as often as you need to in order to keep them off your mind. I usually only look at the actual Projects list as a whole once a week, but I look at Project Support more often, whether in a hard copy folder or in the Notes field for a particular project. Typically I look at it whenever I need to remind myself of some detail I remember noting down, or whenever I'm unsure what the next action is. If you don't trust yourself to remember to look, then you could try leaving yourself a reminder. For instance, let's say that I have a NA to call Carla about the XYZ Project, and depending on her response there are two or three different options for what to do next. I've made some notes about those options, but I'm concerned I may forget to look at them. In that case, instead of just writing "XYZ: Call Carla" on my @Phone list, I might write "XYZ: Call Carla, then check Project Support for NAs".
 
Don't over-systematize!

As a software developer I've had to fight the temptation to over-systematize and over-automate my system. After doing GTD for almost six years now I've truly discovered for myself that the best system is the simplest one. The more overhead involved in any aspect of GTD whether it it's adding a project to your list or a file to your filing system, the more resistance you will feel to the entire GTD process.

I suggest that you don't bother trying to create project codes or use complex ways of linking projects and actions. Your brain does a fine job of connecting the dots; it just can't track the dots. That's the key function of your system. However, your system can't do the required fundamental thinking for you; that's the key function of your brain in GTD.

Just use your lists to park the reminders of your outcomes and actions in their simplest form: a one-line description like "Call Fred re: xyz" or "Finalize proposal re: ABC".

Projects usually start with verbs like:
  • Clarify…
  • Complete…
  • Design…
  • Ensure…
  • Finalize…
  • Handle…
  • Implement…
  • Install…
  • Look into…
  • Maximize…
  • Organize…
  • Publish…
  • Reorganize…
  • Resolve…
  • Roll out…
  • Set up…
  • Submit…
  • Update…

Actions start with verbs like:
  • Buy…
  • Call…
  • Draft…
  • Email…
  • Fill out…
  • Find…
  • Gather…
  • Load…
  • Measure…
  • Organize…
  • Print...
  • Purge…
  • Read…
  • Review…
  • Take…
  • Talk to…
  • Waiting For…

I hope that this helps.
 
As simple as possible, but no simpler

I second what ellobogrande says, above. Here is my take on it.

My Projects list is a written list of changes I want to see made in my world. I describe them as they would look when completed:

File cabinet purged
Oil changed
Snowblower tires inflated
DJ emailed
Cabin rented
Fax to Arthur sent

Instead of using codes, I use keywords from the Project name to connect NAs to Projects. Most of the time this isn't necessary but here are some examples:

Errand-post office-ship box-XMAS
WF call from auto shop as of (date)-OIL
Office-find insurance papers-ARTHUR

If you write slower than you type, then economy becomes more important on paper. You want to write as few words as necessary to get the point across. Because you will be reviewing your lists every day and week, your lists will be reminders instead of new information. You are writing for yourself, and you will be(come) familiar with your various projects and tasks.

Good luck
-JohnV474
 
I do the same as above, but I do not use paper either. I use my PDA for everything.

I don't have a Projects List. With a PDA, you can carry the entire Project plan as a note attached with the Next Action item. But I do use a code before the NA item so I know which Project/Order it belongs to.

I have a few customer orders going at one time, and they all have similar NAs, but are at different places in the order process. So I like to know which customer order I'm looking at when I see the NA. So @Laptop, I may see "(SF) Finish design", which tells me that the order for SF needs to have the artwork finished. Without the "SF" I would not know which order it was without going in the attached note to look at it.
 
Top