What needs to be finished first
A chronological record of the problem exists with timestamps, symptoms, and actions taken so far.
For decision analysis (KT-DA), decision criteria with weights already exist or will be developed in the workshop.
What needs to be ready before start
Template covering four KT processes (Situation Appraisal, Problem Analysis, Decision Analysis, Potential Problem Analysis); tables for in vs not-in comparison and decision criteria; access to logs, metrics, documentation.
A facilitator with KT experience leading all four processes; two to eight participants with domain and data knowledge; one scribe for logging hypotheses and tests.
Problem definition, time period, observed symptoms; known workarounds; available data and sources; escalation level and stakeholders.
2-8 h
Share template up front. Start with Situation Appraisal and decide which KT process is primary (PA, DA, PPA). Set phones aside and pause parallel threads.
The one question this method answers
Which cause, decision, or risk measure can be derived through disciplined separation of facts, hypotheses, and decision criteria?
Marker: Sektion
| Step | Duration | Action | Hint |
|---|---|---|---|
1Section 1: Situation Appraisal | 20-30 min | List problems, decisions, and potential problems. For each entry, assess urgency, impact, and growth rate. Prioritize top themes for subsequent KT processes. | If the list has more than 10 entries, split across two sessions. KT works on focus, not volume. |
2Section 2: Problem Analysis (is / is not) | 45-90 min | For each problem, define the four-field specification: what is affected, what is not, when, where, and how much. Infer likely causes from differences and test each spec. | The "is-not" column is the diagnostic lever. If it stays empty, data understanding is missing and PA becomes speculation. |
3Section 3: Decision Analysis | 30-60 min | Formulate the decision statement. List must criteria and weighted want criteria. Filter options against musts and score against wants. Discuss risks for top options. | More than seven wants dilutes evaluation. Keep top three to five. Use 1-10 weighting, not binary scoring. |
4Section 4: Potential Problem Analysis | 30-60 min | List possible problems for each selected option, then assess likelihood and impact. Define preventive and contingency actions, including trigger and owner for top risks. | Triggers must be measurable. "If there are problems" is not a trigger; "if error rate exceeds 2% for 5 min" is one. |
5Section 5: Followups | 15-20 min | Assign owner, date, and review date for each outcome. Convert open tests from PA into spikes. Archive decision and rationale in a decision log. | Spikes need dates, otherwise diagnostic gaps are lost and KT becomes window dressing. |
What comes out at the end
Structured document with four sections (Situation, PA with is/not table, DA with must/want matrix, PPA with risk list), including decision rationale, followups, and decision log with date and decider.
One entry per incident or decision with date and decider in the header. Later insights are added as an update section rather than overwriting. Update status to `revised` when a decision changes.
Compact working template for Kepner-Tregoe with situation analysis, problem analysis, decision analysis, and risk planning.
Structure situation, problem, decision, and risk analysis in one working view.
Which workflow, issue, or decision should the group examine?
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Situation Appraisal: Three themes were identified. Priority 1: P95 latency increased from 240 ms on 10.05. to 1.8 s.
Problem Analysis:
| Is | Is not | |
|---|---|---|
| What | Order endpoint /v2/orders | Read endpoints, auth endpoint |
| Where | EU-West cluster | US-East cluster |
| When | Since 10.05. 09:00 UTC | Before 10.05. |
| How much | P95 1.8 s, P50 stable at 80 ms | — |
Hypothesis: A change in EU-West cluster on 09.-10.05. is relevant. Deploy log shows DB pool config change. Test confirms: reducing pool from 40 to 20 causes wait times under load.
Decision Analysis: Return pool to 40 (Must: no API downtime; Want: memory under 4 GB, recovery within 5 min). Selected. Score 8.4/10.
PPA: OOM risk at pool 40 plus spike. Trigger: memory over 3.5 GB for 10 min. Contingency: pool 30. Owner: @lisa, monitoring alert by 15.05.
Recognize symptoms and steer against them
Participants fill only the is column, while hypotheses stay broad.
Facilitator explicitly asks both questions for every row. If a participant cannot answer is-not, document it as an explicit knowledge gap and create a spike.
List contains 12 wants, including items that are effectively pass/fail criteria.
Keep musts strictly binary (yes/no). If someone treats a must as a want, the analysis loses integrity. Use at most three to five wants.
Hypotheses are debated but not tested against logs or metrics.
Require a concrete data point for every hypothesis. If unavailable, record as spike, not as fact.
Decision is made but no risks or triggers are defined.
Make Section 4 mandatory. Capture at least three risks per top option with measurable trigger.
DA ends with a score list and no one owns the decision.
KT decision analysis is valid only when a decider is confirmed in advance. Assign backup authority if needed.
Situation Appraisal lists 15 issues and the team starts all, completing none.
Prioritize top 3 and defer the rest to a second session. KT needs depth per problem, not breadth.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.