“Spending” Efficiency to Go Faster
Have you ever been on a project where some person or group is holding up the works? They are called the “bottleneck” station, and here are some usual and unusual strategies for improving output in the presence of various bottlenecks.
In any project or organization, some person, group, or station inevitably acts as a bottleneck to the organization’s output. This is, of course, trivially true: Once the output of that station improves so it is not the bottleneck, some other station becomes the limiting factor.
For just that reason, I will not discuss in this article options about improving the performance at individual stations. I will, rather, discuss ways to improve total system results once you have tried all you can think of for the key stations. If you find a way to improve the performance at the bottleneck station, then you get to start all over, working out where the new bottleneck is and how to improve total system performance in the presence of that bottleneck.
Assuming, then, that you have done all you can to improve the output ability at the bottleneck station, it is sometimes possible to further improve output by putting attention on the non-bottleneck stations.
The odd part about these strategies is that when we use the spare capacity at the non-bottleneck stations, we will sometimes deliberately allow “rework” in order to gain an advantage at the bottleneck station. This is counterintuitive to most people: Most of our industry is founded on the notion that we should avoid rework like the plague.
I will refer to this as “spending” efficiency locally for a global gain.
Once you start looking for this, you will see people in ordinary life doing exactly that: Those who have a bit of spare time find ways to help the bottleneck group and streamline the overall flow. The way in which efficiency is best spent differs according to the situation. Taking a look at those alternatives is what this article is about.
Alistair Cockburn
http://www.stsc.hill.af.mil/crosstalk/2009/01/0901Cockburn.html
200812 software process improvement theory of constraints