Are next actions necessary?
Friday, May 05, 2006I've come to believe that next actions are unnecessary, except when a project is stuck.
This obviously cuts out a big piece of the GTD methodology, but I think it's right for my type of work: web development projects.
Next actions in themselves hold little information about their relative value, unless you start trying to prioritize them, which is not only futile but is also just too time consuming. So, in theory, you rely on your "intuition" to select a next action based on context, time available, etc. Unfortunately, I don't think intuition can be reliably trusted when you have 20-30 development projects in play. When I have a couple hundred next actions in front of me, I simply can't be trusted to pick the right ones. I found that I would consistently gravitate toward certain projects while avoiding others.
If all of my projects were personal projects, this might not be such a big deal. But when dealing with client expectations, contracts, etc., this sort of randomness and thinly veiled psychological preference isn't very logical.
The other thing is that programming/technical work doesn't really lend itself to doing tiny pieces here and there. I am about 1000% more effective when I can really immerse myself in a project and complete as many pieces in one sitting as possible. When going down a list of next actions, I'd find that right as I settled in and focused on a project and completed some tiny action, well, now it's time to switch projects.
I've found a pretty simple solution: a rotating project list, where I work on the project with the oldest "last activity" timestamp. And instead of just doing one thing for the project, I complete as many elements as I can in one sitting - and I push myself to reach a point where I can give the client something new to see or at least get the ball into someone else's court.
This has several advantages. For one, I can't leave a project unattended for too long because it's going to rotate around to the top of the stack again. This has really helped me make progress on projects - especially "easy" ones - that before I would have kept deferring until later. This also helps improve client perception because I'm actually getting to points where they get an update more often. It's easier to determine what to do next, because I may have ten open actions for a project, but they are often related and several can be knocked out at once; and a list of ten is a lot less daunting than a list of 200. And finally I avoid some of the loss of efficiency that comes with switching projects.
This can easily be implemented with a stack of index cards, where you just write each project on a card, start working on the top card's project, and move it to the back of the deck when you're done. And of course, any digital list that lets you stamp an item with the date and time and sort in ascending order by the timestamp works as well.
Of course, the concept of determining the very next physical action is a great one to apply in cases where something is just not moving forward. And I think it's also useful as a type of bookmark to help you remember what was going on if you get interrupted or can't complete something in one sitting. But for the bulk of the type of work I do, adhering to the methodology was actually becoming counterproductive.
Posted by murt at 2:09 AM