1 Comment »

Earlier in this series, I discovered that my Projects List was missing. Then, I searched online for inspiration about how other people dealt with their projects lists.

In this post, I’m going to detail exactly what I did to create a current Projects List, i.e., a list of all of my “active” projects.

Divide and Conquer

As discussed earlier, I was leaning towards dividing my projects list somehow. I settled on an initial division like this:

  • Now - projects that I want to work on within two weeks
  • Soon - projects that I want to work on within the next month
  • Later - projects that I want to work on within the next year
  • Death Row - projects that I’m not sure about - maybe they’ll never get done
  • Done - projects that are already finished
  • Recurring - projects that are recurring

Death Row

I think it was telling that I initially had 18 projects in Death Row. Some of these can’t even really be called projects; they’re more placeholders for reference information. For instance, I have a project called [Outlook], which theoretically was useful for learning Outlook tricks. That’s not really a project, especially since I haven’t used that project as a springboard for a next action in I don’t know how long. Similarly for projects with names like [DebtFinancing], [Doctor], [Tweak], [Ubuntu].

Trimming

So the first thing I can do to trim my projects list is to determine whether or not these are really projects, and if not, cull all mention of them as projects, e.g., category names in EverNote can be rephrased as reference categories.

Recurring Projects

A lot of people don’t use GTD projects/next actions for recurring items, preferring instead scheduling them on the hard landscape (calendar), or using checklists, or something like Sciral Consistency to handle recurring items. However, it works out well for me to put in an NA that tells me to wash the kitchen floor. I don’t put something like this into my calendar because (1) I don’t like to clutter up my calendar with such routine tasks, (2) my todo.txt list allows me to put start dates on next actions, so they only pop up when I can do them, and (3) odds are pretty good that I won’t actually wash my floor on a particular day, but sometime soon after that day happens.

As an aside, I’ve realised that many of the things in this list aren’t even really projects, just one-step actions. I’ve ended up grouping them as projects simply because they are recurring. Marking NAs with a project label such as [Backup] or [Chores] lets me know at a glance that this is an NA that is part of something bigger; in this case, once it is done, it needs to be rescheduled. Otherwise, when I see NAs without any project label, I know that they are one-offs and as soon as that action is done, it’s done - no further thought required. Other views on recurring tasks vs. projects can be seen in this David Allen Co. forum post.

Done But Didn’t Know It

The Done category is for projects that are actually done, but I didn’t realize it. I’ll be able to delete these projects from my list as soon as I make sure all loose ends are tied up, e.g., changing category headings in EverNote to indicate that the information is now reference material, not an actual project.

Meshing with EverNote

After dividing my list of possible projects into time-based categories, I went through my EverNote database and tried to structure my categories better. I decided to use icons to indicate projects, e.g., a red star indicates the category for a project in the Now category. Green for Soon, yellow for Later, white for Death Row. A checkmark will be used to indicate when a project is done.

The use of icons lets me still label categories with things like [ProjectName], but indicates to me what kind of project (active or not or completed) I’m looking at. After an hour or so, I think I have EN pretty well tamed. I’ve already been able to mark 12 projects on my list as “killed”, i.e., they were on death row and I decided that they weren’t really projects, or they were projects, but they’re done. I know that some of the other projects I have listed on death row have corresponding categories in EN, but they must be hidden deep in the hierarchy. I’ll simply do a search for them in order to kill them off.

Todo.txt

Now, some of my projects only exist in my todo.txt file - they’re not complex enough to warrant actual “project support materials” in EverNote. I need to go through this file, line by line, to make sure that I’m not hanging on to dead projects in there.

Back to Death Row

Finally, I think I have completed playing around with my Projects List. Now that I have a better handle on what was in Death Row, I was able to make decisions about each of those projects - was it “Done”, not a project at all, or simply a Someday/Maybe? I’ve deleted all done and non-projects from my list and changed the “Death Row” category to a “Someday/Maybe” category.

The Count

I now have a total of 45 projects on my list, 32 of which are in the Now, Soon, or Later categories. I think that’s a reasonable number. I have 11 recurring “projects”, which I will leave where they are for now.

A Next Action for Every Project

The next step is to make sure that I have at least one next action for each project in my list. Given how I’ve been letting my projects list slide, I wonder how many I’m missing. On the other hand, I’m really only worried about those that are in the “Now” category, and maybe in the “Later” category. In addition, I should have at least one NA for each of my recurring projects, although they won’t necessarily be showing right now, since I can have a start date on an NA, turning it into a tickler.

It turns out that I have 12 projects with no matching next action: 1 in the Now category, 4 in the Soon category and 6 in the Later category. Many of these are the kind of projects that I can’t actually do anything with right now, e.g., projects relating to a conference I want to attend later in the year. However, I did find a couple of projects that I know I have NAs for, but they’re not in my todo.txt file. Instead, they’re annotated in my EverNote database. Now, I do a weekly check of my database to see what I have marked as @next actions, but it’s not the same as having everything in a trusted system. So, I need to add a few NAs to my todo.txt list, even if they are things like “Look into Conference X on such a date”.

Conclusion

It took me about three full hours to create this Projects List, and match it with my EverNote database (project support materials) and my Todo.txt file (next actions). I now have 32 “active” projects, 11 recurring projects (let’s just call them ticklers) and a handful of inactive/someday/maybe projects.

All in all, I think this was time well spent. Having a current projects list will allow me to do a better weekly review. It will help me determine what open loops I have, and make sure that I have a next action for every project that I’m concerned about. The key will obviously be the weekly review - I need to make sure that I look at my projects often. Already, I found a small handful of next actions that were missing from my trusted system. Yup, definitely worth the effort!

2 Comments »

I recently posted about my missing projects list. It’s sad that I didn’t really notice that I was missing a key piece of the GTD puzzle until I admitted to myself that I was routinely skipping the “Review Projects in EverNote” line in my Weekly Review checklist. When I asked myself, “Why are you skipping that all the time?”, my answer was “Because it’s too hard to find the projects list.” Aha! Obviously, there’s a problem with my system if I can’t find my projects list.

So, the hunt for the projects list has started. The first thing I did was start surfing for information about how other GTD practitioners deal with their projects lists.

Storing Project Lists

First, how do other people store their project lists? Ericthedude over at the David Allen Co. Forum asks “What Does Your Project List Look Like?” Responses included: index cards, whatever program is currently being used for next actions (e.g., kGTD), outlined text files (a la emacs), paper lists. Other options, from other places, include the usual suspects: flat text files, Word documents, mind maps, lists kept in tiddly-wikis, Outlook, online programs like BackPack, etc. etc. Basically, the options are endless.

Categorizing Projects

Several people recommend dividing projects into different categories, e.g., filtering by 10,000 ft, 20,000 ft, etc.). Other options (most from the same page) are:

  • Projects, Pending (likely start/resume in next month), Someday-Maybe (idea cauldron)
  • by area of focus (e.g., volunteer work vs. paid work)
  • Business projects divided into People, Process, Structure, Systems. Lifeplan projects divided into Fulfillment, Health, Financial, Career, Order.
  • by area of responsibility, e.g., Clinical, Management, Personal, Staff, etc.
  • Another poster suggests keeping the Projects vs. Someday/Maybe, but review your Someday/Maybes at different intervals, e.g., SM Weekly Reviewed, SM Monthly Reviewed, SM Quarterly Reviewed, SM Yearly Reviewed.

The advantage of dividing your project list into categories is that it can make it easier for you to:

  • focus on specific timelines, e.g., what needs to be done now, vs. what could be done later. The most extreme project list would have no such categories; there would simply be a Projects list and a Someday/Maybe list. However, many people like a bit more division between the two extremes.
  • focus on balancing your workload between work/home, or between paid/volunteer, or any other dimension you wish.
  • focus on those projects related to an area of responsibility when in a specific meeting, or discussing things with your boss.

The disadvantage of dividing your list is that now, you can be seen to have more than one list, and it can be harder to just zoom through the list to see what projects don’t have a next action assigned.

Working with the Projects List

Speaking of working with the projects list, here is what Jason Womac of David Allen Co. suggests:
“The ‘Projects List’ is an inventory of the agreements you’ve made, about what you’re going to DO, that will take you more than one step. You review the list once a week…to ensure you have “Next Actions”…on all of your commitments…this list works best as a flat list (ie: No next actions under each project definition).
So, once you have that list, then, the Weekly Review…is time spent going through, line by line, asking yourself the question: “If I were going to continue on with this project, What’s my next action?”
So, regardless of whether I keep a long list, or break it into several categories, I still need to make sure that I look at each project, once a week, to make sure that I have a next action for every item.

Next Step

The next step in my hunt for the projects list is to make a list of all projects that I can think of, either already listed as an EverNote category, or tied to some next action in my todo.txt list, or from a brain dump. After I list them all out, I’ll try rearranging these projects into different categories to see if some breakdown will be useful/intuitive to me.

4 Comments »

I’ve recently come to the realization that I don’t actually have a real projects list. According to David Allen, in Getting Things Done,

The “Projects” list is not meant to hold plans or details about your projects themselves…it’s just a comprehensive index of your open loops. You actually won’t be working off the “Projects” list…The real value…lies in the complete review it can provide (at least once a week), allowing you to ensure that you have action steps defined for all of your projects, and that nothing is slipping through the cracks.

Now, I have created a little checklist for myself for doing my weekly review. In it, I have an entry for going through my projects list in EverNote. It turns out that I don’t have a “list” per se. Instead, I have a bunch of categories (headings, if you will), of projects that I’m working on. I can tell when a category relates to a project, because I put my project names in square brackets, e.g., [Research]. But these category headings are buried in thousands of other headings. There is no one place for me to see all of my ongoing projects, or open loops. As you can see from the snippet below, it’s a pain to actually see what projects I have on my plate.

From the next action side, I can output a list of projects that I currently have next actions for (from my todo.txt implementation). However, this just shows where I have an NA for a project - it definitely does not show me any projects for which I have *no* NAs. And really, that’s the whole point of that part of the weekly review - making sure that you have an NA for each and every project that you’re working on. And, as you can tell from the little piece below - I don’t seem to have that many different projects in my todo.txt file - which means that I’ve obviously lost track of some/a bunch/many open loops. Ooops.

So, I need to figure out a decent way of keeping track of my projects list. I’ve already determined that I can’t keep it in EverNote. EverNote really stores all of my project support materials, and it’s not suited to keeping one particular note open (say a project list), while you wander through the rest of the database, looking for information about what has been done, what needs to be done, etc.

I’m going to spend some time thinking about what I need my project list to be able to do, what it should look like, where I should keep it, etc. After determining my requirements, then I will create the list. Of course, the easiest way would just be to (gasp) write everything down on a piece of paper. Maybe I’ll just start with that. Other simple options would be a plain text file, a simple Excel spreadsheet (then I could add a bit of information to the projects, such as personal/research/delegated). Part of me wonders if I can include this in my todo.txt file somehow, maybe by just adding in a line per project. Then I could do some Perl magic to tell me what projects I have, which projects are matched with NAs, which aren’t, etc. Already, I can see this as a great way of coding the weekly review - simply have the Perl script tell me which open loops I have missed. Of course, this coding will take time. Hmmmm.

Anyway, I’m off to see what other people do with their project lists. Wish me luck, and stay tuned for “The Hunt for the Projects List”.