Breaking up
December 17, 2006Sometimes you’ll have a project that’s starting to become very big. You’ll have a lot of actions attached to it, and the first five could all be the next action. My advice is to break them up into smaller projects. Sometimes the actions can literally be the projects’ names.
In my experience, you’ve got problem when the “big” actions aren’t physical anymore. As soon as you start to write something like “Get a hotel” on your action list, you’re screwed. But fortunately, the solution is easy, just make a new project and think of the necessary actions to complete it.
You’ll have a lot more projects if you do refactoring and planning like this, but you’ll get used to that. The big difference is that you’ve decided on the very next physical action, instead of having a blob of actions hidden in that one “action”.
Great advice Chris
I especially like the idea of ‘refactoring’ your projects. In my experience, it’s once every few weekly reviews this will happen automatically, given you have enough free time (and a clear mind).
I’m wondering what other refactoring techniques or programming strategies can be applied to GTD. The only one I can think of is Divide and Conquer, are there anymore?
Not really a technique, but reorganizing your GTD contexts is also a form of ‘refactoring’.