Fit-out scope rarely stays still. A joinery detail is added, a finish is swapped, an item is dropped. Each change arrives through a message, a site conversation or a revised quote, and within weeks nobody is sure which changes were agreed, what they cost or whether a revised quote has been counted twice.
This guide sets out a scope and cost change register for a restaurant fit-out. The baseline, changes and amounts are an original fictional illustration. The record supports coordination; contractual, technical and payment decisions remain with the responsible people and their applicable requirements.
Fix the baseline first
Every change is measured against something. Record the baseline package and its revision, the currency, and one consistent tax basis used for every amount in the register. List the exclusions in the baseline exactly as written, because many disputed changes turn out to be items that were never included.
Keep the baseline version fixed during the review. If a new authorised baseline incorporates earlier changes, reconcile the transfer and start a new register version. Retain the old baseline and ledger so earlier amounts cannot be added again.
Give each decision a unique entry
Give each scope change a stable change ID. Give every distinct proposal or amendment its own entry ID and revision, linked to the parent change and earlier entries. Record why it is needed, the scope before and after, the written cost and time impacts, dependencies and unknowns. Retain the proposer, reviewer, authorised decision, evidence and date. Implementation and verification are separate later entries.
Each entry appears once in the calculation. Keep earlier approved entries included when a further amendment adds a net amount. Deferred, rejected and superseded proposals are not approved amounts. A change without an agreed price remains explicitly unpriced, including when its scope has already been approved.
Worked example: three changes against one baseline
In this fictional fit-out the baseline is INR 1,000,000. CH01 adds joinery and is approved at plus INR 40,000. CH02 omits an item and is approved as a documented credit of minus INR 10,000. CH03 revises a finish and is pending at plus INR 25,000.
The approved scope allowance is INR 1,030,000: the baseline plus the two approved signed deltas. CH03's INR 25,000 is shown separately as a known pending proposal. The allowance is not actual spend, a cash requirement, a final forecast or an approval of anything still pending.
A negative amount enters the allowance only as a documented credit. A lower quote that was discussed but not agreed is not a realised saving.
| Fictional item | Status | Signed amount (INR) | In approved allowance? |
|---|---|---|---|
| Baseline, revision A | Agreed baseline | 1,000,000 | Yes |
| CH01 rev A, added joinery | Approved | +40,000 | Yes |
| CH02 rev A, omitted item | Approved, documented credit | -10,000 | Yes |
| CH03 rev A, revised finish | Pending | +25,000 | No, shown separately |
| Approved scope allowance | Calculated | 1,030,000 | Baseline plus approved deltas only |
Amendments are net deltas
Keep the original approved entry in the ledger. Record a later amendment as a separate entry linked to the same change ID and earlier revision. Enter only the additional authorised difference from the amount already included. Preserve superseded proposal versions in the manual history, outside the active calculation.
For example, if CH01 were later approved at a total of INR 45,000, retain CH01-A at INR 40,000 and add CH01-B at INR 5,000. Together they contribute INR 45,000. Replacing the earlier 40,000 with 5,000 would lose the original approval; adding a further 45,000 would double count it. This hypothetical amendment is not included in the table above.
Time impact is not a sum
Record each change's written time estimate, but do not add them together as a total delay. Some changes run in parallel, and others depend on one another, so the effect on the opening date depends on the sequence of work rather than on simple addition. Note dependencies against each change and ask the people planning the programme what the combined effect is.
What change-control guidance supports
The Association for Project Management describes change control as the process through which requests to change an approved baseline are captured, evaluated and then approved, rejected or deferred. Its outline steps are to log the request, review it, assess its wider impact on areas such as scope, time, cost and risk, make a recommendation for a decision, update the plan if approved and then monitor implementation. This guide uses only that general sequence. The register, fields and example are original, and no template, legal rule or engineering rule is drawn from the source.
Put it into practice
Your action checklist
Your progress saves in this browser. No sign-up needed.
0 of 9 complete
From reading to doing
Fit-out scope and cost change register
The Fit-out Changes worksheet records a fixed baseline amount, currency and tax basis, with one active row per unique proposal or amendment entry. Approved signed deltas accumulate against that baseline; later amendments add only the difference while earlier approvals remain included. It shows known pending proposals separately and counts unpriced entries by decision state. Missing baseline data, invalid entries, duplicate entry IDs, inconsistent currency or tax basis, undocumented negative amounts or approved unpriced work block the approved allowance. An unpriced pending proposal stays visible without entering the known pending subtotal. Manual sections retain scope, evidence, authority, revision history, time dependencies, implementation and verification. It does not forecast final cost, sum delay days, approve work or authorise payment.
Open the Fit-out Changes tab in the launch workbook. Keep a copy for your own business.
Download the free workbook See what’s inside the toolkit →Sources & further reading
- What is change control? (Association for Project Management) ↗
Retrieved 7 November 2026. Used only for the general sequence of capturing, evaluating, deciding on (approve, reject or defer), updating the plan and monitoring changes to an approved baseline. No template, legal rule or engineering rule is drawn from it. The register and figures are original.
Published by Keystonne Grow. Product links connect to the Keystonne ecosystem; check the linked product or service for its current scope.