Eliyahu Goldratt first described the Theory Of Constraints (ToC) in his 1984 book, "The Goal", which focused on manufacturing and was a key catalyst for the revolution in the performance of manufacturing in subsequent years.

The Theory of Constraints shows us that in any process, there must be a single bottleneck that limits the total throughput of the process: in the same way that a chain has a weakest link, a process has a single slowest component.

Whilst it may be easy to improve some part of the process, if that component isn't the bottleneck, it will either have zero effect on the throughput because the bottleneck is upstream, or it will actually cause more pain in the system by adding pressure to the bottleneck, if the bottleneck is downstream.

This is why “Any improvements made anywhere besides the bottleneck are an illusion.”

In some systems, the bottleneck is clear to see, such as a narrow junction on a busy street, or a bend in a garden hose.

In some systems, especially those that don't have material, or "inventory" flowing through them, the constraint can be more difficult to see. This includes many business or technology processes such as software and product development.

Using the Theory of Constraints (ToC) to identify bottlenecks (constraints) in a process enables teams and organisations to decide where to focus optimisation work. When the optimisation, elevation, or removal of the constraint is complete, the process begins again to find the next constraint (because there is always the next one).

This practice assumes that you already have a way of measuring the process - such as looking at tickets in jira, cards on a kanban board, or other tools. If you don't, then you can use techniques such as MBPM or value stream analysis to identify where the bottlenecks could be.

Stage 1: Identify the constraint. Look at where "Work In Progress" (WIP) is piling up.

Stage 2: Exploit the constraint. Are there any quick improvements you can make to the throughput of this stage? This is essentially "making the most of what you have". Check to see if you've solved the constraint and moved the bottleneck somewhere else.

Stage 3: Subordinate the constraint. Look at the rest of the process. Are other stages really aligned with this stage? Is there something another stage could do that could improve the flow through this stage? Maybe other stages could add a little more documentation, make a few tweaks to their process, or take on some of the work? Check to see if you've solved the constraint and moved the bottleneck somewhere else.

Stage 4: Elevate the constraint. Maybe you need to add capacity or resources to the constraint? Can the constraint be increased in size or scale? Can you add more people, machines, or resources to it? Keep doing this until you've solved the constraint and moved the bottleneck somewhere else.

Stage 5: Repeat the process. You've just moved the bottleneck somewhere else. Find out where that is, and start again. This is a continuous process and there will always be a bottleneck somewhere!