In order to deal with a bottleneck, you must first realize you have one.
As mentioned in the last article, “This team is always having problems”, bottlenecks have counterintuitive manifestations.
If, however, you’re aware of this, and you want to improve your results instead of blaming people, there are some things you can do.
Identifying the Problem
There is only ever one bottleneck at a time. If two processes have the same pace, the current bottleneck is the upstream one. When you fix that, the next one is the bottleneck.
Adding capacity before or after the bottleneck will have no effect (or bad effects if you use it to produce more work that can’t be finished).
So it’s important to find the issue.
In knowledge work, we can do this by looking at what teams are generally complaining of having too much to do, or getting behind on their delivery dates.
If you have a ticketing system, the teams that have ever growing backlogs of projects and requests are usually a bottleneck in your process.
Now What?
Stop creating work that can’t be finished.
Prematurely starting projects that don’t have resources available to finish them is the source of your problems. It is, by definition, wasteful.
Inventory that can’t be sold won’t be as valuable when version 2 comes out from your competitors (or you) next year. Piling it up isn’t useful.
Control the release of work, and you’ve more or less won.
How do we control the release of work?
In The Goal (yes, this may be one of my favorite books), Drum-Buffer-Rope (DBR) is introduced.
Drum-Buffer-Rope (DBR) is a simple method of letting the constraint control the flow of work.
The drum refers to the constraint setting the pace.
The buffer refers to the amount of work that needs to be ready at the constraint so that the constraint is never left idle. Idle time at the constraint is production time lost forever.
The rope refers to the constraint pulling work, rather than having work pushed into it. This allows the constraint to avoid the setup and teardown costs of stopping a job midway.
In knowledge work, we could identify team dependencies for work that needs to be done, and only release work when that team will have a space for it to get done.