benefits check
Also called: benefits review, benefits realization review, post-launch review
A review a few weeks or months after the launch that compares the real outcome with the success criteria in the brief, such as bookings, not just whether things shipped on time. It decides what to fix, keep or stop, and feeds the next project's estimates.
A benefits check is a review held weeks or months after a launch that compares what actually happened with the success criteria written in the brief. It exists because launch day can only prove half of success. On launch day you can check delivery: was it ready on the date, within the budget, with the agreed scope? Whether the project reached its result (customers who bought, users who stayed, costs that fell) only shows up later.
Schedule each check for when its number can exist, and label early numbers as early. A retention measure "in week four" cannot be complete until the last buyers of the period have reached week four; check it once early for the first cohort and again when everyone has had the chance. Look along the whole chain from the brief's assumptions (traffic, conversion at each step, capacity) to find where the gap actually comes from, rather than declaring the whole project a success or a failure.
The check decides what to fix, keep or stop, looking only at what each next step would cost and change from here. Money already spent cannot be recovered by any decision, so it argues neither for continuing nor for stopping.
Finally, the check turns the project's assumptions into reference data. Next time, the plan starts from measured rates rather than guesses, which is one of the cheapest ways to make future estimates honest.
Example
Klasna's physics launch had two-part success criteria. Delivery: open on 1 February 2027 within 600,000 UAH with at least 8 vetted tutors. Result: 120 packages bought by 28 February, and three in four learners still attending in week four.
Delivery was met: opened on 1 February, 586,300 UAH spent (600,000 − 586,300 = 13,700 under), 9 tutors. The result, checked on 1 March: 58 packages, 58 ÷ 120 = 48.33 % of target (gap 62), by week 21, 14, 12, 11.
The plan's chain was 2,500 visits × 40 % start the test × 75 % finish it × 16 % buy = 120. Actual:
Traffic and starts were on plan; the leaks are test completion (phones 35 % against computers 64.71 %) and the purchase step. Fixing completion alone would have given about 1,060 × 0.75 × 58 ÷ 472 = 97.69, so about 98 packages; fixing the purchase step alone about 472 × 0.16 = 75.52, so about 76. Week-four attendance is 15 of 21 = 71.43 %, but it covers only week-one buyers, so it is labeled early and checked again on 28 March.
Common mistakes
- Declaring success on launch day. Launch day proves delivery; the result needs its own date.
- Checking a number before it can exist. Label early cohorts as early and recheck when everyone has had the chance.
- One verdict for the whole project. Walk the chain step by step to find where the gap really is.
- Letting spent money decide. It is gone either way; decide on what each next step costs and changes.
- Not feeding the next plan. Measured rates should replace the guesses in the next project's assumptions.
Learn it in the course
- The benefits check and a blameless retrospective · Check the result weeks after launch against the success criteria, run a retrospective on facts and decisions, turn lessons into owned actions and close with a one-page report.
- Acceptance and handover to operations · Run the acceptance checks against the real thing, write known problems down with owners, hand each part to an everyday owner and keep a runbook for outages and alerts.
- Case: the first month against the success criteria · Physics opened on time, but bookings are half the target: separate delivery from result, find where the funnel leaked and write the closing report with three actions.