Scope changes and how they are handled

Scope moves. That is not a failure of planning, it is what happens when a plan meets a real market. The thing worth designing is not a scope that never changes, it is a change process where both sides can see the trade.

The one rule

Nothing gets added without something else moving. A new priority arriving mid-cycle is fine. A new priority arriving mid-cycle while the delivery date stays exactly where it was is not, and treating it as fine is how projects quietly fail.

So when something new comes in, the conversation is explicit about which of three things is happening:

1. Something already in the plan moves out, or moves to a later cycle.
2. The date moves.
3. It is quoted and paid for as extra work.

Any of the three is a perfectly good answer. Silently choosing a fourth option, absorbing it and hoping, is the only one that is not.

Inside a retainer

A retainer cycle has a capacity, and the cycle plan is a claim about how it will be spent. Mid-cycle changes are re-agreed against that plan, which normally means option one: the new thing displaces something. Nothing about that costs extra, and nothing about it needs a change order. It just needs to be said out loud so the plan on paper still matches the plan in reality.

Work that is genuinely a different product, an audit, a migration, a workshop, is usually better as its own productized service than as something a cycle absorbs.

Inside a fixed-price service

Fixed price means fixed scope. If the work turns out to be materially larger than what was quoted, you get told before the extra work is done, with a price. You will not receive a surprise invoice, and you will not receive a quietly narrower deliverable either.

The most common version of this is a code review where the codebase turns out to be several codebases. The honest answer there is to say so on day one and quote the difference, not to review a third of it at full depth and call it done.

Inside a custom project

Custom projects are milestone-based on purpose. A milestone is a natural checkpoint where a scope change costs almost nothing to absorb, because the next milestone has not been started. Changes are collected and applied at milestone boundaries wherever possible, and quoted as an adjustment when they cannot wait.

What you can hold me to

• No work you did not agree to gets billed.
• No scope you did agree to gets quietly dropped.
• If something is going to be late, you hear it as soon as I know, not at the deadline.