What it means
Projects begin with ideas that are still moving, and if every conversation silently changes the expected result, the team cannot tell whether it is on time or within budget. A scope freeze gives everyone a stable reference for decisions, without pretending that new facts will stop appearing.
The baseline should describe what will be delivered, relevant specifications, milestones, assumptions, exclusions and the tests for acceptance, and for a website it might name the number of page templates, languages, integrations and rounds of revision. A vague brief cannot support a meaningful freeze.
The sponsor, customer and delivery lead should agree the baseline at a practical stage, because freezing too early can lock in guesses while freezing too late leaves work already started with no agreed boundary. Record version and approval, and make sure suppliers and subcontractors work from the same version, especially when drawings or specifications change quickly.
After the freeze, log proposed changes rather than rejecting them automatically, asking what changes, why, who pays and whether the completion date moves. The authorised decision-maker can approve, reject or defer the change, and only an approved change should update the baseline, with the previous version retained for comparison.
There is an important distinction between a changed request and a correction of work that failed the agreed specification, and the team should not label its own error a new feature. Conversely, a customer may request an improvement after seeing the agreed result, and that is a change even when the request sounds small.
Commercial treatment depends on the contract and facts, so do not promise a free or paid variation based only on a label. A freeze also helps internal projects, because if leadership keeps adding reports to a new system launch without adjusting the deadline or resources, the team can show the trade-off.
It is not a shield against urgent legal, safety or operational needs, which may require an expedited but still documented decision. It also creates a fair basis for measuring progress and explaining why a later choice affected the budget or date.
In practice
Real-world examples.
Example
A cafe agrees drawings and specifications for a kitchen refurbishment. A later request to move plumbing is logged and priced before the contractor starts the extra work.
Example
A software team freezes the launch scope at two integrations. A third is approved only after the sponsor accepts a later launch date.
Example
A supplier delivers the wrong finish against the approved specification. Correcting it is treated as fixing a defect, not as a new paid scope item.
Formula
Calculation
Approved scope change impact = Revised forecast cost - Baseline forecast cost
Worked example. An invented project has a baseline forecast of $240,000. A requested feature adds $18,000 in estimated work and saves $3,000 of work that will no longer be needed.
- Revised forecast cost = $240,000 + $18,000 - $3,000 = $255,000.
- Approved scope change impact = $255,000 - $240,000 = $15,000.
This is a planning comparison, not automatically the price billed to a customer. Contract terms, margin, taxes and risk may affect that price. Record the schedule impact separately.Case study
Seen in the real world.
This illustrative and entirely fictional example follows Cedar Clinic, an invented medical practice planning a new appointment portal. The approved brief covered online booking, reminders and a basic staff dashboard. During development, a manager asked for insurance eligibility checks and a new patient intake form. The developer started work on both without recording the change, assuming they were part of "a modern portal." Two weeks before launch, the practice expected the extra features to be finished at the original price.
The developer had not tested the insurer connection and could not meet the agreed date. The project lead paused new additions, reviewed the signed brief and separated the original deliverables from the later requests. Both sides agreed to launch the tested booking functions first and assess the remaining features as a separately approved phase. For the next project, Cedar introduced a scope baseline with versions, exclusions and acceptance criteria.
Every new request received a short note stating the value, cost, dependencies and deadline effect. The process did not eliminate changes. It made the choices visible and kept the teams aligned.
Watch out
Common mistakes.
- Calling a vague project title a frozen scope when deliverables and exclusions are not defined.
- Treating every post-freeze request as impossible instead of assessing it through change control.
- Charging for correction of work that did not meet the agreed baseline without examining the contract and facts.
Questions
People also ask.
Does a scope freeze ban changes?
No. It establishes the baseline so later changes can be assessed and approved with their effects understood.
When should the scope be frozen?
Once the deliverables and acceptance criteria are clear enough to estimate and approve, and before substantial dependent work proceeds.
What should happen to the old version after a change?
Keep it with the approval history so the team can see what changed, when, why and who accepted the impact.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%