A final project that ends with the last commit is half a project. The important questions come afterward: Does the new way work for the people it was built for? May the old one be switched off? What did it cost, and what would you do differently next time? This lesson takes the project to its end: pilot, measurement, decision, report, submission.
Again it teaches nothing new. The pilot is in lesson M6.3, the measurement in lesson M6.4, the switch-off in lesson M6.5. Here you see how the three come together into one decision and how you record it.
Pilot and measurement
The pilot plan for your function block has the form from lesson M6.3: stages with Who, “Continue when” and “Back when”; who flips the switch;
what the fallback looks like; the exceptions with reason and date. It is in docs/pilot-plan.md or a section of the plan. Two things
belong in the project that the course has so far shown only for the order list:
- The counter for the old way (lesson M6.4) runs from the first day of the pilot. Without it, the grace period is later a guess.
- The measurement decides, not the mood. Before the pilot you fix which number means “continue”: an error budget, a comparison of the results old against new, a duration. After the pilot you read the number, not your feeling.
| The measurement shows … | Decision | What you do |
|---|---|---|
| within the budget, comparison without difference | continue | next stage according to the pilot plan |
| difference between old and new | back | switch off, look for the cause (reconciliation, lesson M6.2), new test |
| error budget used up | back | switch off, fix class A errors first |
| too little data to judge | wait | extend the stage; small numbers are not a statement (lesson M6.4) |
| all stages through, grace period running | prepare switch-off | tick off the switch-off conditions |
The project does not end worse because the pilot reports “back”. It ends worse if the measurement is missing and nobody knows what the pilot showed.