Handle Change Requests Without Scope Creep

Record the requested change, price its impact and obtain written approval before revising scope. Follow a $500 newsletter-signup proposal through a practical change-control workflow.

Scope creep is extra work becoming part of a project without a corresponding decision about scope, price or delivery dates. A change request is the point where you make that decision explicit.

The useful rule is simple: a request is not an approval, and a proposal is not a revised baseline. Keep the original commitment visible while the client considers the change.

The example: CR-001 for Northstar

This fictional demonstration concerns Northstar Studio (Demo) and Website launch (Demo), as of 28 September 2026. Four of six baseline tasks are complete, or 67% by task count. The two remaining tasks are Test enquiry form, due 2 October, and Approve launch, due 9 October.

The client asks to add newsletter signup. The change proposal is:

The $125 rate is the assumption for this new change estimate. It does not revise a rate on previously recorded or invoiced work. The four-hour estimate also does not imply a four-hour calendar shift: the proposed date must account for sequencing, testing and the delivery slot.

1. Recognize the change

Compare the request with the agreed deliverables and acceptance criteria. A new newsletter capability is additional scope if the original agreement did not include it. Fixing a broken enquiry form that the original scope already promised is a correction to that scope, not automatically a billable extra.

Clarifications, new requirements and defect corrections need different treatment. Resolve that classification before quoting a fee; otherwise the client may read the proposal as a charge to finish work they already bought.

2. Document the request

Give it a stable reference such as CR-001. Write down what is being added, why it is needed, who requested it, the affected deliverable and the version of the baseline being changed.

For newsletter signup, agree the expected behaviour before work begins: where signup appears, what fields it needs, which mailing service it connects to, what successful submission looks like, and who supplies the necessary access. These are questions to settle, not promises that all possible integrations fit into the four-hour estimate.

Use the change request form to keep the request, estimate, decision and implementation record together. A task or comment can hold the reference and notes. It does not turn a pending request into an approved change.

3. Assess effort, price and delivery impact

Estimate the work required to implement and check the agreed addition. In this example, the proposal is 4 hours × $125 = $500, before any separately agreed taxes or extras.

Document the assumptions behind that number. If the required mailing-service access or final copy is missing, say how that affects the estimate or delivery plan. Separate the time spent doing the work from the calendar date when it can be delivered.

For Northstar, the proposal moves launch from 9 October to 12 October if approved. The baseline remains 9 October while the client decides. Do not move the existing dates merely because a quote has been prepared.

4. Present options

Give the client a decision they can make:

Request a response by 2 October because the decision affects scheduling. Missing that date does not mean consent. Reconfirm the proposed schedule if the client replies later.

5. Obtain written approval

Capture the decision against the specific version of the proposal: what is accepted, the additional price, the resulting date, who accepted it and when. A written response in the agreed communication channel can form the operational approval record; retain it with the project.

For this demonstration, CR-001 remains pending written approval. No client has accepted it, and the launch baseline has not changed.

Corcava estimates can use a client acceptance link for a specific estimate version. That is an estimate workflow, not a general approval button for tasks, reports or deliverables. If you use that route, verify that the accepted estimate includes the scope and commercial terms you intend to agree. Acceptance does not automatically rewrite an existing project's scope and dates.

6. Update the baseline after approval

Only once approval is recorded should you update the scope, price record, implementation tasks and affected dates. Keep a reference to the accepted CR-001 version so later reporting can distinguish the original plan from the approved change.

Before approval, report six baseline tasks and the separate pending proposal. After approval, explicitly explain any added tasks and revised denominator; a new task count should not silently make historical progress look different.

Notify the delivery team of the agreed change through your normal process. Creating a change-request task or preparing a report does not automatically notify the client or establish acceptance.

7. Execute and track the approved work

Create a clearly named implementation task once the change is authorized, and record the work against it. Compare actual effort with the four-hour estimate when it is complete. If new facts materially change scope or price, return to the decision process before committing to more work.

For an hourly change, reconcile chargeable time with the applicable rate. For an agreed fixed $500 change, invoice the agreed fee under its terms rather than silently replacing it with a different hourly charge. See time tracking and invoicing for the mechanics of generated time lines.

Keep the weekly report consistent

The client reporting example should show the same decision state as the change record:

CR-001 newsletter signup is pending. Proposed fee: $500. Decision requested by 2 October. Current launch baseline: 9 October; proposed launch after approval: 12 October.

“67% complete” describes the baseline task count. It does not approve the extra work, imply 67% of the budget has been spent, or guarantee either launch date. Any red/amber/green delivery assessment is the project owner's judgement and needs a reason.

A short check before accepting extra work

• Can you identify the part of the existing scope the request changes?
• Are the deliverable, estimate assumptions, price and calendar impact explicit?
• Is the decision tied to a named proposal version and authorized decision-maker?
• Does the project still show the original baseline until approval?
• After approval, do the tasks, report and invoice basis all refer to the same accepted change?

Use the change request form for the record and the weekly status report template for communication. For deciding which records to share, see what clients should see in a project portal.