The Evaporating Cloud
Every persistent constraint is kept in place by a structural contradiction — two legitimate requirements that appear mutually exclusive. The Evaporating Cloud makes that contradiction visible, names the assumption underneath it, and dissolves both by questioning whether the assumption is actually true. Goldratt called it “evaporating” because the contradiction doesn’t get resolved through compromise. It evaporates when the assumption is removed.
If a constraint has persisted despite repeated improvement attempts, it is almost certainly being kept in place by a contradiction that has been assumed away rather than questioned. The constraint is not a resource problem or a process problem. It is a logical conflict between two legitimate requirements, sustained by an assumption that nobody has examined.
The Evaporating Cloud does not resolve contradictions through compromise — trading some of one requirement for some of another. It dissolves them by finding the assumption that made them appear incompatible and asking whether that assumption is actually true.
☰ Contents
What the Evaporating Cloud is
The Evaporating Cloud — also called the Conflict Resolution Diagram — is one of Goldratt’s Thinking Processes, developed in It’s Not Luck (1994). It was designed to answer the question that the Current Reality Tree could not: why does the constraint persist despite everyone knowing it exists?
Goldratt observed that persistent constraints are almost never resource problems. If a constraint were simply a resource problem, organisations would add resource and the constraint would dissolve. Persistent constraints persist because of a deeper structural conflict: the organisation simultaneously needs two things that appear mutually exclusive. Every attempt to satisfy one requirement makes the other harder to satisfy. The organisation is trapped — not by lack of resource but by a contradiction it has never made explicit.
The Cloud makes the contradiction explicit — visible, nameable, examinable. And in doing so, it reveals the assumption that is sustaining the contradiction. Challenge the assumption, and the contradiction often dissolves entirely — not through compromise but through a solution that satisfies both requirements simultaneously.
The name matters. “Evaporating” is not the same as “resolving.” Resolving a conflict through compromise means each side gives something up — some standardisation, some customisation; some flow, some safety; some speed, some thoroughness. The compromise leaves both sides partially dissatisfied and the underlying assumption intact.
Evaporating means the conflict ceases to exist because the assumption sustaining it has been removed. Paul O’Neill did not compromise between safety and productivity at Alcoa — he demonstrated that the assumption underneath the conflict was false. Both improved simultaneously. Gloucestershire did not trade some flow for some safety — SHMI fell for 14 consecutive months while throughput rose. The conflict evaporated because the assumption that they were in conflict was never empirically true.
If your solution requires one side to accept less of what it legitimately needs, you have resolved the conflict rather than evaporated it. The underlying assumption is still in place — and the conflict will return.
The five-box structure
| Box | Label | The question it answers |
|---|---|---|
| A | Objective | What is the shared goal both sides of the conflict are trying to achieve? |
| B | Requirement 1 | What does side 1 need in order to achieve the objective? |
| C | Requirement 2 | What does side 2 need in order to achieve the objective? |
| D | Prerequisite 1 | What specific action or condition does Requirement 1 demand? |
| D′ | Prerequisite 2 | What specific action or condition does Requirement 2 demand? (conflicts with D) |
How to draw one
Real examples
A — Objective: Patients leave hospital when medically fit
B — Requirement 1: NHS needs faster discharge
C — Requirement 2: Local authority needs to control social care spending
D: Discharge patients immediately when ready
D′: Slow discharge to avoid exceeding social care budget
Conflict: Immediate discharge vs budget-controlled discharge
The assumption: NHS and social care budgets must remain separate
The injection: Shared ICS budgets making the cost of delayed discharge visible to both parties simultaneously. Not a compromise — an evaporation. The conflict dissolves when financial risk is shared rather than separated.
A — Objective: Deliver value to customers profitably
B — Requirement 1: Business needs standardisation to scale
C — Requirement 2: Customers need customisation for their context
D: Standard product for all customers
D′: Customised product for each customer
Conflict: One size fits all vs bespoke for each
The assumption: Standardisation and customisation must apply at the same level of the system
The injection: Standardise the platform; customise the configuration. Toyota, iPhone, NHS discharge pathway. Not a compromise — both requirements met fully at different levels.
A — Objective: Deliver high quality software on time
B — Requirement 1: Business needs faster delivery
C — Requirement 2: Customer relationship needs to be maintained
D: Redesign the customer acceptance testing process
D′: Don’t challenge the customer’s process
Conflict: Redesign CAT vs protect the relationship
Two assumptions keeping the conflict in place:
Assumption 1 (on the B→D arrow): “Redesigning the CAT process will take significant time and effort AND is technically achievable.” This is the assumption the tech team acts on immediately — it is visible, satisfying to address, and produces a technically correct solution. The engineering trap: the team redesigns the process, the customer doesn’t adopt it, nothing changes. The technical solution addressed the wrong assumption.
Assumption 2 (on the C→D′ arrow): “Challenging the customer’s acceptance testing process will damage the relationship.” This is the assumption that has never been tested. It is invisible, uncomfortable to examine, and gets deferred indefinitely. It is also the assumption that, if false, dissolves the conflict entirely — without any redesign required.
The injection: Test Assumption 2 before building Assumption 1. Show the customer the Kanban board — the delivery timeline, the weeks lost at CAT, the cost in their terms. Most customers, shown that CAT is costing them delivery time, will engage rather than resist. The conflict evaporates not through a technical redesign but through a conversation that was never had because an assumption was never tested. Not a compromise. An evaporation.
A — Objective: Deliver high quality patient care
B — Requirement 1: Hospital needs faster patient flow
C — Requirement 2: Patients need safe, thorough care
D: Speed up processes, reduce time per patient
D′: Maintain thoroughness, take the time needed
Conflict: Speed vs thoroughness
The assumption: Speed and thoroughness are in conflict
The injection: Gloucestershire’s SHMI fell 14 consecutive months while throughput rose. O’Neill at Alcoa: both improved simultaneously. The assumption was never empirically true. Not a compromise — the conflict evaporated in the data.
Step 1 — Prepare the data before the conversation
Don’t go to the customer with a complaint. Go with evidence. Quantify the constraint precisely:
- Average time in CAT queue per release (weeks)
- Number of releases delayed by CAT in the last 12 months
- Cost to the customer in delayed capability
- Your own cost in holding releases, re-testing, version proliferation
Data makes the conversation about shared evidence rather than competing interests. It depersonalises the problem — not “you’re slowing us down” but “here is what the process is costing both of us.”
Step 2 — Three questions in the conversation
Q1: “Is this picture accurate from your side?” — Give them the chance to correct the data. They may have context you have never seen. This is Going to the Gemba applied to the customer relationship.
Q2: “What is making CAT take this long from your side?” — You don’t know their constraint. You cannot design the injection until you understand it.
Q3: “What would need to be true for this to be faster?” — The injection question. Opens the solution space without prescribing a solution. Invites co-design. Use a Parking Lot to capture ideas that emerge but aren’t the primary constraint — keeping the conversation focused on the one assumption being challenged.
Four scenarios — what is likely to come out
Scenario A — Their constraint is resource. CAT takes six weeks because they have one person doing it part-time. Injection: dedicated CAT resource or shared testing environment. Solvable within the relationship.
Scenario B — Their constraint is trust. CAT takes six weeks because they don’t trust your releases to be stable. Every release needs extensive testing because previous releases had defects. The injection points back at your quality process, not their CAT process. The Evaporating Cloud shifts — the real conflict is between release speed and release quality. Bootstrap CUSUM on defect rates post-release tells you whether that assumption is true.
Scenario C — Their constraint is regulatory. CAT takes six weeks because a regulator requires a specific sign-off before any software change goes live. This is the Boundary trap — the constraint sits outside both organisations’ authority. Requires a Level 3 Deep fix: engaging with the regulatory framework itself, not the customer’s internal process.
Scenario D — Their constraint is assumption. CAT takes six weeks because “that’s how long it takes” — nobody has ever questioned it. When you show the data, they discover the actual testing takes two days. The six weeks is largely waiting time. Injection: a new trigger mechanism that starts CAT immediately when a release is ready rather than when the customer’s calendar allows. No new resource. No regulatory engagement. A process redesign that both parties benefit from. The most common outcome — and the most satisfying.
The Bootstrap CUSUM test
After the conversation and the agreed injection, Bootstrap CUSUM on CAT cycle time confirms whether the injection produced a structural change point or activity without improvement. The pre-committed prediction: “CAT cycle time will fall from X weeks to Y weeks within Z months of implementing the new trigger mechanism.” The data is allowed to say no.
The TRIZ connection
The Evaporating Cloud and TRIZ contradiction analysis are independently developed responses to the same insight: persistent problems are persistent because of a structural contradiction, not a resource shortage. TRIZ calls it a technical or physical contradiction. Goldratt calls it a conflict. Both say the same thing: the solution is not a compromise between the two sides but the removal of the assumption that made them appear incompatible.
TRIZ adds one further insight: resolve the contradiction in a different dimension. Standardisation and customisation appear to conflict at the product level. They do not conflict when standardisation applies to the platform and customisation applies to the configuration. The conflict dissolves when you change the level at which each requirement operates.
This is the injection in Evaporating Cloud language: a condition that satisfies both requirements simultaneously by changing the dimension in which they operate. The assumption was not that standardisation and customisation are incompatible — it was that they must apply at the same level of the system. That assumption is almost always false.
How contradictions dissolve
Goldratt called it “evaporating” rather than “resolving” for a precise reason. Resolved suggests a negotiated settlement — each side gives something up. Evaporated means the conflict ceased to exist because the structure that produced it was changed.
Paul O’Neill at Alcoa did not resolve the conflict between safety and productivity by trading some safety for some productivity. He evaporated it by demonstrating that the assumption underneath the conflict — that fixing safety processes costs productivity — was false. When processes are fixed at the level that causes harm, they are also fixed at the level that causes waste. Both improve simultaneously. The conflict evaporated because the assumption that sustained it was removed.
Gloucestershire did not resolve the conflict between flow and safety by trading some of each. They evaporated it by holding Quality, Scientific Approach, and All One Team as a single system rather than as competing workstreams. The assumption that flow and safety are in conflict was never empirically tested. The data — SHMI falling for 14 consecutive months while throughput rose — removed the assumption permanently.
Bootstrap CUSUM — the test
The Evaporating Cloud identifies the injection — the condition that would dissolve the conflict. Bootstrap CUSUM tests whether the injection, once implemented, has produced a structural change point in the outcome metric.
A pre-committed prediction made before the injection is implemented specifies what metric should change, in what direction, within what timeframe. Bootstrap CUSUM confirms whether it did. If a change point appears — the assumption was correctly identified and the injection correctly dissolves the conflict. If a flat line appears — either the wrong assumption was challenged, or the injection was not fully implemented, or the conflict has a deeper layer that has not yet been made visible.
Test whether your injection dissolved the constraint
Upload your outcome metric to the StepChange Analyzer. Bootstrap CUSUM will confirm whether the Evaporating Cloud produced structural change — or whether the constraint has a deeper assumption still to be surfaced.
▶ Open the StepChange Analyzer