Dependencies and milestones as decision points

A plan can look sensible line by line and still be impossible, because of a hidden dependency: a link between pieces of work that nobody wrote down.

Roman planned to onboard tutors in the first week of December, giving them all of December to prepare. Ask what onboarding needs before it can start, and a chain appears. Onboarding needs tutors who passed a demo lesson. Vira runs demo lessons on the final curriculum, not drafts. The curriculum is final only after her review, on 15 December. So onboarding can't start before late December at the earliest.

Each link was reasonable and known to someone. Nobody had put them together, so the earliest possible start was invisible. The habit that catches it is simple: for every piece of work, ask what must be finished before this can start?, then ask the same of the answer, until you reach something that's already done.

A dependency is a link where one piece of work can't start or finish until another does. Ask where each link comes from, because there are three sources.

• Logical: the work needs another task's output. Demo lessons need the final curriculum.
• Through people: the same person is needed in two places at once. Vira can't review the curriculum and watch demo lessons on the same days.
• Outside the project: someone the project doesn't control. The test build waits for a contractor's free weeks; a scope change waits for Leo's written decision.

Most schedules show only the logical links, because they're visible in the work itself. The other two are where plans quietly break: a schedule can be logically perfect and still assume Vira does three things in the same week, or that an outside partner's calendar matches yours. When you list dependencies, ask all three questions for each task.

The dependency most schedules miss runs through people: two or three tasks that don't need each other's output but need the same person. On paper they can run in parallel; in reality they queue.

Vira is the clearest case on the launch. Her curriculum review, the demo lessons and the diagnostic question bank all land on her in the same December weeks. None needs the others' output, so a schedule built only from logical links would show them side by side and promise dates her calendar can't keep. Vira also holds 73 of the 131 must-days, so her weeks decide a lot.

Two honest responses exist. Sequence the tasks in the schedule, so the dates reflect one person doing one thing at a time. Or move part of the work to someone else: a freelance author could draft the question bank from the draft units, with Vira checking it afterwards. Either way, make the person visible in the plan; “Vira will manage” is not a plan.

A milestone is a point in the schedule with no duration of its own: it marks that something important is done. The work leading to it sits in the tasks before it.

Its real use is as a decision point, not a progress decoration. Leo's instinct (“Kick-off done”, “Design done”) produces markers that look like progress and decide nothing. Instead, phrase each milestone as a question with a date: “By 25 December, do we have 8 tutors who passed a demo lesson?”, and decide now what you'll do if the answer is no.

That last part is what makes a milestone useful. A “no” discovered on 25 December with a plan B prepared in November takes a day to act on. The same “no” with nothing prepared takes a week of meetings, in the busiest part of the project. If you can't name the decision that a milestone triggers, it probably isn't one.

A milestone earns its keep on the day it comes back no. The response has two parts, both decided in advance.

Who decides. Vira's plan B for 25 December (open with 6 good tutors and cap the number of learners instead of rushing two more through) is a good prepared decision. But it changes a success criterion: the brief says at least 8 tutors who passed a demo lesson. Only the sponsor changes criteria, so it goes to Leo in writing. Because it's prepared, with its cost spelled out (fewer learners in February, a lower result target), he can decide within his two working days instead of a week.

How fast. The project lead reports a milestone “no” the same day, in writing: the question, the answer, the prepared decision and what it costs. Waiting for the weekly status burns the very days the preparation was meant to save. And quietly lowering the bar (a shortened demo lesson) is never one of the options.

Good milestones sit where waiting chains meet: points after which several pieces of work can start, or before which a slip would push everything behind it.

For physics the list follows from the dependencies. 1 December: are all five units drafted? (the checkpoint from the brief). If a unit is missing, Vira's review can't finish on 15 December, and everything behind it moves; the prepared question is which unit the review starts without. The curriculum final (15 December). 25 December: 8 tutors passed a demo lesson? The test passed its pilot. Go or no-go before 1 February: are all acceptance criteria met?

A marker like “Landing page design done” fails the test: nothing waits for the design alone, and nobody decides anything there. It's a task on Danylo's board. The same goes for “kick-off meeting held”: an event, not a decision point. Fewer, sharper milestones beat a long list of ticks.

Routine progress can wait for the weekly status. A milestone that comes back “no” can't: it exists precisely to trigger a decision on time, so the project lead reports it the same day, in writing.

The note has four parts, and the first three are ready before the milestone date: the question (“By 25 December, do we have 8 tutors who passed a demo lesson?”), the answer (“6”), the prepared decision (open with 6 and cap learners) and what it costs (fewer learners in February; the result target goes down with it). Leo answers within two working days, as the brief's change rule says.

Why not batch it into the weekly status? Because on a fixed date every day of delay comes out of someone's work later. A “no” on Thursday held for the next Wednesday status has already cost four working days that the plan B was written to save. Bad news early is cheap; bad news late is a crisis.

Every date in a plan should be traceable back through its chain. Behind tutor onboarding the chain runs: curriculum units drafted by the authors → Vira's review makes the curriculum final → demo lessons on the final curriculum → tutor onboarding by Roman → the launch email to families, which announces tutors who are ready.

Each link needs the one before. Written out, the chain shows at once why onboarding can't start in early December, and why a late unit on 1 December moves the launch email in January. Every link you skip is a date somebody will promise without knowing it.

The chain also helps with people. Roman will want to know why his plan moved three weeks; show him the chain. People accept a date they can trace back to its reasons, and argue with one that arrives as an order.

How it fits together: find every dependency (logical, through people, outside), make milestones decision points, report a “no” the same day. Next lesson: which chain decides the end date, and how much room the others have.