Necessary But Not Sufficient
One of the most precise and underused distinctions in improvement thinking. A necessary condition must be present for the goal to be achieved — but its presence alone does not guarantee the goal. Most improvement programmes declare success after achieving one necessary condition while others remain unmet. Goldratt and Dettmer gave this distinction a rigorous logical framework. Every improvement failure is, ultimately, a failure of sufficiency.
☰ Contents — click to expand
The logical distinction
Must be present. Not enough.
A condition that must be satisfied for the goal to be achievable. Without it, the goal is impossible. But its presence alone does not guarantee the goal — other necessary conditions may be unmet.
Oxygen is necessary for fire. It is not sufficient — you also need fuel and heat.
Guarantees the goal.
A condition or set of conditions whose presence alone guarantees the goal will be achieved. A sufficient condition is what you need to actually get the result — not just make it possible.
Oxygen + fuel + heat together are sufficient for fire. All three necessary conditions met simultaneously.
The practical implication is precise: every improvement goal has a set of necessary conditions — things that must be in place for the goal to be achievable. Achieving any one of them is progress. Achieving all of them simultaneously, and maintaining them, is sufficiency. Most improvement programmes achieve one or two necessary conditions, call it done, and wonder why the outcome does not follow.
A necessary condition is achieved: a new protocol is written, a technology is deployed, a staff training programme is completed, a structural change is made. The programme is declared successful. The outcome does not change. The response is confusion, frustration, or blame — because the logic seemed sound. The protocol was right. The technology worked. The training was delivered.
The error is treating a necessary condition as if it were sufficient. The protocol is necessary — but other necessary conditions (consistent compliance, adequate staffing, a feedback mechanism, a system that does not make workarounds attractive) remain unmet. The goal requires all of them. One is not enough.
Goldratt’s point — technology is necessary but not sufficient
Eliyahu Goldratt, the originator of the Theory of Constraints, made this argument most explicitly in his 1999 novel Necessary But Not Sufficient (co-authored with Eli Schragenheim and Carol Ptak). The book’s premise was a direct challenge to the enterprise software industry: implementing ERP, MRP, and advanced planning systems was necessary for a company to achieve world-class performance — but it was not sufficient. Technology without corresponding changes to management processes, measurements, and mindset would not produce the promised results.
The argument generalised beyond technology. Goldratt’s core insight from the Theory of Constraints was that every system has a constraint — a binding limitation that determines throughput. Addressing anything other than the constraint is necessary for some things but never sufficient to improve overall system performance. And addressing the constraint requires not just identifying it and applying a fix, but simultaneously changing the processes, measurements, and behaviours that have been built around accommodating it.
📊 Goldratt’s three conditions for a complete solution
In Necessary But Not Sufficient, Goldratt identified three conditions that together are sufficient to produce genuine, sustained improvement — any two are necessary but not sufficient:
1. The technology must be available and functional. This is the condition that organisations focus on almost exclusively. It is necessary. It is not enough.
2. The organisation’s processes and procedures must change to exploit the technology and the released constraint. Installing new technology while keeping old processes is like building a motorway and requiring vehicles to stop at every junction — the capacity is available but the system is not designed to use it.
3. The organisation’s measurements and incentives must change to align with the new processes. Old measurements will drive old behaviour even when new processes are in place. If clinicians are measured on the old metric, they will optimise for the old metric regardless of new protocols. Deming made the same point in Point 11: eliminate numerical quotas that conflict with quality. The measurement system is a necessary condition for sustained improvement — and the one most frequently left unchanged.
All three must change simultaneously. Change any two and the third will pull the system back to its old behaviour.
Dettmer’s Logical Thinking Process
H. William Dettmer formalised Goldratt’s thinking into the Logical Thinking Process (LTP) — a set of cause-effect thinking tools that make the necessary/sufficient distinction operationally precise. The LTP provides a structured way to answer the three questions that any improvement effort must answer:
What to change? What to change to? How to cause the change?
Current Reality Tree (CRT)
Maps the cause-effect relationships that produce the current undesirable effects. Identifies the root cause(s) — the small number of core problems that, if addressed, would eliminate most of the undesirable effects.
Future Reality Tree (FRT)
Maps what would need to be true for the goal to be achieved. The sufficiency test lives here: if we implement these changes, are they sufficient to produce the desired outcome — or do other necessary conditions remain unmet?
Prerequisite Tree (PRT)
Identifies the necessary conditions that must be achieved before the goal is reachable, and the obstacles that prevent each necessary condition from being met. Maps the path from here to sufficient.
Transition Tree (TT)
Sequences the actions required to move from the current state to the future state — in the right order, addressing each necessary condition in the sequence that makes the next one achievable.
The most important tool in the LTP for the necessary/sufficient distinction is the Future Reality Tree. It forces the question: if we implement the proposed change, is the resulting state sufficient to produce the desired outcome? If not — if other undesirable effects persist or new ones appear — the proposed change is necessary but not sufficient, and the additional necessary conditions must be identified before the full solution can be designed.
Applied to improvement programmes
The necessary/sufficient framework reframes every improvement programme question. Instead of “will this intervention work?” — which tends to produce a binary yes/no answer — it asks: “what are all the necessary conditions for the goal, which are currently met, and which are not?”
This reframing is valuable because it separates two very different types of failure that look identical from the outside:
Failure type 1 — wrong intervention. The intervention does not address a necessary condition for the goal. Fixing it will not help because it is not on the path to sufficiency. Example: retraining nurses in wrong-route medication administration when the necessary condition is physical connector incompatibility.
Failure type 2 — incomplete intervention. The intervention addresses a genuine necessary condition, but other necessary conditions remain unmet. Progress is real — the goal is now closer — but the outcome has not yet changed because sufficiency has not been reached. Example: deploying ENFit connectors in one trust while procurement has not mandated them nationally.
Type 1 failures are worth abandoning. Type 2 failures are worth completing. From the outside — from a Bootstrap CUSUM chart showing no change point — both look the same. The necessary/sufficient analysis is what distinguishes them.
Worked example — NHS Never Events
Bootstrap CUSUM on NHS wrong-route Never Events finds a flat process at 17.5 events per year for 15 years. The necessary/sufficient analysis explains precisely why.
Three of five necessary conditions are met. Two are not. The goal — elimination of wrong-route Never Events — requires all five simultaneously. Conditions 1, 2, and 3 are necessary but not sufficient. The Bootstrap CUSUM flat line at 17.5 events per year is the statistical record of a system that achieved three necessary conditions and stopped.
The sufficiency test
Before declaring an improvement programme complete, four questions constitute the sufficiency test:
- Have all necessary conditions been identified? Not just the obvious ones — the technological fix, the training programme, the new protocol. Also the measurement change, the accountability structure, the feedback loop, the procurement mandate. A Future Reality Tree makes this explicit.
- Have all identified necessary conditions been met? Not planned, not in progress — met. A condition that is 80% implemented is not met. A procurement mandate that has been recommended but not authorised is not met.
- Are all necessary conditions being maintained? A necessary condition that is met and then withdrawn — a CQUIN incentive that ends, a political focus that moves elsewhere — returns the system to insufficiency. Sufficiency requires all necessary conditions to be sustained simultaneously.
- Has Bootstrap CUSUM confirmed a structural change in the outcome measure? A structural change point at the predicted confidence level, in the predicted direction, within the expected lag window, is the objective confirmation that the system has moved to a new sufficient state. Without it, the sufficiency test has not been passed — regardless of how many necessary conditions appear to be met.
Applying the sufficiency test requires acknowledging that the current state is insufficient — which is uncomfortable when significant effort and resource have already been invested in achieving the necessary conditions that are met. The sunk cost of the training programme, the technology deployment, the protocol redesign creates pressure to declare success rather than acknowledge that further necessary conditions remain unmet. Goldratt identified this explicitly: the organisation celebrates achieving a necessary condition, reduces pressure for further change, and the system settles into a new equilibrium that is better than before — but short of the goal. The Bootstrap CUSUM change point is the honest arbiter: the goal was either achieved or it was not. The data does not care about the effort invested.
Bootstrap CUSUM as the sufficiency verifier
Bootstrap CUSUM is the objective answer to the sufficiency question. It does not assess whether necessary conditions are in place — that is the work of the Future Reality Tree and the sufficiency test. What it does is provide a dated, statistically defensible answer to whether the combination of necessary conditions that have been implemented is producing a permanent structural change in the outcome.
A Bootstrap CUSUM change point at 95% confidence or above, in the direction of improvement, within the expected lag window, is evidence of sufficiency. The system has moved permanently to a new mean. The conditions in place are collectively sufficient to produce and sustain the improvement.
The absence of a change point, in a series with adequate data, is evidence that sufficiency has not yet been reached — regardless of how many necessary conditions appear to be met. It is the signal to return to the Future Reality Tree and ask: what necessary condition have we missed, or what condition we thought was met is actually not?
📊 The complete necessary-sufficient-CUSUM cycle
1. Map the necessary conditions using a Future Reality Tree or equivalent. Identify all conditions that must be met for the goal to be achievable. Include technology, process, measurement, accountability, and sustainability conditions.
2. Apply the sufficiency test. Are all necessary conditions met? If not, which are unmet? Address the unmet conditions in the order specified by the Prerequisite Tree — some are prerequisites for others.
3. Pre-specify the Bootstrap CUSUM prediction. Once all identified necessary conditions are met, state the prediction: we expect a Bootstrap CUSUM change point in outcome measure Y within Z periods at W% confidence.
4. Apply Bootstrap CUSUM to the outcome measure periodically after implementation. A change point confirms sufficiency. The absence of a change point within the expected lag window signals that a necessary condition has been missed — return to Step 1.
5. Maintain all necessary conditions. A change point confirmed by Bootstrap CUSUM is not a signal to relax the conditions that produced it. Sufficiency requires all necessary conditions to be sustained. The dementia diagnosis rate was above target while the PM’s Challenge maintained political and financial pressure. When that pressure reduced, the rate began to drift. The necessary condition — sustained system-level commitment — was not maintained. See the dementia analysis.
Related concepts
This concept sits within a broader framework for understanding why improvement programmes succeed or fail. Start with Why Nothing Changes for the full picture, or go to Start Here for a guided introduction to the method.