Zero Inventory is about more than just saving money on holding stock.

The ideal batch size is one.

When you order one shiny new blue automatic Toyota Corolla with air-conditioning and power windows (but without the sports bumpers or tinted windows) precisely one order for a blue automatic Toyota Corolla with air-conditioning and power windows (but without the sports bumpers or tinted windows) enters the factory.

In a perfect pull system this means:
- one more engine block gets poured
- one more automatic transmission sub-assembly is delivered to the final assembly line.
- precisely 875 M5 screws are delivered (ok I made up that number)
- when the blue car body goes barrelling down the assembly line, an air-conditioning unit is manufactured to arrive at the assembly line at just the right time.

To achieve anything approaching this level of synchronicity is a special kind of magic. But I want to talk about WHY you'd do it. Why not just make make 500 engines, 500 air-conditioners, 500 transmissions and sit back and wait for the orders to pour in.

Why go to all the trouble?

When you don't buy more from suppliers than you can manufacture you don't have to waste money to have stock lying around gathering dust. When you don't manufacture more products than you can sell you're not wasting your time making the wrong thing. That's easy, anyone can see that.

The Lean Manufacturer takes it further than that: they look at the process involved in getting there. They recognise that while taking ANY forwards action is commendable, true perfection is unattainable; and that this fact should be seen as a motivator to remain constantly vigilant in the face of recent success.

A Lean Manufacturer is agile, able to change pace or direction at the drop of the hat. At all levels, from corporate direction and new model design through to deciding how many car-seats are to be delivered this hour, plans are worked and reworked right up until the last moment. The LM'er is able to respond to market demand.

While there is very little room for error in the Lean factory these things do happen: when a fault occurs at one station the ENTIRE line stops and EVERYONE rushes to that spot to fix the problem immediately. By committing themselves to the Lean path the weak links are quickly rooted out and strengthened.

When a factory operates according to a true pull-system everyone can be confident that their effort is valuable. People won't bust their guts for 3 weeks straight cranking widgets that are just going to sit in some warehouse somewhere, those widgets are going to be in the customer's hand by the end of the week: guaranteed.

How does this relate back to GTD?

So, you've got a ToDo list. Well done. When you organised you don't waste time doing things that don't need to be done. Ok. That's the easy part.

When you take it further and start applying GTD you learn WHY you have that list, and how it makes your life easier:

• your life will never be perfect, but the closer you get the more serene you will be. Every step in the right direction is great. Seriously, well done. Now you know that you can take that step: go take the next.
  
• when you have all your Stuff totally zipped up and captured you're able to change projects instantly. You can finish what you're doing and go play with the kids, safe in the knowledge that you aren't leaving some vital unclosed loop unrecorded.
• because you concentrate more on what needs to be done immediately you have more feedback on the doability of your commitments. What can look like an easy week's work on a ToDo list suddenly becomes 90 hours of cumulative Next-Actions! That's good information to have at the START of the week BEFORE it becomes a problem.
• When you use GTD you know that you're putting your efforts in the places you want your efforts to be. You're only ever bothering to do the stuff that leads you towards your goal.
  

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."