> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Conflict Resolution Diagram

> Conflict Resolution Diagram draws one shared goal, two needs, and two clashing actions, then tests the assumption that makes the clash look necessary.

<Info>
  **Category**: Methods<br />
  **Type**: Conflict-Structuring Method<br />
  **Origin**: Eliyahu M. Goldratt, evaporating cloud, 1990; widely taught in *It's Not Luck* (1994)<br />
  **Also known as**: Evaporating Cloud, Conflict Cloud
</Info>

<Note>
  **Quick Answer** — Conflict Resolution Diagram is a method for mapping a stubborn clash as one shared objective, two needs, and two actions that seem unable to coexist. Eliyahu M. Goldratt introduced it in 1990 as the evaporating cloud, inside the Theory of Constraints. The key insight is that an assumption often holds the fight in place, and a new condition can retire that assumption while both needs stay intact.
</Note>

## What is Conflict Resolution Diagram?

A Conflict Resolution Diagram is a logic map that sets out one shared objective, two needs that objective requires, and two actions that seem unable to coexist.

> The clash usually sits between two actions. The objective and both needs can be legitimate at the same time.

Picture a tug-of-war rope tied to a stake, with each side pulling so the tent will stand. The diagram asks whether that stake is sound. The standard drawing has five statements: objective A, needs B and C, both required for A, and actions D and D-prime. D is what one side believes it must do to secure B, and D-prime is what the other side believes it must do to secure C. Those two actions are the pair that cannot both be done. The lines between the statements are necessity claims, and you read each one in this form: in order to have this, we must have that, because of some assumption.

People usually enter at the actions, such as hire or refuse, a large batch or a small one, stay or go. The diagram moves the conversation from those actions to the needs, and then to the because. That is a different job from [force-field analysis](/methods/force-field-analysis), which lists pressures for and against a change, and it is different from scoring a list of options. The work here is to find which "must" is doing the damage.

### Conflict Resolution Diagram in 3 Depths

* **Beginner**: Write the two demands, the need each demand protects, and one objective both sides would sign. Read the five lines aloud before you debate who wins.
* **Practitioner**: Under each arrow, finish the sentence with "because." Pick one assumption you can test this week. Design a new condition that still serves both needs, then check that neither need was quietly cut in half.
* **Advanced**: The arrow claims necessity, which is stronger than preference. Chronic conflicts often survive because a useful action was promoted into the only action. A vague objective such as "success" makes every new idea look wise, because nobody can tell whether A happened.

## Origin

Conflict Resolution Diagram comes from Eliyahu M. Goldratt's [Theory of Constraints](/methods/theory-of-constraints), where he used it to invent a simple way through a dilemma.

The drawing appears as its own chapter in his 1990 book *What is this Thing Called Theory of Constraints and how should it be implemented?* (North River Press). The chapter is about inventing simple solutions. In 1994 the business novel *It's Not Luck* carried the tool, with the rest of his thinking processes, to a wide managerial audience. Goldratt's name for the drawing was the evaporating cloud. Accounts of the tool, following Lisa Scheinkopf's *Thinking for a Change*, trace that name to Richard Bach's 1977 novel *Illusions*, in which characters clear a cloud by taking it out of their thinking. The aim is similar in spirit. Examine the assumption, and the dilemma can disappear. H. William Dettmer's *The Logical Thinking Process* (2007) is a standard manual of these tools and also calls the same drawing a conflict resolution diagram.

Goldratt's best-known illustration is the fight over batch size, with a shared objective of a lower cost per unit. One need is a lower setup cost per unit: the time and money required to switch a machine or a process to the next job. The action attached to that need is to run large batches. The other need is a lower carrying cost per unit: the cost of holding inventory, including space, cash tied up, and the risk that goods go stale. The action attached to that need is to run small batches. He then asks for the because. One assumption is that setup cost cannot be reduced, and another is that the word "batch" has only one meaning. Shortening the setup attacks the first assumption. Splitting two kinds of batch attacks the second. The production batch is how much you make between setups, and the transfer batch is how much you move to the next step. Those two amounts do not have to match, and a medium batch would only have divided the two actions.

## Key Points

The diagram works when you treat every arrow as a claim that can be wrong, and you refuse to stop at a split that wounds both needs.

<Steps>
  <Step title="Start from the two actions">
    Write the two demands as plain actions, side by side. "Take the full-time internship" and "stay in the required course this term." Do not polish them into slogans, and do not award either one the label "reasonable" yet. If you cannot say what each side is actually proposing to do, you are not ready to draw the rest.
  </Step>

  <Step title="Recover the need and the shared objective">
    Ask what each action is protecting. The internship may protect income and a reference. The course may protect credits that keep graduation on time. Then name an objective that needs both: leave school able to work, and still finish. This is the move principled negotiation is known for, and it is the move a [win-win](/strategies/win-win) outcome requires. If neither side will sign any shared objective, stop. You may have two separate fights.
  </Step>

  <Step title="Read each arrow with because">
    Say the line aloud: in order to graduate on time, I must stay in this course this term, because it is offered only now. Jelena Fedurko, in *Behind the Cloud* (2011), recommends reading the lines aloud, so you check the logic by ear as well as by eye. Each because is a candidate. [Inversion thinking](/thinking/inversion-thinking) helps here: ask what would make this because false, and what evidence would show that. "Setup cost cannot fall," "the course cannot be replaced," and "practice must run until 8:30" are claims about the world, not fixed furniture.
  </Step>

  <Step title="Retire one must, then check both needs">
    An injection, in this method's vocabulary, is a new condition that makes one assumption no longer binding. A night section, a substitute course, or a three-day internship can be an injection. So can a shorter setup, or a transfer batch that is smaller than the production batch. After you choose one, ask whether both needs are still whole. A half-and-half split often leaves income too thin and credits too thin. Keep the injection only if you can point to both needs and still recognize them.
  </Step>
</Steps>

## Applications

Use a Conflict Resolution Diagram when the same two proposals keep returning, both sides can name a real need, and cutting the difference in half would leave that need unmet.

<CardGroup cols={2}>
  <Card title="Reconcile one term without dropping a goal" icon="graduation-cap">
    Put "full-time internship" opposite "required course." Needs: a paid reference, and credits that hold the graduation date. Test three becauses: the course runs only this term, the internship must be full-time, and no substitute counts. A night section or a three-day week is worth trying only if pay and credits both remain real.
  </Card>

  <Card title="Move safety out of every task estimate" icon="clock">
    Staff pad each task so a promise survives surprises. A project manager cuts the pads so the plan looks fundable. Needs: reliable delivery, and a schedule leadership will back. Test the idea that safety has to live inside every task. Pooling safety in one project buffer, as Goldratt proposed in *Critical Chain* (1997), is one injection to try. Watch whether honest estimates and delivery promises both survive the change.
  </Card>

  <Card title="Name the need under a weeknight fight" icon="house-chimney">
    "In bed at nine" sits opposite "stay at practice until 8:30." Needs: enough sleep for school, and a place on the team. Objective: a week the child can sustain. Assumptions to test: every practice is mandatory, bedtime is identical seven nights, and the only ride leaves work at six. Try one reversible change for two weeks, such as a carpool or a later night only on match days. Keep it only if sleep and the team both hold.
  </Card>

  <Card title="Separate a processing batch from a moving batch" icon="hospital">
    A clinic may run one afternoon batch of samples because changeover is costly, while wards want results before morning rounds. Needs: a lab that setup does not consume, and decisions made on today's tests. Test the claim that samples must travel in the same lump in which they are processed. Moving smaller groups, while keeping a sensible process batch, is the injection. Judge it by the time from sample to result.
  </Card>
</CardGroup>

## Case Study

In a 2014 case, an IT manager at a utility company used a Conflict Resolution Diagram on a mobile-app project. The manager located \$25,000 in contingency funds and concluded that the project could be phased, with any delay not exceeding 45 days.

Mahesh Gupta and Sharon Kerrick, of the University of Louisville, reported the episode in the *Journal of International Technology and Information Management*, without naming the company. The manager built the diagram with a guided web application, wrote the clash as a story, and listed the assumptions under the arrows. The injections that followed challenged two assumptions on the link between one need and the action that was supposed to serve it.

The funds and the phase plan are the injection: a new condition, with both needs meant to stay recognizable. The authors record a limit: people steeped in the Theory of Constraints might have preferred Critical Chain as a stronger injection for this project and for the projects around it. The decision-makers did not take that path, because the timeline was short and they knew little of the wider method. The published record stops at the decision and does not show whether the app later shipped inside those 45 days. What the case shows is that the diagram can turn a stuck argument into a fundable, bounded plan. A measured gain in delivery is a further question.

## Boundaries and Failure Modes

A Conflict Resolution Diagram fails when the clash is a real constraint, when the sides do not share an objective, or when the page is used to decorate a choice already made.

1. **Some exclusions are physical, legal, or safety-critical.** One person cannot be in two cities in the same hour. A sterile process does not become optional because someone calls the rule an assumption. You can still draw the diagram to see which need the rule protects. You cannot delete the rule by renaming it. If a because survives a real test, the constraint stays. [Second-order thinking](/thinking/second-order-thinking) then asks what a clever workaround would break next.
2. **The objective has to be one that both sides will actually own.** If one party will accept no A that includes the other's need, you are looking at two objectives. A slogan such as "excellence" or "alignment" hides that fact. [Abstraction laddering](/methods/abstraction-laddering) is the check: if nobody in the room can act on A, the objective is floating above the mandate.

A common misuse is the **prosecution diagram**. You write your action as the only professional choice, and you write their need as fear, politics, or stubbornness. They would not repeat that sentence. The drawing then hardens the fight it was meant to open. Write their need in words they would sign. Goldratt urged people not to stop at compromise, because a split often leaves both needs only partly met, and that stance is not a proof that every assumption is false. When the becauses survive contact with evidence, and no feasible injection appears, a bounded compromise or a sequenced choice is the honest outcome.

## Common Misconceptions

Three mistakes explain most failed diagrams: calling a split a win, treating every assumption as guilty, and caricaturing the other side's need.

<AccordionGroup>
  <Accordion title="Misconception: &#x22;A fair split is already a win-win.&#x22;">
    A fair split divides the two actions. Each side gives up part of what it was proposing to do. The diagram asks a prior question: which need was the action serving, and is there a condition under which that need survives whole? Half an internship plus a missed exam can look balanced and still fail both needs. Use the split when the assumptions hold and time has run out. Do not start there by reflex.
  </Accordion>

  <Accordion title="Misconception: &#x22;If you cannot find a false assumption, the method failed.&#x22;">
    Some assumptions are true today. Setup really does take four hours. The course really is offered once a year. The method still has a move. An injection can change the world so that a true assumption stops binding: shorten the setup, add a section, fund a phase. Finding that nothing is false and nothing can be changed is also a result. It tells you the clash is real. A hard constraint, or a causal investigation, is the next tool. A smarter slogan will not move it.
  </Accordion>

  <Accordion title="Misconception: &#x22;Their need is just a dressed-up demand.&#x22;">
    The demand is D or D-prime. The need is the condition that demand is trying to protect. If you collapse the two, you are back to arguing proposals. A false dilemma is the habit of treating two actions as the only actions. This diagram tests that habit. It does not guarantee the dilemma was false. Write the other need so the other person recognizes it. Then test the because. A need you have rewritten as a flaw cannot be satisfied, so the clash stays in place.
  </Accordion>
</AccordionGroup>

## Related Concepts

These pages sit next to the diagram: the system method it belongs to, the outcome it aims at, and the tools that answer a different question.

<CardGroup cols={3}>
  <Card title="Theory of Constraints" icon="link" href="/methods/theory-of-constraints">
    Improve the system by managing the current constraint. The diagram is one of its thinking tools, aimed at policy conflicts rather than at a machine's speed.
  </Card>

  <Card title="Win-Win" icon="people-carry" href="/strategies/win-win">
    Look for an outcome both parties would choose again. The diagram is a way to hunt for that outcome by challenging a necessity, not by averaging two demands.
  </Card>

  <Card title="Force Field Analysis" icon="arrows-alt-h" href="/methods/force-field-analysis">
    List forces for and against a change. Use it to weigh a proposal. Use the diagram when two actions each claim to be necessary for a shared objective.
  </Card>

  <Card title="Second-Order Thinking" icon="layer-group" href="/thinking/second-order-thinking">
    Ask what the injection causes next. A local peace can create a new conflict one step downstream, or protect work that is not the real constraint.
  </Card>

  <Card title="False Dilemma" icon="scale-balanced" href="/fallacies/false-dilemma">
    The fallacy presents two options as the only options. The diagram is a test of that presentation. Sometimes the test confirms that both actions really do exclude each other.
  </Card>

  <Card title="Five Whys" icon="question-circle" href="/methods/five-whys">
    Walk a causal chain toward something you can fix. The diagram walks necessity arrows toward an assumption you can retire. One asks why it broke. The other asks why this action was mandatory.
  </Card>
</CardGroup>

## One-Line Takeaway

<Tip>
  **Write both demands, the need under each, and the shared goal. Then retire one "because," and check that both needs are still whole.**
</Tip>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.