As I mentioned last time, don't choose a tool that doesn't fit your flow. What does that mean? Here's an example: I thought I'd be clever and create a separate flow for home and work. Since I work at home, the thinking was that I'd further separate my two worlds with two systems. In one corner I had The Hit List syncing to iCal which in turn was syncing with Todo on my iPhone. In the other corner: Toodledoo in my browser (or standalone in Fluid) and on my iPhone. Guess what happened?

I wound up preferring one system over another. In this case, Toodledo (a service I'll dissect in a later post). Todo and The Hit List and even lowly iCal are great, but since the majority of my inbox items fly at me in a work context, I simply wound up using Toodledo more often. That simple cognitive shift of changing to another system wound up enough of a barrier to me to discontinue my hacked-together system. Oh, and it didn't help that my hacked system didn't work right.

The Hit List is a very powerful tool, and iCal works great with my MobileMe account. The hack to sync the two with Todo, also a terrific piece of software, only works so well. My second piece of advice this week: avoid hacked solutions unless you can fix them easily. This goes back to truly learning your system. If you can code your own apps and craft your own workflow, more power to you. If you can't, admit that you won't be able to fix things and look for a total solution elsewhere.

Case in point: so-called Kinkless GTD. Remember this one? I loved it. Add items via QuickSilver into a special, fragile OmniOutliner Pro document and all sorts of magical things happened. Unfortunately, the system was fragile as a glass kitten. Once it blew up on me once, I never got it working again, and had to unlearn a number of methods for capturing and completing tasks. That is not the way to get things done. But the toolset was beyond my capacity to fix it. So take a lesson from Star Trek and don't become dependent upon a tool you can't fathom. Or, at the least, find something with support documentation.

Next I'll show you some questions to ask when evaluating tools.