The benefits check and a blameless retrospective

The success criteria of a project have two halves, and they become checkable at different times. Delivery (date, budget, scope) is settled on launch day. The result, whether the launch did what it was for, needs time to happen.

At Klasna, physics opened on 1 February, within budget, with nine tutors. On 15 February that half can be checked and stated honestly. The result half can't: 120 learners buying a package by 28 February, and three in four still attending in week four. A booking count in mid-February is a progress signal, not the check.

That is why the benefits check comes weeks after launch and compares the result with the criteria written in the brief, not with how the launch felt. Launch day shows the team delivered; it can't show whether families came and stayed.

So Leo can announce delivery today. Announcing success has to wait for the numbers, or the word means only that the project ended.

A benefits check measures each criterion when the number can exist, and labels any number that is still early. Checking too soon doesn't give a worse number; it gives a different one, about a smaller group.

At Klasna the bookings target runs to 28 February, so bookings are checked on 1 March. Week-four attendance is harder. A learner who buys on 20 February reaches week four only in mid-March. On 1 March the attendance figure covers only the first week's buyers, a small group, so it is early and must say so. The full check, for everyone who bought in February, comes on 28 March.

So the plan checks attendance twice: an early read for the first buyers, labelled as early, and the real check at the end of March. Reporting the early figure as if it covered everyone would make a small sample look like the answer, in either direction: one more or one fewer learner could swing it by several points.

A benefits check exists to decide what happens next: what to fix, what to keep and what to stop. It looks only at the road ahead.

That makes money already spent irrelevant to the decision. At Klasna most of the 600,000 UAH ceiling is spent by February. If bookings come in under target, it is tempting to argue that the spend obliges the company to keep going until it pays off. But the spent money is gone whatever Klasna chooses; it argues neither for nor against anything. This is the same sunk-effort rule as in re-planning, now applied at the end of the project.

The right questions are forward-looking. Where exactly did the result fall short of the criteria? What would each next step cost from here, and what would it change? A weak step in the funnel might be cheap to fix; a whole direction might be worth stopping. Either answer comes from comparing the result with the criteria and the options with each other, never from what has already been paid.

A benefits check has a second customer: the next project. Every plan starts from assumptions, and most of them are guesses. The check replaces those guesses with what really happened, step by step, so the next plan can start from a real number.

At Klasna the target of 120 learners was a guess, as Vira admits. After February the team knows much more than whether 120 was reached: how many families started the diagnostic test, how many finished it, how many of those bought, how many learners each tutor actually took. The next subject launch can build its target from those rates instead of from a round number that sounded ambitious.

This is how an organization gets better at estimating without anyone becoming a better guesser: each project leaves reference data behind. The check is not a verdict on whose estimate was wrong, and it is not a reason to set the next target higher to motivate people. Its job is to make the next forecast realistic.

A project retrospective looks back at how the project ran to find what the next one should do differently. A blameless retrospective looks at facts and decisions, not people: what we knew, what we chose, and what the plan made likely.

At Klasna the test problem was found three days before opening, and Danylo is ready to take the blame: "it was my test". A blameless look starts elsewhere. Fact: the phone check with a dropped connection ran on 28 January. Decision: in November the plan put acceptance in the last week. So the useful question is why the plan placed that check so late. Vira's answer: in November nobody wrote outages down as a test condition, not Danylo, not her, not the plan.

That lesson is about the plan, so it can be fixed. Blame teaches people to hide problems next time and leaves the plan exactly as it was. Questions like "who forgot?" or "why did Danylo miss something so obvious?" call a problem obvious only in hindsight.

A retrospective works best as a fixed sequence, so the discussion moves from what happened to what changes:

1. Gather the facts: the timeline and the data.
2. Look at the decisions and what was known when they were made.
3. Find what in the plan or process made the outcome likely.
4. Agree at most three actions, each with an owner and a date.
5. Put the actions into templates and checklists the next project will use.

Facts come before judgement, otherwise the loudest memory wins. Decisions are judged by what was known at the time, not by what everyone knows now: in November nobody knew the test would fail on a dropped connection. Causes are looked for in the plan and the process, because that is what the next project inherits. And the last step matters most: a lesson that lives only in the meeting notes is forgotten by the next launch, while a line in the launch checklist is used by people who never heard of this retrospective.

Most retrospectives fail at the last step: the lessons are right, but nothing changes. A lesson becomes an action only when it says what changes and where, who owns it and by when.

At Klasna, "test earlier" is the right lesson and a useless action: no owner, no date, no place where the change lives, so nobody will do it. The working version: "The launch checklist adds a phone check with a dropped connection at the first demo. Owner: Danylo. By 15 March." It changes a document the next launch will use, so it works even if nobody remembers this project. As Danylo says, it's a change to the checklist, not a promise to try harder.

Two more traps. A promise about a person ("Danylo will be more careful") is not a change to anything and breaks the blameless rule. A list of twelve improvements "to keep in mind" means none: with no owners and too many items, all of them fade. Keep three actions at most, each owned and dated.

A project closes with a closing report that fits on one page and ends with the sponsor's signature. It holds:

• delivery against the criteria: date, budget, scope;
• the result against the criteria, with the dates each number was checked and early numbers labelled;
• what was handed over to whom;
• money spent, in numbers, against the ceiling: not "roughly within budget";
• up to three actions with owners and dates;
• a recommendation: what to fix, keep or stop.

At Klasna the page goes to Leo, and the project closes when he signs it. Two things stay out: a list of who caused each delay, which breaks the blameless rule, and the project chat, which hides the answer the page exists to give.

The report is short on purpose. Its readers are the sponsor today and the next project's lead in a year, and both need the same few facts.

How it fits together: check delivery now and the result when it exists, decide forward, learn blamelessly, and leave owned actions in a one-page report. The last case applies all of it to February's real numbers.