Tip of the Week: Try Listing Problems Instead of Next Actions
April 30th, 2007 (7:16am) Anne Zelenka 16 Comments
David Allen’s Getting Things Done personal productivity scheme suggests you track the next physical action you need to do for each of your projects. Once you finish that action, you immediately identify and record the next. This leads you inexorably towards your goals at the same time it clears your brain of “open loops,” outstanding and amorphous need-to-dos that distract and disturb you. But might there be benefit in postponing deciding what the next step is until you’re ready to act?
Kevin Rutherford puts the lean programming principle “decide as late as possible” in practice on the to do list he maintains for software changes. He’s recently switched from identifying actual code changes on his to do list to listing the problem he needs to address. He finds it gives him better results:
I have no idea how, why or when this change happened, but I’m pleased it did. Between the time I write a particular to-do item and the time I finally get around to executing it, I may significantly change the code in that area. Or I may learn something about the code and where it wants to go next. Or the problem may disappear, as a side-effect of some other change. Either way, the solution I might have on my to-do list has a chance of being inappropriate now that the code and I have moved on. So by listing the problem as I originally saw it, I’m giving myself a much better chance of creating the right solution for it - because I’m deciding on that solution in the presence of the full facts.
Perhaps this applies to more than just software development to dos. Postponing decisions on what action to take allows you to optimize the action at the time you do it. For many tasks this isn’t necessary. If you need to go to the grocery store, it doesn’t make much sense to write “problem: refrigerator is empty” on your task list. For more creative projects, however, it might allow you to move forward with more agility and less angst at the time you update your to do list.
16 Comments Post your own comment
Roni says: April 30th, 2007 9:37am
I suppose David Allen would call these problems “Projects” which need to be reviewed weekly.
aeschright says: April 30th, 2007 10:12am
Calling each one a project would be excessive in the case of many programming todos. I’m guessing the items are more like “No one can find the help page for our site”. You could add “put link to help page in navigation bar” to your list, but maybe something else in the site layout will change before you get that far and the task won’t be relevant. So it could be more effective to write down the problem to fix, and then find an appropriate solution when you have time to work on the issue.
Roni says: April 30th, 2007 10:19am
So it’s a specialized list… and lists are what GTD is about after all…
David Hollingworth says: April 30th, 2007 11:50am
For me simply restating that I have an issue that needs to be addressed will do nothing to get me forwards in implementing a solution.
I do agree with the idea of leaving some space between identifying that an issue exists and deciding on a solution. It give the sub (un) conscious time to mull over the problem and come up with innovative solutions that might be quashed if I think I’ve identified the solution and written it into my to do list.
In this cast my Next Action is to brain storm and record possible solutions. The too can be reviewed at a later date (the next Next Action) before implementing the best.
Anne Zelenka says: April 30th, 2007 11:58am
That’s a good point, David — the next action can be brainstorming a solution. Doesn’t have to be merely stated as a problem.
Kevin Rutherford says: April 30th, 2007 12:14pm
I too use GTD for managing my projects and next actions. I didn’t think to make the connection in my article, because I was really talking about something different. The lists I grow during a programming episode (which typically last 30-120 minutes) are simply “don’t forgets”: reminders to myself to leave the workspace clean and tidy before I leave. I sometimes do the same when I’m working on my company accounts. These are micro-actions, and they only exist because I have a poor memory and a butterfly brain. The overall goal of the episode is indeed likely to have been a Next Action on some project; my “don’t forget” list is a serendipitious breakdown of that Next Action, grown as necessary.
Richard says: April 30th, 2007 9:07pm
As a programmer myself, I kinda combine the methods. Initially, I’ll tag an action with “bug” or “feature” in my list, and then when it’s closer to being worked on I’ll change it to an action, if I have a specific solution in mind.
Also, those bugs etc really don’t need contexts…I’m fairly sure I know where I’ll be when I do them ;)
raincoaster says: May 1st, 2007 2:44am
Actually, it’s a damn useful perspective shift, moving from “next action” to “next issue to face.” I teach personal growth courses to people in crisis, and circumstances change for them so quickly that sometimes the identified next action is impossible or inappropriate by the time it’s supposed to happen.
Hey, for grocery lists for those on a tight budget, it makes no sense to write “go to store” but it makes plenty of sense to write “need breakfast cereal, entrees, milk for a week…” then buy what’s on sale instead of specifics you stuck on there days ago. This is the kind of flexibility that the shift can provide.
Paul Veltman says: May 1st, 2007 2:40pm
I like the idea of keeping a list of problems, but would not throw away the ‘Next Actions’ list yet.
The ‘Next Actions’ are a list of thought-through actions designed to solve problems. All the thinking has been done, and the widgets just need to be cranked.
To replace this with a list of problems which still need to be solved or thought about seems to undo the usefulness of this approach, and might be better described as ‘Getting Things Thunk About’ rather than ‘ Getting Things Done’.
One is geared towards Action, the other geared towards Purpose and Direction.
These need to be kept distinct, and as previous commentators have said, the Weekly Review of the ‘Projects’ list already provides room for this thinking and processing.
PV
links for 2007-05-08 says: May 8th, 2007 12:20am
[...] Web Worker Daily » Blog Archive Tip of the Week: Try Listing Problems Instead of Next Actions « “Postponing decisions on what action to take allows you to optimize the action at the time you do it.” (tags: GTD lifehacks organization productivity self-improvement) [...]
Productivity links for May 8th says: May 8th, 2007 5:30pm
[...] Web Worker Daily » Blog Archive Tip of the Week: Try Listing Problems Instead of Next Actions … - “Postponing decisions on what action to take allows you to optimize the action at the time you do it.” [...]
Matthew Cornell says: May 14th, 2007 5:26am
Nice article. I’ve been thinking about how lean programming techniques merge with GTD, and the idea of early vs. late decisions is interesting. On the one hand, deciding action when things show up is a very deep central concept in GTD. On the other hand, putting off excessive project planning is also there…
Regarding problems, you’ve probably heard that “every problem should be a project” - see Why every problem should be a GTD project.
Padraig O'Morain says: June 10th, 2007 2:47am
A value I can see to this approach is that I think I sometimes put off doing next actions because at some level I’m hung up about the problem it’s meant to solve. By making the problems explicit I might be able to stop fooling myself. I’ll try this and let you know how I get on!
Listing Problems Instead of Next Actions says: July 16th, 2007 3:03am
[...] at Web Worker Daily » Blog Archive Tip of the Week: Try Listing Problems Instead of Next Actions «, the question is asked, “can this be applied to more than just [...]
My Get Things Done List » Blog Archive » Problems or actions, it's still a list [What's the next action] says: August 7th, 2007 9:04pm
[...] Daily published an interesting article. A programmer decided he would not list his next actions but his problems. While reading the [...]
Patrick Allmond says: August 19th, 2007 5:55am
Boy I am a day late and dollar short.
The only thing I’d suggest is a change in terminology. Problems will tend to put a negative spin on things for you and those you work with. Instead try using the words “challenge” or “issue”. It will still apply to software and most other subjects as well. It may seem trivial but the actual words you use will affect your attitude when working with the item.
Patrick