h1

Breaking up

December 17, 2006

Sometimes 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”.

Advertisements

3 comments

  1. 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).


  2. 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?


  3. Not really a technique, but reorganizing your GTD contexts is also a form of ‘refactoring’.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: