Finding the Real Constraint
Most improvement programmes address the wrong constraint. The result is effort, activity, and cost — with no detectable change in system throughput and no Bootstrap CUSUM change point. This page gives you a practical six-phase process for finding the real constraint before designing the solution — drawing on Goldratt’s Theory of Constraints, TRIZ contradiction analysis, SIT, and systems thinking.
Before designing a solution, check the four traps: are you fixing the loudest symptom, a constraint outside your boundary, a constraint that has already moved, or an absence rather than a process failure? Designing a good solution for the wrong constraint produces a flat Bootstrap CUSUM line.
The constraint and the contradiction are usually the same thing seen from different angles. If the problem has persisted despite repeated attempts to fix it, there is a structural contradiction keeping it in place. Name both sides of that contradiction before designing the solution.
☰ Contents
The four constraint traps
These four patterns account for the majority of constraint misidentifications. Check each one explicitly before proceeding to solution design.
| Trap | What it looks like | The test |
|---|---|---|
| 1. The loudest symptom becomes the assumed constraint | The most visible, most complained-about problem gets the resources. A&E waiting times are loud. Corridor care is visible. Ambulance handovers make headlines. But loudness is a function of where pain surfaces, not where the constraint sits. The discharge constraint is quiet — it lives in local authority budgets far from operational noise. | Ask: if we fixed this completely, what would system throughput do? If the answer is "improve significantly" — it may be the constraint. If the answer is "we'd hit the next bottleneck within weeks" — it's a symptom, not the constraint. |
| 2. The constraint is outside the organisational boundary | If the constraint sits in a partner organisation, a supplier, a regulator, or a different budget — it won't be identified because there's no authority over it. The instinct is to look inside your own boundary because that's where you have leverage. The system doesn't care about your boundary. | Map the full value stream, not just your organisation's portion of it. Ask: where does work accumulate — inside or outside our boundary? If the largest queue is outside, the constraint is outside. A Level 3 fix is required. |
| 3. The constraint has moved and nobody noticed | A previous improvement programme successfully elevated a constraint. The system improved. Then the constraint shifted to the next weakest link — but the programme continued targeting the original constraint. Effort is now applied to a non-constraint. Diminishing returns are blamed on the method, not the misidentification. | Re-run the constraint identification process after every confirmed Bootstrap CUSUM improvement change point. Goldratt’s Step 5: don’t let inertia become the next constraint. |
| 4. The constraint is an absence, not a process failure | Goldratt’s framework focuses on process constraints — where work accumulates in a flow. But many modern constraints are structural absences: no shared budget mechanism, no scaleable operating system, no workforce pipeline, too much customisation preventing standardisation. These don’t show up as queues. You have to ask for them explicitly. | Ask: what would need to exist that currently doesn’t for this problem to dissolve? If the answer is a new capability, a new structure, or a new relationship rather than a faster process — the constraint is an absence. Trimming (SIT) and the Ideal Final Result (TRIZ) are the right tools. |
The constraint is always a contradiction
This is the single most powerful insight from combining Goldratt with TRIZ. Every persistent constraint — one that has survived repeated improvement attempts — persists because of a structural contradiction: two requirements that appear mutually exclusive. The constraint is not just a bottleneck in a flow. It is a tension between two legitimate needs that the system cannot simultaneously satisfy.
The standardisation/customisation contradiction
“We can’t standardise because customers need the solution customised.”
This contradiction appears constantly in product and service design. TRIZ’s answer: resolve it in a different dimension. Standardise the platform, customise the configuration. Toyota standardises the production system while offering enormous model variety. The iPhone standardises the hardware platform while enabling infinite app customisation. The NHS equivalent: standardise the discharge pathway while locally configuring the care package.
The contradiction dissolves when you separate the levels at which standardisation and customisation apply. The constraint was not a process problem — it was an assumption that standardisation and customisation must apply to the same level of the system simultaneously.
| Domain | The contradiction | The resolution |
|---|---|---|
| NHS discharge | NHS needs patients to leave faster AND local authorities need to control social care spending | Shared budgets that make the cost of delayed discharge visible to both parties simultaneously — the contradiction dissolves when financial risk is shared rather than separated |
| Standardisation vs customisation | Business needs standardisation to scale AND customers need customisation for their context | Standardise the platform/pathway; customise the configuration/parameters. Separate the levels at which each applies |
| Quality vs speed | Increasing speed appears to reduce quality AND improving quality appears to reduce speed | Toyota resolved this by discovering that quality and speed are not in conflict when defects are eliminated at source — the contradiction was based on a false assumption about where quality is created |
| Centralisation vs local autonomy | Central control ensures consistency AND local autonomy enables responsiveness | Centralise standards and accountability; decentralise method and delivery. The ICS model attempts this — it fails when accountability is centralised without shared financial risk |
Use this sentence structure: “We need [A] because [reason A is necessary] AND we need [not-A] because [reason not-A is necessary].” If you cannot complete both sides of that sentence, you haven’t found the contradiction yet. If you can complete both sides and both sound legitimate — you have found the constraint. The solution space lies in challenging the assumption that A and not-A cannot coexist.
The six-phase process
This process takes approximately 90 minutes with a team that has relevant knowledge of the system. It combines the most useful elements of Hurson’s Think Better, Goldratt’s thinking processes, and TRIZ contradiction analysis into a single practical sequence.
Diverge List every symptom — without filtering
Write every Undesirable Effect (UDE) on the board. No evaluation, no prioritising, no "we already know that one." Generate freely. Include symptoms that feel unrelated. Include symptoms from outside your organisational boundary.
Then apply Hurson’s four Cs: Cull (remove duplicates), Cluster (group related symptoms), Combine (merge overlapping ones), Clarify (rewrite vague ones as specific observable effects).
One discipline: separate symptoms from causes. A symptom has something upstream causing it. A root cause has nothing upstream — it simply exists as a structural condition. Do not try to identify causes yet.
Converge Find the clusters — what symptoms share a common cause?
This is the hardest visibility problem in the whole process. The root cause is often buried beneath multiple layers of symptom. Meadows’ iceberg model describes exactly this: events (visible) sit above patterns, which sit above structures, which sit above mental models. Most teams cluster at the event level — grouping symptoms that look similar — rather than the structural level where root causes actually live. Joiner’s levels of fix make the same point: the root cause is at Level 3 (system) while the symptoms surface at Level 1 (output). Clustering must drive down through the layers, not stay at the surface.
Look at the clustered symptoms and ask: what single cause, if true, would explain this whole cluster? This is the Current Reality Tree in its simplest form — not the full formal tree, just the branching question.
For each cluster, write a candidate root cause. Do not evaluate whether it is correct yet. You are generating candidate causes, not confirming them.
Run the throughput test on each candidate: if this cause were eliminated, which symptoms would resolve? The candidate that resolves the most symptoms across the most clusters is the most likely root cause.
Converge Check the four traps
Run the four-trap checklist against your candidate root cause before proceeding:
1. Are we focusing on the loudest symptom rather than the binding constraint?
2. Is the real constraint outside our organisational boundary?
3. Has the constraint moved since we last looked?
4. Is the constraint something we don’t have rather than something we’re doing wrong?
If any trap fires, revise the candidate root cause before continuing.
Converge Name the contradiction
Ask: why has this constraint persisted despite previous attempts to fix it? Complete the contradiction sentence: “We need [A] because [reason] AND we need [not-A] because [reason].”
If both sides sound legitimate — you have found the structural contradiction that is keeping the constraint in place. Write it on the board explicitly. This is the most important single output of the process.
Then ask: what assumption underlies this contradiction — and is that assumption actually true? Challenge the assumption before designing the solution. Many constraints dissolve when the assumption is examined rather than accepted.
Diverge Describe the Ideal Future — then generate solutions
Ask TRIZ’s Ideal Final Result question: what would the system look like if this constraint simply didn’t exist — with no cost, no politics, no history? Describe it in specific, observable terms. This is your target state.
The classic TRIZ example: the IFR for cleaning windows is “the windows clean themselves.” That sounds absurd — until you ask what property of the glass could make dirt not adhere, or what external agent (rain, sunlight) could perform the cleaning function. Hydrophilic self-cleaning glass is the real-world solution. The IFR question unlocked it by removing the assumption that cleaning requires an agent applying effort.
Applied to NHS discharge: the IFR is “patients leave hospital the day they are medically fit, automatically, with no delay.” Working backwards: what prevents that? No community capacity. No shared incentive. No single responsible person. Each prevention is a candidate constraint.
Then ask Hurson’s generative question: How might we get from here to there? Generate freely — no evaluation. Include solutions that seem impossible. Include solutions from other industries that have resolved the same contradiction (TRIZ calls this analogical thinking — how did Toyota resolve quality vs speed? How did Netflix resolve selection vs availability?).
Apply SIT’s Trimming question: what could we remove from the current system that would make the constraint disappear or weaken? The instinct is always to add resources. Trimming asks the opposite.
Converge Evaluate and make the testable plan
Filter candidate solutions through three questions:
1. Does this address the constraint directly — or a symptom?
2. Does this require authority we have — or authority we’d need to acquire?
3. Would Bootstrap CUSUM detect a change point if this worked?
The third question is the most important. If you cannot describe a specific metric that would show a statistically significant structural shift within a defined timeframe — the solution is not yet concrete enough to implement. Refine it until Bootstrap CUSUM could confirm or refute it.
Output: one testable plan with a pre-committed prediction — metric, direction, timing, confidence threshold, and balancing measures. This is the input to Step 7 (PDSA) of the improvement method.
If the team does not have data on where work accumulates, where queues form, or what the current rates are for key metrics, Phase 1 will take longer. The most common reason this process stalls is that symptoms are described in vague terms (“communication is poor,” “the system is broken”) rather than as specific, measurable Undesirable Effects. Spend the time in Phase 1 making every symptom concrete and measurable — the rest of the process depends on it.
TRIZ and SIT — the useful bits
TRIZ (Theory of Inventive Problem Solving) was developed by Genrich Altshuller from analysis of 400,000 patents. SIT (Systematic Inventive Thinking) distilled TRIZ into five practical patterns. Both are powerful but have steep learning curves. These are the elements most directly applicable to constraint identification and improvement design.
| Tool | Source | The one question it contributes | NHS example |
|---|---|---|---|
| Contradiction analysis | TRIZ | What two legitimate requirements are in conflict — and what assumption makes them appear incompatible? | NHS needs faster discharge AND councils need to control budgets. Assumption: these budgets must remain separate. Challenge: shared ICS budgets dissolve the contradiction. |
| Ideal Final Result (IFR) | TRIZ | What would the system look like if the constraint simply didn’t exist, with no resources and no cost? | Patients leave hospital the day they are medically fit, directly to appropriate community care, with no delay. Work backwards from this to find what is preventing it. |
| Trimming | SIT | What component of the current system could be removed, with its function redistributed to something already present? | Remove the separate discharge coordinator role; redistribute the function to the ward nurse who already knows the patient. Fewer handoffs, faster discharge, no additional resource. |
| Task Unification | SIT | What additional job could be assigned to an existing component without adding new resources? | The ICS lead who already manages NHS-council relationships also holds the shared discharge budget — one person, two previously separate functions, shared accountability. |
| Attribute Dependency | SIT | What two variables that are currently independent could be linked so that one automatically responds to the other? | NHS discharge funding that automatically increases when delayed transfer rates rise — removing the current separation between the organisation that bears the cost and the one that controls the solution. |
| Resolve in a different dimension | TRIZ | Can standardisation and customisation apply at different levels of the system simultaneously? | Standardise the discharge pathway (the platform); customise the care package (the configuration). The contradiction between standardisation and local flexibility dissolves when applied to different levels. |
Other tools for finding the constraint
| Tool | Best for | Key question |
|---|---|---|
| Current Reality Tree (CRT) | Complex systems with many interrelated symptoms. Builds a full causal map from symptoms to root cause using if→then logic. | What single root cause, if true, would explain all these symptoms simultaneously? |
| Value Stream Mapping | Flow-based processes. Maps every step, identifies where inventory (patients, work) accumulates. The largest queue is upstream of the constraint. | Where does work wait longest — inside or outside our boundary? |
| Iceberg Model | Distinguishing events (visible symptoms) from patterns, structures, and mental models. Forces intervention above the event level. | What structural condition is producing this pattern — and what mental model is preventing us from changing it? |
| Pre-mortem | Quick constraint identification before implementation. Imagine the project has failed — why? | If this intervention produces no Bootstrap CUSUM change point, what will have been the reason? |
| Cynefin framework | Deciding which approach to use. Complex problems require probe-sense-respond rather than analyse-design-implement. | Is this a complicated problem (right answer exists, needs expertise) or a complex one (right answer emerges from experimentation)? |
| Fault Tree Analysis | Safety-critical systems. Top-down deductive logic from undesirable outcome to combinations of causes. | What combinations of conditions must be simultaneously true for this undesirable outcome to occur? |
How Bootstrap CUSUM confirms you found the right constraint
The ultimate test of constraint identification is empirical, not analytical. If you have correctly identified and addressed the binding constraint, Bootstrap CUSUM applied to your primary outcome metric will detect a structural improvement change point within the expected timeframe. If it does not — if the data shows a flat line — the analysis was incomplete. You addressed a non-constraint, a symptom, or a constraint that was outside your system boundary at the wrong level.
📝 The pre-committed prediction as the final output
The output of Phase 6 is a pre-committed prediction written before implementation:
- Which metric will move — the leading indicator, not just the outcome
- Which direction — up or down
- Within what timeframe — how many periods after the intervention
- At what confidence threshold — 90%, 95%, or 99%
- What balancing measures you will monitor simultaneously
If Bootstrap CUSUM detects the predicted change point — you found the real constraint. If it does not — return to Phase 2. The flat line is not a failure. It is the most precise diagnostic available: the constraint was not where you thought it was.
Test whether you found the right constraint
Upload your outcome metric data to the StepChange Analyzer. Bootstrap CUSUM will tell you whether a structural change point appeared — and date it precisely so you can verify it coincides with your intervention.
▶ Open the StepChange Analyzer