What it is
According to Goldratt's Theory of Constraints, performance improvement of a system or process is achieved by identifying constraints - or bottlenecks - and working to fix the most limiting constraint in order to achieve higher system throughput.
"A system's constraint is nothing more than what we all feel to be expressed by these words: anything that limits a system from achieving higher performance versus its goal." - E. M. Goldratt
The theory states that every system has room for improvement and that the most limiting constraint bounds the current performance of a system. So, following that to its conclusion, removing the most limiting constraint will have the effect of instantly improving the performance of the overall system, which will then be limited by a different constraint.
The Theory of Constraints was first described by an Israeli management consultant called E. M. Goldratt in his 1984 book, The Goal (see Further reading). His theory builds on earlier work done within the field of manufacturing process and systems dynamics.
When to use it
- To identify and fix bottlenecks in a production process.
- To find ways to make production processes work more efficiently.
How to use it
The Theory of Constraints provides a set of five focusing steps designed for identifying and eliminating constraints within a system.
The following sections describe each step in more detail:
- Identify the system's constraints
To start, identify as many constraints as possible within the current system. These constraints are the bottlenecks that work to lower the overall throughput of the system. Once the list of constraints is complete, identify the most limiting constraint, the one that bounds the performance of the overall system and thereby most impacts the overall goal.
It is helpful to think of a system as a chain consisting of many individual links. Under extreme tension, the chain will fail at its weakest link. In other words, the performance of the overall system is bounded by its most limiting constraint. If you work to strengthen the weakest link, the performance of the overall system will be improved, and the new limiting factor will be the next weakest link.
- Decide how to exploit the system's constraints
Now that the most limiting constraint is identified, you should work to minimise the effect of that constraint without executing any expensive or time-consuming activities. In other words, you should try to look for some quick wins.
Make quick improvements to the throughput of the constraint. This can be thought of as making the most of what you have. Are there any obvious measures that can be taken to prevent this part of the system from being the most limiting constraint? Is the bottleneck caused by an outdated policy or procedure that could be changed (policy constraints are a surprisingly common occurrence)?
- Subordinate everything else to the above decision
Review the other connected parts of the system to ensure that they support the needs of the constraint. For instance, is one part of the system flooding the constraining part with requests in a software system? Could the calling code cache some results or be optimised in other ways to reduce the number of requests?
Once this is complete, you should reevaluate the system to determine whether the bottleneck identified is still the most limiting constraint or whether a different component now limits the system's overall performance. If the constraint has moved, you should move to Step 5.
- Elevate the system's constraints
If, after applying the previous steps, the constraint is still limiting the system's overall performance, elevate the priority of the work required to fix the bottleneck and proceed with this work until it is no longer the most limiting constraint.
Remember: any effort spent in improving the performance of anything but the weakest link is wasted, as it will have no impact on the overall throughput.
- Repeat the process
This step reminds us that there will always be a part of the system that limits the overall performance. After all, if nothing prevented a system from achieving better performance, its throughput would be infinite, which is impossible in a real-life system.
"In our reality any system has very few constraints and at the same time any system in reality must have at least one constraint." - E. M. Goldratt
Frequently asked questions (FAQs)
How effective is the Theory of Constraints for performance improvement?
In 1998, Steven Balderstone and Victoria Mabin from Victoria University of Wellington in New Zealand conducted some research into the effectiveness of the Theory of Constraints in the real world (see Further reading).
Balderstone and Mabin investigated the published results of Theory of Constraints implementation from over one hundred cases. In this data set, no failures or disappointing results were found. In summary, the following mean improvements were found:
- Lead times - 69% reduction
- Cycle times - 66% reduction
- Due date performance (meeting delivery promises) - 60% improvement
- Inventory levels - 50% reduction
- Revenue / throughput - 68% increase
- Combined financial variable (revenue / throughput / profit) - 82% increase
How thoroughly should the Theory of Constraints be applied to a system? How do I know when to stop?
By rigidly applying the Theory of Constraints, and thereby acknowledging that the performance of a system can constantly be improved, you can see that there will always be opportunities to work to remove constraints.
However, the theory should only be applied until the system performs comfortably as required. Any time spent working on performance improvements beyond that is likely wasted, as the system will never be pushed to those limits.
Therefore, it is essential that you monitor the system's performance according to requirements to know not only when they have been breached but also when they are consistently being achieved.
Balderstone, S. J. and Mabin, V. J. (1998) A Review of Goldratt's Theory of Constraints (TOC) - lessons from the international literature. Victoria University of Wellington, New Zealand. Available from https://www.tocinstitute.org/uploads/1/2/7/9/12796657/toc_impact_study.pdf [accessed 29 September 2021].
Goldratt, E. M. and Cox, J. (2014) The Goal: A Process of Ongoing Improvement, 4th Revised Edition. Great Barrington, MA: North River Press.
Kim, G., Behr, K. and Spafford, G. (2014) The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, 2nd revised edition. Portland, OR: IT Revolution.
Some of the links to products provided in this article are affiliate links. This means that the supplier may pay the owner of this website a small amount of money for purchases made via the link. This will have absolutely no impact on the amount you pay.