Fixed scope or fixed date: pick one before you commit

Every delivery commitment has three numbers in it: what will be built, by when, and with how many people. A team can hold two of them. The third has to be allowed to move, because it is where everything nobody knew at the start ends up.

Most commitments that go wrong did not choose. Scope was fixed in the brief, the date was fixed in a meeting, the team was whoever was free, and each of those decisions was made by a different person on a different day. The slip that follows is not bad delivery. It is the third number moving without anyone having agreed that it could.

Fixed date, flexible scope

Use this when the date is real and outside your control: a regulation, a contract, an event, a season. The promise is "something useful ships on the day", and the work is cutting, not adding.

It only works with two things written down before the start. First, the part that must be there for the date to mean anything, kept small enough that the team is sure of it. Second, the order in which everything else would be dropped. That list is the out-of-scope list written in advance, and it is what turns a cut in week six from a failure into the plan.

The trap is a fixed date with a scope that is flexible in name only. If every item on the list turns out to be essential the moment someone proposes cutting it, the scope was fixed all along and nobody said so.

Fixed scope, flexible date

Use this when a partial result is worth nothing: a data migration, a security fix, a compliance report, an integration the other side will test end to end. The promise is "all of it, as soon as it is right".

The date still has to be said, as the team's best figure with how sure they are, and as a date that will be revisited at named points. "We expect mid-August; we will confirm or move it on 1 July, when the first customer data has been run through" is a commitment. "When it's done" is not, and nobody downstream can plan around it.

The trap here is the date being quoted onward without the condition. Whoever hears "mid-August" in a status meeting repeats it as a promise. Put the review point next to the date every time it is written.

Both fixed: then the team or the quality gives

Sometimes both really are fixed. A contract names the features and the day. Then the flexible number is capacity, and that has to be decided as deliberately as the other two: which named commitment gives up its people, and who was promised that one. It is a visible trade, made before the start.

If capacity is fixed as well, something still moves. It is quality, or the team's evenings, and both are borrowed against the next quarter. An organisation that fixes all three numbers has not removed the flexible one. It has only stopped looking at it.

How to choose, in one question

Ask the person who wants the work: "If we reach the date with two thirds of it done, would you rather ship the two thirds or wait?" The answer is nearly always immediate, and it tells you which number is fixed. Write it into the commitment in a sentence a stranger could read:

• "Date is fixed at 30 June. Scope beyond the two core flows is cut in this order: bulk import, then the audit export."
• "Scope is fixed. Expected mid-August, medium confidence, reviewed on 1 July."

If the answer is "neither, we need all of it on the date", you are in the third case, and the conversation is about what else stops. That is the same conversation as pushing back on a date, held early enough to be useful.

When it changes mid-flight

Whichever number was flexible will move; that is what it is for. The discipline is in saying so when it does. A cut from the flexible scope is reported the week it is made, not discovered at the demo. A moved date is said early, with the new date. And a change to the number that was supposed to be fixed is not an adjustment. It is a new commitment, and it goes through a change that is decided and recorded.

If you use DeliverySheet

The product does not have a "fixed scope / fixed date" switch, and you do not need one. A commitment records the committed outcome, the start and end dates and the capacity each delivering team agreed to, and the demand carries its in-scope and out-of-scope lists from shaping. Which of them is flexible is a sentence you write in the committed outcome. What the product adds is the record when it moves: a change to the date, scope or capacity is a re-baseline with its reason, and a close asks for one of three outcomes, so work that shipped on the date with cuts is recorded as delivered with exclusions and says what was left out.