Practical workflow · Projects from kickoff to payment

Handle a mid-project scope change before work continues

Preserve the original agreement and separate the requested change, cost and timing impact, and decision. Includes a change record and client reply.

Further work follows a confirmed change while the original scope stays traceable.

Chill&AutomateUpdated October 10, 20264 min read
An original project folder separated from a proposed additional scope card.
Chill&Automate illustration.

“One more page” needs its own decision

A project is underway when the client asks for another page. The request is understandable, but nobody confirms whether it changes the price, delays delivery, or replaces something already agreed. The team starts work and resolves the difference at handover.

Describe the extra work as a change against the accepted baseline. Separate receiving a request from agreeing to perform it. Keep the original scope: overwriting it removes the distinction between existing and additional work.

Use the change record and client reply and completed fictional example. They support your particular agreement; they are not a universal contract amendment.

Compare the request with the accepted scope

Open the accepted proposal and identify its version. Describe the change for someone who missed the latest call: “Add a Contact page with a separate enquiry form” is more useful than “finish the website.”

Decide whether it clarifies an agreed deliverable, corrects an unmet requirement, or introduces new work. Do not automatically classify every comment as a paid addition. Equally, a small-looking feature does not silently become part of the accepted scope.

When unsure, ask a specific question and leave the change open. For the accepted baseline, see proposal acceptance.

Explain the consequences in one reply

Before asking for a decision, state the effect on deliverables, price, timing, and required inputs. Distinguish an estimate, fixed addition, and hourly work. Distinguish a confirmed date from an option dependent on capacity.

In the fictional model, the client requests a Contact page. The studio can keep the original scope and date, or add the page and move delivery. The $600 addition is an illustrative chosen amount, not a market estimate or a currency conversion.

The Contact page is outside proposal WEB-014 v2. We can add it for a fixed $600 addition using the same tax treatment as the original proposal. Delivery moves to October 16 if the inputs arrive by October 12. To retain the original date, we can keep the original scope. Please confirm which option you choose.

Adapt the wording and tax details to the actual agreement. If you have not checked capacity, state when you will confirm the impact instead of inventing a new delivery date.

Connect acceptance to a specific change

Assign an identifier such as WEB-014 / CH-02. Retain the issued change, client response, and internal capacity decision. A general “great” during a conversation about several options may need clarification.

Before continuing, establish that the person confirming the change can do so under your agreement. The necessary consent or signature method depends on your terms and circumstances; this template does not prescribe it. An ambiguous answer remains unresolved.

Record when the new scope takes effect. Keep the earlier proposal and changes in the history.

Update the plan after the decision

Following confirmation, update tasks, dates, and commercial records so they refer to the same change. Pass it to the person performing the work. A created task is not a substitute for the client’s decision.

If the client declines, continue with the accepted original scope. If extra work has already started, record that fact and agree on the next step. Do not rewrite history as an earlier approval.

Use a fictional project to try acceptance, rejection, and a conditional response. Each route should make the authorized work and supporting decision clear. Automate recurring administration once this distinction works. After delivery, continue with delivery to payment.

The same request has three possible outcomes

Acceptance of CH-02: Jamie explicitly confirms the Contact page, illustrative addition and conditional date. Casey verifies capacity and links the decision to the tasks. Rejection: Jamie wants the original price and date; mark CH-02 declined and do the original scope. “Yes, but without moving the deadline” does not accept the offered option: keep CH-02 open, give Casey an agreed date to check alternatives and request another decision. If inputs miss October 12, recheck delivery rather than promising October 16 without its condition being met.

Check your result

Do I have enough evidence for the next step?

Checks are temporary reminders on this page. They are not saved and do not verify the outcome for you. Record evidence in your own notes or the downloadable worksheet.