Case: the contractor slips two weeks

When a dependency slips, re-plan the whole chain from today, not just the late task. A delay rarely ends where it starts: everything that waits for it moves too.

At Klasna the checkout chain has three links. The contractor has 10 working days of tasks left (C3 4, C4 2, C5 2, C6 2; C1 and C2 are done). After his release the payment provider reviews the new product line for 5 working days. Then Danylo runs an end-to-end test with real test purchases for 2 working days. Classes open on Monday 1 February, so the chain must be ready by Friday 29 January: 15 working days from Monday 11 January, today included.

Add the links: 10 + 5 + 2 = 17 working days against 15. Release on 22 January, provider to 29 January, test to Tuesday 2 February: two working days late. The original plan had release on 8 January and 8 days of buffer; that buffer is gone. Use the remaining days from the task list, not the planned days or the reported percentages.

Earned progress is a light check on how much planned work is really done: for each task, its planned days × its done %, summed and compared with the total planned. It says how far the work has come in the plan's own units, which is more useful than a feeling of "mostly there".

For the contractor's six tasks at Klasna: C1 5 days at 100% = 5, C2 3 at 100% = 3, C3 6 at 50% = 3, C4 2 at 0% = 0, C5 4 at 50% = 2, C6 5 at 60% = 3. That is 16 of 25 planned days earned: 64%.

Now the catch. Earned progress looks back; the forecast must look ahead. C3 is "50% done" on a 6-day task, yet its new estimate is 4 days left, not 3: the task has grown. So the re-plan uses the remaining days (10), not 25 − 16 = 9. When the earned figure and the remaining estimate disagree, the remaining estimate from the person doing the work wins, and the difference is itself worth a question.

Duration is not effort divided by people. Adding a person to late work helps far less than the arithmetic suggests, for two reasons. The newcomer needs time to learn the code or the material, and during that time someone has to explain it. And some tasks can't be split: one person has to do them in sequence.

At Klasna Danylo's "easy fix" is the contractor's second developer: ten days of work, two people, five days, release on the 15th. The contractor's own estimate says 20 January. The newcomer spends three days learning the code, and the checkout task can't be divided between two people. Two days saved instead of seven, for 48,000 UAH at 6,000 UAH a day for a minimum of eight days. That leaves 4,000 UAH of the 52,000 under the ceiling, and the chain is ready on 29 January with zero buffer.

Adding people can still be the right call, but only with an honest estimate of the new date and what it costs, never on the naive division.

When the date can't move and the money is nearly gone, scope flexes: ship the must items first and move the rest after opening. The priority column does the work; the question is only which of the remaining tasks the opening really needs.

At Klasna, C3 checkout (4 days) and C4 receipts (2 days) are musts: 6 days. C5 tutor calendar sync is a should, C6 instalments a could. If the contractor ships the musts first, the release lands on Monday 18 January. The provider reviews 19–25 January, Danylo tests 26–27 January, and the chain is ready on Wednesday 27 January. Of the 15 working days, 15 − 6 − 5 − 2 = 2 days of buffer remain, at no extra cost. The contractor finishes C5 and C6 while the provider reviews, and they ship after opening.

Cutting has a price too, so name it: without calendar sync, Roman books tutors' evening slots by hand for about two weeks. Annoying, not fatal, and a price paid in effort rather than in the opening date.

A half-finished feature pulls hard: "we've already paid for most of it". But the days already spent are sunk: the same under every option, so they can't decide. The only question is whether the remaining cost is worth what it buys now.

At Klasna the instalments feature (C6, a could item) is 60% done: three of five days, already paid. Two more days and families could pay in two parts from day one. Ask only what lies ahead: two more days now against a buffer of exactly two days, before a provider review that might still fail (R01 in the register). Putting C6 back into the first release moves it to 20 January and leaves the chain ready on 29 January with zero buffer.

Deferring is not dropping. Instalments ship in February, after opening; families have paid for packages in one go for years, so it's a nice extra, not a reason to open late. The three paid days are not lost either: they're still in the feature when it ships.

Moving a fixed date looks like the safe choice because it makes the schedule comfortable. But it is an option with its own price, and that price is paid by the people the project serves.

At Klasna, opening on 15 February with full scope gives 8 working days of buffer and costs nothing now. In exchange, every family loses two weeks of the exam season, which is the reason the date was fixed in the first place, and the results check against 120 learners on 28 February gets two weeks of sales instead of four. A safe schedule that misses what the project is for is not safe.

It is also not the lead's choice. The opening date is one of the limits only the sponsor can change, in writing, within two working days. So the note presents it honestly as option C, with its buffer and its cost, next to the others; Leo chooses. The lead's job is to make the trade-off visible, not to pick the comfortable option on his behalf.

Options in a re-plan don't all go to the same person. The change rule from the start of the module sorts them: below the agreed threshold, the lead decides and reports it in the status; above it, or when a fixed limit moves, the sponsor decides in writing, within two working days, and the decision is logged.

At Klasna the threshold is up to two days of buffer and 10,000 UAH from the reserve for the lead; the date, the budget ceiling, the out list and the success criteria belong to Leo. So shipping C5 and C6 after opening is the lead's call: it changes no success criterion, costs nothing and keeps the buffer. Paying 48,000 UAH for a second developer is far above the 10,000 UAH threshold and nearly empties the reserve: Leo's. Moving the opening to 15 February changes a fixed limit: Leo's.

Sorting the options before writing the note saves a round trip. The lead acts on what is his, says so in the note, and asks the sponsor only for the decisions that are really his.

A recommendation with thin buffer needs two companions. A trigger is a checkable condition with a date early enough to act on. A fallback names what happens next if it fires, and who decides.

For option A at Klasna, with two days of buffer before a review that might fail, a good pair is: "If the musts aren't on the test site by Monday 18 January, or the provider hasn't approved by 25 January, I come back to you the same day with B or C." Each date leaves days to act. The fallback reuses options already priced, so nobody has to invent them under pressure.

Weak versions fail the same tests. "If things look bad, we'll talk" has no condition and no date. "Check again on 29 January" fires on the deadline itself. "He'll work the weekend" is effort without a cost or a check.

How it fits together: re-plan the whole chain from today, check earned progress but forecast from remaining days, price every option honestly, keep sunk work out, sort who decides, and guard the choice with a trigger. The next module closes the project: acceptance, handover and the benefits check.