Chapters
- 01 · Establish a Review Rhythm
- 02 · Inspect Errors, Exceptions, and Overrides
- 03 · Compare Expected and Actual Outcomes
- 04 · Measure Adoption, Cost, Speed, and Quality
- 05 · Find Drift and Stale Definitions
- 06 · Test Changes Before Broad Release
- 07 · Roll Out and Roll Back Deliberately
- 08 · Update Owners, Documentation, and Training
- 09 · Capstone: Run the Quarterly Operating Review
16 min · Interactive exercise
Capstone: Run the Quarterly Operating Review
Work a real review pack, validate the plan, approve version 1.0, and close the curriculum.
Eight sections, and this chapter is the only capstone in the curriculum where you use the thing you built rather than build another one.
Six findings are in front of you, one from each inspection type. For each, decide change, monitor, or accept. Then the panel shows which ones the plan you wrote would actually have caught.
One of them it does not catch, deliberately. A downstream consumer stopped using an output and nothing noticed, because the plan measures adoption of the system rather than adoption of its outputs. That is not a flaw to be embarrassed about: a review plan that catches everything has not been tested against anything. The right response is to accept it this quarter and add the missing signal to the next version, which is the loop working exactly as intended.
Then thirteen validation checks run by stable ID. Does every finding type route to somebody who is actually in the review? Does every change have a rollback trigger, or a gate and a stated reason why it cannot have one? Does the confirmer of a propagation differ from its author?
What the plan buys
Not that the system will improve, which no plan guarantees and which skips the part where somebody has to decide something. Not that problems will be caught earlier, which is true and describes monitoring.
What it buys is that the review produces changes rather than observations, and that each change can be shown to have helped or not. Every finding type routes to a named decision, and every change carries acceptance criteria written before it. That pair is the whole difference between measuring a system and improving one.
GTM Lab
Saved locallyOperating Review and Improvement Plan
sample-operating-review-plan · v1 · draft
Work the review pack
Six findings, one quarter. For each, decide change, monitor, or accept. Then see which ones the plan you wrote would actually have caught, and which arrived by luck.
- Overrides are up, and almost all of the rise is in one segment.The override inspection, which asks how often, in which direction, and whether it is concentrated.
Change: the rules are wrong for that segment specifically, which is far more actionable than a rate that drifted up overall. - One control has refused nothing all quarter.The exception inspection, which treats a rate of zero as a prompt to test the control rather than as good news.
Change: send it something it must refuse and confirm the refusal appears. - Spend is up, and the metered portion has not moved.The cost inspection, because the plan publishes which portion is not metered.
Change, but a measurement change first. Optimizing the metered part would achieve nothing. - The specification claims something the live behavior no longer does.The quarterly re-read of the specification against live behavior.
Change: mark it wrong rather than unverified, and correct the document this quarter. - Usage is high and overrides are rising alongside it.The adoption inspection, which is read alongside override rate rather than alone.
Change, routed to the sales leader as a trust problem rather than to operations as a training one. - A downstream team quietly stopped using an output six weeks ago and nothing noticed.Nothing in this plan. It arrived because somebody mentioned it in passing.
Accept for now, and add an abandonment signal for that consumer to the next version of the plan.
Run all 13 validation checks
The checks test the seams between sections, since every section was written while looking only at that section. Each runs by its stable ID and reports pass or fail with a reason.