Steve Fenton

Limit work in progress and actually deliver

There are so many metaphors that can help to explain this theory and I have used a good number of them – from CPU context switching to balancing limited power between two railways and beyond.

Today, I’ve settled on filling up water containers.

I’ll make this really simple up front. The water containers are projects. The water is your people. This isn’t difficult to understand… but it is such an important business lesson.

If you have a queue of five customers with various water containers, dividing your limited water flow into all five containers means all five customers wait a long time. You will look absolutely rubbish to five customers.

By filling just one container at a time, you delight a a couple of customers, please a couple of others and are no worse off with the last one.

Let’s put that into numbers. We’ll assume a tap rate of 1l per minute.

Example one: they all want roughly the same amount of water (500ml).

By concentrating on one customer at a time it will take 30 seconds in total to supply the water to the first customer. Customer one is delighted.

By trying to please all five customers at once, it will take 150 seconds in total to supply the water to the first customer. Customer one is annoyed.

Let’s compare the rest of the customers:

Customer One At A Time All At Once
Customer 1 30 150
Customer 2 60 150
Customer 3 90 150
Customer 4 120 150
Customer 5 150 150
Average 90 150

You may imagine that customers 1, 2 and 3 would be utterly pleased when using “One at a Time Limited”. Customer 4 will be moderately happy. Customer 5 won’t know the difference between “One at a Time Limited” and “All At Once Inc”.

Of course, this is remembering that switching between glasses (just like switching between projects) in an attempt to keep them all in flight at once leads to waste, so the 150 seconds calculated number would, in reality, be even worse.

But we already know this right – because companies that try and juggle lots of projects concurrently often fail to ever finish a single project.

You can play with the numbers – try making it so different customers need different amount of water, or try dividing the stream in something other than equal measures or some other trick. What you’ll discover is that you suddenly need to dedicate people to co-ordinating the complexity. How do we make sure that our best customer gets twice as much time at the tap? How do we calculate these times once the customer with a low water requirement is sated, which means dividing things four ways until the next customer has their water? I’ll bet you’ll need a whole bunch of people and software and meetings and jostling for position once you try to do anything more complex than an even division. Oh yeah – that is what companies do… instead of limiting the work in progress. You haven’t even accepted that not all water is equal yet (and I bet you call them resources, rather than people, as if they were as similar as two cups of water).

Chopping and changing constantly doesn’t work at the program level, the project level, the product level, the task level – at any level at all.

Pick the stuff that is really critical to your business and get on and finish it. Nothing else needs to be in flight right now – it can wait until you have actually delivered something.

Please note – I am not advocating putting all of the people on a single project, because we all know that you can only cut a cake into so many pieces while still being able to say that “everyone ate cake”. I’ll bet that you haven’t reached this point though and that you are trying to do too much at once…

Written by Steve Fenton on