Divergent and Convergent Thinking
Every improvement process alternates between two fundamentally different modes of thinking: divergent (generating freely, without evaluation) and convergent (filtering, deciding, committing). Mixing the two modes in the same breath is the most common reason team problem-solving sessions produce frustration rather than insight. The two-diamond approach makes the alternation explicit — and maps it directly onto the 7-step improvement method with timings.
Never evaluate while generating. Never generate while evaluating. The moment someone says “yes but that won’t work” during a generation phase, the divergent thinking stops — and with it, the possibility of finding the answer that was three ideas away.
The two modes require different mental states and different ground rules. Separate them explicitly in every session. Name which mode you are in. The facilitator’s primary job is to protect the divergent phase from premature convergence.
☰ Contents
The two modes — what they are and why they conflict
Divergent thinking expands the possibility space. It generates options, surfaces assumptions, discovers connections, and finds solutions that would not have been visible if evaluation had started earlier. It requires psychological safety — the freedom to say something that might be wrong, incomplete, or apparently irrelevant without being immediately corrected.
Convergent thinking narrows the possibility space. It filters, prioritises, combines, and commits. It requires rigour — the discipline to apply explicit criteria and make decisions rather than keeping all options open indefinitely.
The conflict between them is real and structural. Evaluation suppresses generation — people stop suggesting ideas when they are being assessed. Generation suppresses evaluation — people resist committing to a direction when they sense there are more options to explore. Mixing both in the same conversation produces a mediocre version of each: not enough ideas generated, not enough rigour applied to the ones that were.
The typical NHS improvement workshop mixes divergent and convergent thinking throughout. Someone proposes an idea (diverge), someone immediately evaluates it (converge), the proposer defends it (converge), a third person proposes a modification (diverge), and the session drifts between half-formed ideas and premature conclusions for two hours. No genuine generation phase occurred. No rigorous convergence phase occurred. The output is a list of compromises rather than a tested solution.
The two-diamond model
The double diamond was developed by the Design Council and independently by IDEO as a visual model of the design thinking process. It maps directly onto improvement work and onto the 7-step method.
Each diamond represents one diverge-converge cycle:
Diamond 1 — find the real problem. Diverge to understand the full scope of symptoms and causes. Converge on the binding constraint and the contradiction keeping it in place. This is where most improvement programmes fail — they converge too quickly on a problem definition without genuinely exploring the space.
Diamond 2 — find the right solution. Diverge to generate the widest possible solution space. Converge on the one testable solution that addresses the constraint at the right level with the authority available. This is where creativity matters — but only once the problem is correctly defined.
The 7-step method — mapped to the two diamonds
| Step | Mode | Diamond | What happens |
|---|---|---|---|
| Step 1 List symptoms |
Diverge | Diamond 1 | Generate every symptom freely. No filtering. No prioritising. Include symptoms outside your boundary. Apply the four Cs at the end of the phase — not during. |
| Step 2 Measure |
Converge | Diamond 1 | Select the metrics that will tell you whether the system has structurally changed. Run Bootstrap CUSUM. This is data collection and analysis — convergent by nature. |
| Step 3 Root cause |
Diverge then Converge | Diamond 1 | Diverge: generate candidate root causes using CRT, fishbone, or the six-phase process. Converge: name the contradiction, check the four traps, identify the binding constraint. |
| Step 4 Test constraint |
Converge | Diamond 1 → 2 | Confirm the constraint using throughput analysis. This is the narrowest point of Diamond 1 — a single, clear problem definition before Diamond 2 opens. |
| Step 5 Generate solutions |
Diverge | Diamond 2 | Generate freely using “How might we?” TRIZ IFR, SIT Trimming, analogical thinking. No evaluation during this phase. Quantity over quality — the best ideas often come late in the generation phase. |
| Step 6 Prioritise |
Converge | Diamond 2 | Filter using three questions: does this address the constraint directly? Do we have the authority? Would Bootstrap CUSUM detect a change point if it worked? Apply PICK model for effort vs impact. |
| Step 7 PDSA |
Both | Diamond 2 | Plan (converge — write the pre-committed prediction). Do (converge — implement at small scale). Study (converge — run Bootstrap CUSUM). Act (diverge if change point absent — return to Step 3). |
Timings — three hours from symptoms to testable plan
With a team that has relevant system knowledge and data available, the full two-diamond process takes approximately three hours. This is the time to produce a pre-committed improvement plan — not to implement it. Implementation and the PDSA cycle follow separately.
Step 2: Review measures — 15 min
Step 3: Root cause — 30 min
Four traps check — 10 min
Name the contradiction — 15 min
How might we? — 20 min
Step 6: Prioritise — 15 min
Write testable plan — 15 min
Metric + direction + timing
Confidence threshold
Balancing measures
PDSA plan for Step 7
Ground rules for each mode
- No evaluation — defer all judgment
- Quantity over quality — more is better
- Build on others’ ideas rather than replacing them
- Include wild and apparently impossible ideas
- One voice at a time — no interrupting
- Write everything down — no idea is too obvious
- The facilitator stops evaluation, not generation
- Apply explicit criteria — not gut feel
- Cull, cluster, combine, clarify — in that order
- Seek the strongest version of each idea before discarding
- Decisions must be specific and actionable
- The output is a commitment — not a list of options
- Test the decision: would Bootstrap CUSUM detect success?
- If no decision is possible — return to diverge
The five Cs — how to converge well
Hurson’s five Cs are the practical mechanism for the convergent phase. Applied in sequence, they take a large, messy list of generated ideas and produce a small, clear set of actionable candidates.
The evaluation matrix — choosing the best solution
Once the four Cs have produced a shortlist of candidate solutions, the evaluation matrix makes the choice explicit and defensible. Each solution is scored against agreed success criteria — and the scores are visible to the whole team simultaneously. This separates the evaluation from the politics: the conversation is about the criteria, not about whose idea wins.
Hurson’s insight is that the success criteria must be agreed before the solutions are evaluated against them. If criteria are chosen after solutions are proposed, they will unconsciously be chosen to favour the preferred solution. Agree the criteria first — during Diamond 1, when the problem is being defined — then apply them in Diamond 2.
| Candidate solution | Easy to implement out of 5 |
Staff like it out of 5 |
Patients like it out of 5 |
Addresses constraint out of 5 |
Bootstrap CUSUM testable out of 5 |
Total out of 25 |
|---|---|---|---|---|---|---|
| Shared NHS/council discharge budget | 2 | 3 | 5 | 5 | 5 | 20 |
| Daily discharge coordinator huddle | 5 | 4 | 3 | 2 | 3 | 17 |
| Same-day discharge protocol for fit patients | 4 | 3 | 4 | 3 | 4 | 18 |
| Additional care home beds (capital bid) | 1 | 4 | 5 | 4 | 4 | 18 |
The matrix reveals that the shared budget solution scores highest overall despite being hardest to implement — because it addresses the constraint directly. The daily huddle scores highest on ease and staff acceptability but lowest on constraint impact. The matrix makes this trade-off explicit rather than leaving it as an unspoken assumption in a verbal discussion.
Once the matrix has identified the leading candidate, apply POWER to stress-test it before committing:
- Positives — what is genuinely good about this solution?
- Objections — what are the legitimate concerns? State them as specific risks, not vague doubts
- What else — what information is still missing that would change the evaluation?
- Enhancements — what could make this solution stronger without changing its core?
- Remedies — how could each objection be addressed or mitigated?
The output of POWER is a refined, objection-tested version of the chosen solution — ready to be written as the pre-committed testable plan.
The PICK model (Possible, Implement, Consider, Kill) is a two-criterion evaluation matrix pre-built: Impact on one axis, Effort on the other. It maps directly onto two of Hurson’s success criteria — Impact covers “addresses the constraint” and “patients/customers like it”; Effort covers “easy to implement” and “staff like it.”
Use PICK as a rapid first-pass filter before the full evaluation matrix. A two-minute PICK sort removes the obvious low-impact, high-effort candidates from the room quickly and without debate. The evaluation matrix then applies the full success criteria — including constraint alignment and Bootstrap CUSUM testability — to the remaining Implement and Consider candidates only.
The three-stage convergent funnel: PICK (2 min, visual sort) → Evaluation matrix (10 min, full criteria) → POWER (5 min, stress-test the winner).
If the team agrees the criteria after looking at the solutions, the criteria will unconsciously be chosen to justify the preferred solution. Agree the success criteria during Diamond 1 — when the problem is being defined and no solutions are yet on the table. The criteria in the example above (easy to implement, staff like it, patients like it, addresses the constraint, Bootstrap CUSUM testable) should be finalised before Diamond 2 opens.
Common traps
| Trap | What it looks like | The fix |
|---|---|---|
| Premature convergence | The HiPPO (Highest Paid Person’s Opinion) states a solution in the first ten minutes and the room converges around it. The divergent phase never occurs. The solution is the first idea, not the best one. | The facilitator explicitly names the mode at the start: “We are in diverge mode for the next 20 minutes. No evaluation.” The HiPPO’s idea goes on the board with everyone else’s. |
| Endless divergence | The team generates ideas indefinitely and resists committing to any. Every option feels incomplete. The session ends with a long list and no decision. | Name a hard stop for the divergent phase. Apply the four Cs on a timer. The convergent phase requires a decision — not a perfect decision, a testable one. |
| Skipping Diamond 1 | The team jumps straight to generating solutions without rigorously defining the problem. The constraint has not been correctly identified. Diamond 2 produces a well-designed solution to the wrong problem. | Enforce Diamond 1 completion before Diamond 2 opens. The output of Diamond 1 is a specific, agreed contradiction statement — not a vague problem description. |
| No testable output | The session produces a plan that cannot be confirmed or refuted. “Improve communication between teams” is not testable. Bootstrap CUSUM cannot be run on it. | End every session by asking: “What specific metric would change, in what direction, within what timeframe, if this plan worked?” If the group cannot answer, the plan is not yet specific enough. |
Run the Study step of your PDSA
Once the plan is implemented, upload your outcome metric data to the StepChange Analyzer. Bootstrap CUSUM will tell you whether a structural change point appeared — the honest answer to whether the plan worked.
▶ Open the StepChange Analyzer