Saturday, January 03, 2009

50th time is the charm with GTD?

Well, it's a new year and I, like many, and making an effort to organize. I've read David Allen's Getting Things Done and been inspired, but have never quite got a system I'm terrifically happy with. Usually, I try something new, move all my lists, get a temporary boost (more from inspiration than efficiency) and then things end up about the same.

Well, this is another one of those times! This post from March sounds startling like this one, but I will press ahead. The idea of using google notebook didn't last long. I'm not sure why. I think part of it is the interface. It just has all these borders and stuff that get in the way of the lists. I fell in love again with emacs and after using org-mode for outlining, put my lists in there and used svn for versioning. I found myself reordering branches, indenting, and generally messing with my giant .org files (work and home). Worse, I found I was generally doing things that never made it on the list and not looking at the list to see what to do.

Next (yes, there's a next), I tried taskodone, which based on taskpaper. I was inspired by this review of taskpaper

"TaskPaper’s strength is that it lets you focus on crossing out those tasks instead of building a self-referential web of unfinished business which separates you from the cold, harsh reality of all the work you need to do."Scott McNulty,

Hey, that's me! OK, so I tried taskodone and I like it, and I really think it might be OK. It has a lot of charm in that it's pretty fiddle proof with only one level of indendation. It didn't quite stick with me though. I still wanted to reorganize my unfinished business. I also didn't like looking at it all all the time. I suppose some discipline, like just looking at the @na lines would work, but still when I opened it to delete a finished line or add a next task, I'm still looking at everything.

All of the above with tags and outlines actually has little to do with what's in David Allen's book. His lists are just lists. Many of us have this need to keep actions tied (electronically, preferably) to their projects. His project list though, is just a list of projects! You only consult it at the weekly review or when adding a new one. The other lists or lists contain your next actions.

Where does the planning happen? In the project plans, of course. These project plans are culled for actions in the weekly review. They go in folders in the book, I believe. You get out these manilla things, look and alter them, and then update your plain old flat GTD lists. I had never quite figured this out (and am still not sure I have).

Where are the project plans in my org-mode giant list? Well, they are *all* right in there. Yes you can collapse and expand and only look at what you need with some fancy emacs keystrokes, but still, they are *all* right there. Too much for me.

Where are the project plans with taskpaper? Well, umm, umm... There's a flat list of tasks under the project headings, but that's just not enough for a project of any complexity. You can break a project into separate project (which I did) and have something like "Build a house:", "Build a house - hire an architect," " Build a house - hire a contractor," etc. That's just cheating though, and your forced to look at all the sub-projects.

OK, so my projects don't really live in manilla folders too often. What could I use? Well, gee, how about those things on the filesystem we call "folders?" Wait, it's all coming back to me now. Back in grad school, I had a small set of folders that my life depended on. One folder would hold the .tex, .ps, and gnuplot script files that represent the paper (or my thesis) that I was working on. The other folder(s) would hold code and the output of that code. The state of those folder represented my progress in pretty absolute terms. When the paper was done, refereed, and published, I was pretty much done. I would put "TODO" or "FIXME" into code or tex files and have TODO files with lists of task. grep was my friend for finding where work was needed.

Much of that simplicity came from what I was doing and it was just natural. Now I'm more connected with other people and there's a lot of quick turnaround exchanges via email that can be confused with advancing the ball. Often there's not a product I'm actively working on that would naturally go in a folder. I might have one due in the distant future, but haven't actually got to the point of creating a folder and opening a word processor.

So here's the idea -- use project folders. Have a project? Make a folder. Put some stuff in there that represents what's been done and what has to be done. The state of these folders represent progress (or lack thereof). I'm thinking org-mode can help here with a with the tasks. Keep TODOs separate from notes, and references. Flag the next action with TODO and use org agenda to pull the master action list together. The project list is just "ls ~/projects."

Really the only revelation (to me) is that having all your project plans in one file can be terribly distracting. OK. I've wasted enough time not actually doing things while writing this, so back to work!

No comments: