Risk responses, the pre-mortem and built-in quality

Each row of the register needs a risk response: what the project decides to do about the risk before it happens. There are five moves.

• Avoid: change the plan so the risk can't happen. If Vira draws the simple diagrams herself for topics 1 to 8, the plan no longer depends on the illustrator there.
• Transfer: hand the impact to someone better placed, by contract or insurance. The contractor's agreement holds back 30 % of the fee until checkout passes Danylo's test.
• Reduce: lower the probability or the impact. Two tutors read each curriculum topic in parallel with Vira, so the review can't pile up at the end.
• Accept: live with it, often with a reserve. Keep 24,000 UAH aside for higher January ad prices and watch the cost per booking weekly.
• Escalate: when the response is beyond the project's authority, hand it to the sponsor with a recommendation, such as a second payment route.

Two of the five responses are easy to overrate.

Transfer hands part of the impact to someone better placed, usually by contract or insurance. Klasna's agreement with the contractor holds back 30 % of the fee until checkout passes Danylo's test. That protects Klasna's money and gives the contractor a reason to deliver. But it moves money, not dates: if checkout is late, families still can't buy physics packages on 1 February. The schedule side of the risk needs its own response, such as a trigger ("no working checkout on the test site by 4 January") and a fallback.

Accept isn't the same as ignoring. Accepting means deciding consciously to live with a risk, usually with a reserve of time or money and something to watch: 24,000 UAH set aside for higher January ad prices and the cost per booking checked weekly.

For each response, ask what it actually protects: the date, the money or the result.

Uncertainty cuts both ways. An opportunity is an uncertain event that would help the project, and it goes in the same register, with the moves turned around: make sure it happens, make it more likely, share it with a partner who can use it better, or simply accept it if it comes.

At Klasna, Danylo notices that two of the math tutors have physics degrees and might want to teach physics too. If Vira invites both to a demo lesson this week, that makes the opportunity more likely: Klasna could have ten vetted tutors instead of eight, and some spare evening slots. As a side effect, it also reduces the evening-slots risk.

Waiting to see whether they apply would be accepting it. Nothing here needs the sponsor's authority, so there's no reason to escalate. Opportunities rarely get noticed unless someone asks for them, so ask in every review: what could go better than planned?

Take one serious risk, "tutors are not ready by 1 February", and the moves become concrete. Reduce it: invite two more candidates to demo lessons now, as backups. Limit the impact: open with fewer tutors and cap new bookings to their real slots, so no family books a lesson nobody can teach. Escalate the part beyond the project: ask Leo to decide whether opening with 7 vetted tutors is acceptable, since "at least 8" is a success criterion he signed.

Some moves look like responses and aren't. Letting two unsigned candidates start teaching and signing contracts in February breaks labor rules. Silently skipping Vira's demo-lesson check for the last two tutors breaks the quality promise to families and hides a change to the brief.

A response that breaks the law, labor, safety or data-protection rules isn't a response. It's a new and bigger risk, for the families and for Klasna.

Under deadline pressure, shortcuts appear that look like risk responses. Leo offers one for the provider's review: a contact there, a "thank you", and the file moves to the top. That's a bribe, and no project goal justifies it.

The same goes for other tempting moves around this launch: letting candidates teach before they sign contracts, or skipping the personal-data consent for recorded demo lessons. A response that breaks the law, labor, safety or data-protection rules isn't a response at all. It's a new and bigger risk, for the families and for Klasna, and it doesn't belong in the register as an "option".

There is almost always a legal route that reduces the same risk. Here, Hanna's: submit the provider's documents early and ask for their published review time in writing, so the schedule can account for it. If the legal route isn't enough, that's a decision for the sponsor about the date or the scope, never a reason to cut the corner.

Some risks slip past every list; outages almost did. A project pre-mortem finds them by flipping the question. Thirty minutes on a call: "It's 2 March. The physics launch failed. Write down why."

The steps matter:

1. Set the scene: the launch has failed, as a fact.
2. Everyone writes their reasons alone for five minutes, so the loudest voice doesn't set the list.
3. Read the reasons out and merge duplicates.
4. Turn each new reason into a register row with an owner and a trigger.

Why it works: it's easier to say "it failed because" than "it might fail if", and nobody looks like a pessimist for naming a cause. Vira's note, "tutors found mistakes in the practice sets in February", is exactly the kind of reason a normal risk session misses.

The test of a pre-mortem is the register afterwards. One that ends without new rows only changed the mood.

Vira planned to check all 12 practice-set topics herself in mid-January. One big inspection at the end finds problems when they're most expensive to fix: days before opening, with no time to rewrite.

Built-in quality means checking while the work is done, in small pieces. Three habits:

• Acceptance criteria agreed before the work starts, so authors know what "good" means.
• Checks on a sample as each piece lands: a second tutor solves the first ten tasks of every topic as soon as it's drafted.
• A small trial before going live: five learners take the diagnostic test before it opens, not five hundred after.

The contrast is timing, not effort. A single January check and complaints through the support chat after opening find the same mistakes, only later, when fixing them costs days before the exam season and the trust of the first families.

A definition of done is the short list every piece of work must meet before anyone calls it finished. It turns built-in quality from a good intention into a check.

Three rules make it work. It's short: four to six lines. It's the same for every topic, so nobody argues in January about whether topic 7 is finished. And every line is checkable by someone who isn't the author. For a physics practice set: a second tutor has solved the first ten tasks and found no errors; every task has a worked solution; the files open and read well on a phone, Danylo's line.

Lines like "Vira feels it's good enough" or "the deadline has arrived" fail the test: a feeling can't be checked by anyone else, and a date passing says nothing about quality.

How it fits together: responses for each risk, opportunities, clear ethical limits, a pre-mortem and quality checked as the work lands complete the risk and quality toolkit. The case next hands you the team's raw forty-line list to turn into the few risks Leo needs to see.