This is part 5 of a series of posts about identifying the constraint of a system and time for wrapping up and a conclusion (of the series, not the topic!).
Newcomers to Theory of Constraints understand quite easily the concept of bottleneck but are frequently puzzled when looking for them in a real-life process. Furthermore, people have usually difficulties to distinguish bottlenecks or Capacity Constraint Resources from the system’s constraint. As only the latter controls the Throughput of the whole system, meaning it does control the system’s profitability, constraint hunters should better not mismatch the focusing point.
Through the examples in the previous posts, readers can understand that there is no such a thing like a simple trick, neither ready procedure to find the constraint, but a necessary and sometimes painstaking investigation process.
If you missed previous posts, you may check:
- How to identify the constraint of a system? Part 1
- How to identify the constraint of a system? Part 2
- How to identify the constraint of a system? Part 3
- How to identify the constraint of a system? Part 4
Some constraints can really be well hidden and remain elusive, leading analysts to be wrong when identifying it. Because of the growing number of standard and regulatory requirements, the constraint is more and more often found in the paperwork process, in quality assurance or information flow. And this is the wrong place for the constraint to be.
How to be sure the constraint is found?
With so many opportunities to mismatch the constraint, how can one be sure about having found the constraint? Well, by definition the constraint controls Throughput. Elevating the constraint is like opening a valve, the flow through the constraint increases. And as, also by definition, all other resources have excess capacity compared to the constraint, the flow should soon reach the process’ output. This enables the organization to ship more, to ship on time, take more orders and shorten time-to-cash.
For non-profit organizations, the Throughput is expressed in “Goal units”, meaning achieve more of what the organization exists for, like treating more patients for a medical center, providing more food to the homeless, etc.
Now this is quickly noticeable if the downstream process steps are waiting for supplies from the constraint, otherwise the flow from the constraint may take longer to reach the process’ end.
Be aware of the S curve and Valley of despair
As with many improvement initiative, the result may be delayed to a point that some stakeholders come to the conclusion it doesn’t work. Before getting trapped in this pitfall, the project manager or the leader should be aware of the frustration with the S curve.
When dealing with bigger projects rather than improvement activities, it’s not only the S curve the project manager and the sponsors should worry about, but also the “Valley of despair”. This valley is a low in morale following the excitement and expectations about the benefits that the new project will bring. The drop in morale comes when issues and bugs let the new solution appear worse than the old. The challenge for the leader is to get everyone as quick as possible through the valley of despair, accommodate the new way or system and eventually recognize the benefits.
Keep on alert once the constraint is found!
Now once the constraint is properly identified and the efforts to exploit and elevate it begin, the leaders should immediately take care of the consequences of releasing more “goal units” through the constraint.
- First because the constraint will most probably move to another spot and again this can be anywhere in the process.
- Second because upstream as well as downstream process steps may be taken by surprise. Upstreams by an increase of demand in order to supply and exploit the increased capacity. Downstream by the flushing of the work in progress that may propagate a significant wave of workload.
- Third because management must anticipate any necessary action to sustain the flow at the new level, otherwise the success will only be sporadic and ultimately disappointing.
I recommend reading two other posts related to these warnings:
The search for the system’s constraint can be very simple and straightforward, but most often it is tricky and leads to identify wrongly some resources as culprits. It is no rocket science but needs investigation skills and rigor. Experience helps a lot and the good news is that taking care of constraints is never-ending, so experience may accumulate fast.