Situation Assessment

When to use

Use at the literal start of any strategy or problem-solving engagement, before any data has been pulled and before any direction has been proposed. Also use whenever leadership has a vague sense something is wrong but hasn't diagnosed it, when two people describe "what's happening" in materially different terms with neither view checked against data, or when a previous fix didn't work — which usually means the team solved for a plausible-sounding cause instead of the evidenced one.

What it does

Runs the two phases a real engagement actually goes through in order, instead of jumping straight to data collection. Phase one: build the issue tree and an initial hypothesis at each node, before any analysis exists, so the work that follows is targeted rather than open-ended. Phase two: triangulate real evidence across three independent lenses to prove or kill each hypothesis, tagging every finding fact, inference, or unknown, so nothing downstream gets built on an unverified assumption. The output is a workplan-backed fact base anchored to one decision question, not a data dump.

Method

Phase 1 — Frame and hypothesize (before any data is pulled)

1. Frame with SCQ (Situation-Complication-Question): state the shared situation, name the complication that broke the status quo, and write the single decision question this assessment must answer. One question, not a general review.
2. Build the top-level issue tree: decompose the decision question into 3-5 MECE branches, no overlapping coverage, no gaps. Test MECE-ness explicitly — could one piece of evidence plausibly sit under two branches? If so, redraw the boundary. Decompose one level further until nodes are concretely testable (not "the market is attractive," but "five-year CAGR exceeds our hurdle rate").
3. Write an initial hypothesis at every testable node — your best current guess at the answer, based on whatever partial evidence or experience already exists. This is the hypothesis-driven discipline real strategy work depends on: form a working answer early, then spend the engagement trying to disprove it, rather than researching everything and hoping a conclusion emerges at the end.
4. Name the specific analysis that would prove or kill each hypothesis — the exact data pull, interview, or calculation, not a vague "look into this." A hypothesis with no attached falsification analysis isn't yet actionable.
5. Prioritize nodes by decision impact: which hypotheses, if wrong, would actually change the final recommendation? Analyze those first — don't spread effort evenly across every branch.
6. Build the workplan: owner, data source, and target completion date per prioritized analysis — this is what turns the tree from a diagram into a running project.