Must, should, could: cut scope, not the date

When the work doesn't fit the time, a project has three levers: the date, the resources and the scope (what the launch includes). Which one to pull first depends on what the date is for.

For physics, the date serves the goal. Families book exam preparation before the exam season; open two weeks late and those are two weeks of learners lost to other schools. So the date is the last thing you move. Adding people rarely helps late either, as module 3 shows. The first lever is scope: deliver fewer things, but deliver the essential ones on time.

Leo's “better late than half-done” sounds responsible, but it frames the choice wrongly. The alternative to late isn't half-done; it's a smaller launch that's fully done, with the extras arriving after opening. That only works if you know in advance which items are essential, which is what the must, should, could sort is for.

Owners mark their own items as musts because they care about them: Vira wants video solutions for the forty hardest tasks, Danylo a parent progress dashboard. To sort fairly, use one test, the same for everyone:

Can we open on 1 February and reach the goal without it?

If yes, it isn't a must, however much people like it. Tutors can explain hard tasks in the lesson; parents can ask the tutor until a dashboard exists. Both ideas pass the launch without them, so they become should or could. That doesn't make them bad ideas; it puts the decision with the goal, not with whoever argues loudest.

The test ignores things that feel relevant but aren't: how important the owner thinks it is, whether it's half done, whether a competitor has it. A diagnostic test, by contrast, fails the test: without it learners can't be placed and booked into the right package. That's a must.

After the must test, every remaining line goes into one of two boxes, and a few things don't belong on the list at all.

• Must: the launch can't open or reach its goal without it. The diagnostic test on the platform.
• Should: it hurts to leave out but has a workaround. The waiting list on the early landing page: two days of Danylo's time that checks demand in December, before most money is spent. The launch still works without it.
• Could: nice to have and easy to drop. An adaptive version of the test.
• Not this time: not a fourth box but the brief's out list. Chemistry exam preparation was put out of the project there, so it isn't sorted at all.

The point of the boxes isn't labelling for its own sake: shoulds and coulds are the room to manoeuvre. They fill the spare capacity and are the first to go when something slips.

Before cutting, check which limit actually binds: money, days, or the time of particular people. Cuts help only if they free the scarce one.

For physics, Hanna was clear: most of the list fits under the 600,000 UAH ceiling. Money isn't short; days before 1 February are. Cutting the cheapest items would save money nobody needs to save and free no time at all. An expensive item, such as a paid ad buy, might take almost no team days, so cutting it wouldn't help either.

The useful question is: which shoulds and coulds take days from the people the musts depend on? Video solutions for the forty hardest tasks would take weeks of Vira's time, and Vira also reviews the curriculum, which tutors' demo lessons wait for. Moving them to after launch frees exactly the time that's short. Look at whose days a cut frees, not just how many.

Once the list is sorted, compare the musts alone with the team's capacity: the person-days people can actually give the launch before 1 February. The musts must fit clearly below it.

Why not exactly? Because estimates are ranges and things slip: a reviewer is ill for a week, a contractor delivers late. If the musts fill every available day, there's nowhere to absorb a slip except the date, which is precisely what you agreed not to move. A plan with no slack isn't efficient; it's fragile.

The spare room isn't wasted either. Shoulds and coulds fill it: the waiting list, the adaptive test, the level report. If nothing slips, they ship. If something does, they're the first to go, and the date holds.

So “everything is a must” is not just a sorting problem. It's a sign that the project has no room to manoeuvre at all.

Sorting tells you what could go; a drop order tells you what goes first. Cutting scope well runs in five steps:

1. Apply the must test to every line.
2. Check the musts fit clearly below capacity.
3. Rank the shoulds and coulds in the order you'd drop them.
4. Get the sponsor to sign the drop order, now.
5. When a slip happens, drop the next item and report it in the weekly status.

Step 4 is the one people skip. Leo's instinct is reasonable: “I could decide in January, when we know more.” But in January every owner defends their item under pressure, with the date close and everyone tired. Decided calmly in October, the same slip becomes one line in the status note: “dropped the next item, the date holds.” If Leo cares about something near the top of the order, the time to move it is now, while it costs nothing.

A cut is easier to accept when it isn't a rejection. Nobody needs to tell Danylo or Vira no: their item moves to should or could, with the reason written down, and goes on a list for after the launch.

The habit has three parts. Apply the must test openly: can we open on 1 February and reach the goal without video solutions? Yes, because tutors can explain hard tasks in the lesson. Write the reason next to the item, so it doesn't look like a matter of taste or rank. Give the idea a place later: video solutions come back after launch, when real learners show which tasks they struggle with.

People accept a cut they can see the logic of. What they resist is a cut that feels arbitrary (“Leo decided”) or a flat no that kills an idea they care about. Avoiding the conversation by keeping everything as a must only moves the fight to January.

The signed drop order exists for one moment: a slip in January. Say the diagnostic test build slips by a week, and the order starts with the January advertising, then the level report. The move is mechanical: drop from the top of the order until the week is recovered, report it in the weekly status, and keep 1 February.

The tempting alternatives all fail. Moving the opening breaks the goal the date serves. Dropping the diagnostic test because it's the item that slipped removes a must. Asking everyone to work evenings hides the problem and burns people out.

One caveat, developed in module 3: dropping work helps only if it frees the people or time the late task needs. Cutting the January advertising doesn't speed up Danylo's build if Danylo wasn't working on the advertising.

How it fits together: cut scope, not the date; one must test; musts below capacity; a signed drop order. The case next applies this to the real list, with effort ranges and capacity.