Case: the first month against the success criteria

A closing report states the two halves of success separately, because they can have opposite answers. Delivery asks whether the team did what it promised; the result asks whether that achieved what the project was for.

At Klasna on 1 March, delivery is met: physics opened on 1 February, with nine tutors who passed a demo lesson, and 586,300 UAH spent against the 600,000 ceiling, 13,700 under. The result is not: 21 + 14 + 12 + 11 = 58 packages by 28 February against a target of 120. That is 58 ÷ 120 = 48.33% of the target, a gap of 62 packages.

Mixing the halves goes wrong either way. "We opened on time, so it worked" hides the result. "Bookings are half the target, so the project failed" wipes out a delivery the team really achieved and points at the wrong people. Stated apart, the report tells Leo exactly which half needs attention: not how the project was run, but the path from visit to purchase, which the rest of this case follows.

When a result falls short, follow the funnel step by step and compare each step's real rate with the assumption the plan used. The plan's target was built from those assumptions, so the gap must sit in one or more of them.

At Klasna the December plan assumed 2,500 visits, 40% of visitors starting the diagnostic test, 75% of starters finishing it and 16% of finishers buying: 120 packages. February's real numbers: 2,620 visits (on plan), 1,060 tests started (40.46%, on plan), 472 completed. Completion is 472 ÷ 1,060 = 44.53% against 75%: the first big leak.

Then look at the leaking step week by week. If the rate jumps around, it may be a launch-week glitch. At Klasna completion stays between about 44% and 46% every week, so the problem is built into the test, not bad luck. This walk also clears the usual suspect: someone will blame the ads, but the traffic was above plan. The question is not who failed but which assumption reality corrected.

A funnel can leak in more than one place, so keep walking after the first gap. The next step is the purchase: of the families who finished the test, how many bought?

At Klasna the plan assumed 16% of finishers would buy. February: 472 finished and 21 + 14 + 12 + 11 = 58 bought, so the purchase rate is 58 ÷ 472 = 12.29%. That is a second leak, smaller than completion but real.

Each leak deserves its own line in the report, because each points to a different fix. A completion problem lives in the test itself: its length, how it behaves on a phone, what happens when the connection drops. A purchase problem lives after it: how the result is explained, the package prices, the booking step. Merging them into "conversion is low" loses that difference.

Note also the denominator. The purchase rate is measured against finishers (472), not against starters or visitors; a rate against the wrong base would blame the purchase step for families who never reached it.

Funnel data tells you where people drop out. It rarely tells you why. A good conclusion states only what the numbers support and marks the rest as hypotheses to check.

At Klasna the February data supports three conclusions. Test starts were in line with the plan (40.46% against 40%). Test completion is the biggest leak, and it is worst on phones: phones are about two-thirds of starts (720 of 1,060), and only 252 ÷ 720 = 35% finish there, against 220 ÷ 340 = 64.71% on computers. And the purchase step after the test is also below plan (12.29% against 16%).

What it doesn't support: that traffic was the main problem (visits were above plan), or that the dropped-connection bug accepted at handover is the cause. That bug is one hypothesis; a 20-minute test on a small screen is another. The cheapest way to tell them apart is to watch five parents take the test on their own phones before building any fix. Fixing the wrong cause costs a month and leaves the leak in place.

To decide which leak to fix first, size each one: recompute the result as if that single step had matched the plan, with every other step left as it really was.

At Klasna, if completion had been the planned 75%: 1,060 starts × 0.75 = 795 finishers, times the real purchase rate of 58 ÷ 472, gives 795 × 58 ÷ 472 = 97.69, about 98 packages. If instead only the purchase step had matched its 16%: 472 × 0.16 = 75.52, about 76. Against the actual 58, fixing completion is worth about 40 packages a month, fixing purchase about 18.

The what-if keeps one step at a time on purpose. Fixing both at once would compound, and that number would tempt the report into promising it; the honest version shows each lever's size separately and lets the plan choose.

The sizes also explain why more advertising is a weak answer: traffic was already on plan, and every extra visit flows into the same leaking test. The biggest lever is the step with the biggest gap.

A number is only as good as the group it covers. Before reporting a rate, check its denominator: who could have been counted by now?

At Klasna, week-four attendance looks like 71%, just under the target of three in four. But a learner starts lessons in the week of purchase, so by 28 February only the first week's buyers, 21 learners, have finished week four; 15 of them still attend: 15 ÷ 21 = 71.43%. The other 37 buyers haven't reached week four and can't count as stopped. Dividing 15 by all 58 (25.86%) is wrong for that reason.

With 21 learners, one person moves the figure by about five points: 16 ÷ 21 = 76.19%, which would pass. So the number is neither a pass nor a fail yet. The report states it as early: "71% (15 of 21 first-week buyers), re-checked on 28 March for all 58". Calling the target missed treats noise as a verdict; leaving the number out until it looks good hides it.

A closing report also lists the risks handed over to operations, each with an owner. They are no longer project tasks, but the people now running the work need to see them.

At Klasna the tutor data shows one. The nine tutors offered 240 lesson slots a week, 960 over February's four weeks, and delivered 272 lessons: 272 ÷ 960 = 28.33% of slots used. The plan gave each tutor about 15 learners; they got 58 ÷ 9 = 6.44 on average. Tutors are paid 430 UAH per delivered lesson from the operating budget, so February payouts total 272 × 430 = 116,960 UAH, about 12,996 per tutor for the month.

Tutors who earn little may leave before the spring exam peak, exactly when Klasna needs them. That is an operations risk now, owned by Roman, who runs schedules and payouts. The report records it with its owner; it does not turn it into a project task, because the project is closing and the fix belongs to the people who will be there in April.

The closing report ends with a recommendation, and the most common pressure at that point is to spend more so that what's already spent pays off. What's spent doesn't vote. The next step is chosen by what each option costs from here and what it would change.

At Klasna Hanna expects Leo to ask whether more advertising would make the 586,300 UAH pay off. The funnel answers no: traffic was on plan, and the biggest leak is test completion on phones. Every extra visit flows into the same test, so more ads buy few packages, while fixing completion is worth about 40 packages a month. Stopping physics would be just as wrong: the data shows fixable leaks and an early attendance figure, not a dead product.

So the recommendation is to find out why phones drop out, by watching five parents take the test, then fix completion, and only then think about traffic.

How it fits together: separate delivery from result, walk the funnel, size the leaks, label early numbers, hand risks to owners and decide forward. That closes the course's project, from a one-page brief in October to a one-page report in March.