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.