3 things that context-lists can't do.

I was thinking today about some stuff in my system that doesn't seem to be described in the diagram: I thought that I had discovered the Flaw in GTD until I realised that there's that sneaky little loop off to the side called Project Planning. GTD will only get you halfway - it'll only help you keep track of the balls you have in the air - at some point you have to start juggling.

Don't forget:


Project Folder

It may sound redundant to list the Project Folder as a promise-management tool, but I wanted to make it clear from the start that there's a reason why you have these things - and it's not just to keep you busy.

You keep returning to your scope document - you refer to the drawings - you keep quotes for things you've ordered - you keep sales projections.

It's not enough just to have a random manilla folder stuffed full of bits of paper you think you might one day need again. You have to start each Project with a proper folder - and use appropriate labels to guide you to keep track of the things that need to be kept. Personally I have the following labels in my folders:

• Scope
• Development
• Drawings
• FEA
• FMEA
• Prototyping
• Tooling
• BOM
• CAPEX
• Component Plans

This list isn't exhaustive - and it's probably missing some things that a better engineer than me would include - but it directs to map out the path of a Project before it's started and to not get lost along the way.


Non-context lists

David Allen only really talks about keeping action lists for the various contexts that you have. I've written my thoughts on the usefulness of contexts already.

When you have a Project that essentially involves a confluence of many semi-unrelated events it can be useful to maintain action lists for each project. For example: monitoring the progress of design, development and tooling for each component in a completely new assembly.

DIYplanner.com has a blank checklist. I write the name of each component at the top of each list, staple them all together and then note the next-action or waiting-for. Then reviewing the Project progress is simply a matter of flipping through the sheets to make sure that each component is under control.

I don't use these lists to store todo's - maintaining more than one master-list would be Evil. The purpose of these project-based lists is rather to simplify the review process.


Time blocks
Some things you can't plan as a series of actions, you just have to sit down and do them.

I've learnt that, for me at least, the process of invention can't be scripted. While I do have methods at my disposal I have no way of knowing how long I'm going to take to solve a design problem, or even what thought processes I'm going to use.

It wouldn't make sense to plan out the week by saying "On Monday I'm going to invent that component, then the day after I'll invent the other bits, and I'll finish probably on Thursday by reinventing those other bits." It doesn't work like that. At that stage I don't even know what the constraints are, let alone the shape of the pieces or even how many pieces there are. How can you put a forecast on solving a puzzle when your first step is to invent the puzzle board?

I don't track next-actions for jobs that rely on my creativity. I rely on my creativity for that. That means that I just have to block out time - 4 hours at a minimum - and just do it until it's done.

The song Yesterday was written on the first take: apparently Paul got out of bed one morning with a song running through his mind. He couldn't work out where he'd heard it before so he went to the piano and played it. Nothing. He played it for some friends, who loved it, but no-one had heard it before. After a while they realised that it was a brand new song that had literally come to Paul in his sleep.

How long does it take you invent something? The answer is "Sometime between a long time and a short time."