Handle a Creative Project Change After the Scope Is Approved

Separate the request from the response

Write the request in neutral terms before deciding whether it is small. Perhaps a brochure now needs a second language, a logo project needs packaging mockups, or an approved animation needs a new ending. Preserve the client’s wording and identify which deliverable or assumption it changes. A friendly description such as quick extra is not a production estimate.

Check the current scope, revision allowance and agreement process. A correction needed to meet the agreed specification is different from an additional format or a changed direction. If the distinction is unclear, explain the uncertainty and compare it with the written brief. Do not turn every question into a charge, but do not quietly promise an unassessed addition.

Identify dependent work before estimating

List the production steps the change touches: source content, design, approval, export, quality review and delivery. A second language may affect line length and layout as well as translation supply. Replacing a final image can require new permissions and alternative text. The visible edit is only one part of the work.

For an illustrative six-page brochure, adding two pages may require new copy, new image choices, a revised contents reference and another proof. Estimate those activities separately rather than multiplying the page count blindly. State which inputs the client must provide and what remains uncertain. This makes the estimate inspectable without pretending that every change can be measured exactly in advance.

Offer a small set of realistic options

Show the client two or three routes with concrete consequences. One option may keep the original delivery date by replacing an existing deliverable; another may retain everything with a revised schedule and fee. A third may treat the addition as a later phase. Do not offer an impossible deadline as a courtesy that you hope to rescue through unpaid overtime.

Use the same comparison headings for every option: included output, excluded output, client input, review point, delivery date and commercial effect. Keep recommendations connected to the project goal. If the launch only needs one approved language, a later translation phase may be practical; if both are essential, the launch plan needs to acknowledge that dependency.

Confirm the chosen variation through the agreement process

Follow the contract change procedure and applicable requirements. Australian Government guidance, for example, explains the value of documenting agreed variations; it is jurisdiction-specific guidance rather than a universal legal template. Use qualified advice when you need terms interpreted or rewritten. A project note cannot override the actual agreement.

Operationally, the record should identify the original project, what changes, which version is replaced, the effect on schedule and cost, and the people approving it. Make any response deadline explicit and reasonable. Do not treat an unanswered message as approval unless the agreement and applicable rules clearly support that result. Resume the changed work only when the necessary decision is in place.

Keep the revised baseline easy to find

Update the working brief, deliverable list and schedule after approval. Mark superseded versions clearly so that a collaborator does not continue the old route. Keep the change record beside the project rather than scattered across a chat history. Tell the client which document now defines the next review.

At the next milestone, compare the work against the revised baseline. If another request appears, use the same short process without reopening settled points unnecessarily. At project review, note what caused the change: missing information, a new business requirement or an unclear original assumption. Improve future briefs from that evidence instead of assuming every change was preventable.

Questions that come up