Tracking scope changes in a client project

Record a client scope change as a request, an impact assessment and an authorised decision before adding it to committed work. Keep the starting agreement and each approved revision identifiable, so the client and delivery team can see why a deliverable or date changed.

Identify the agreed starting point

Locate the approved deliverables, acceptance criteria, assumptions and dates, and identify who can authorise a revision. A client comment might clarify the brief, point out work that does not meet the agreement, or ask for something new. Compare it with the agreed scope before calling it a change; a correction to incomplete work should not quietly become an extra request.

For example, a client might ask for a second language version of a website page after approving a single-language brief. That fictional request needs assessment before it enters the delivery plan.

Keep a record for each request

Record the requester, date, desired outcome, reason, affected deliverables, owner and decision deadline. Keep the discussion with the request, but identify the final decision separately. Useful states are proposed, assessing, awaiting decision, approved, rejected and deferred. These are suggested labels, not required software features.

Assess the effect before deciding

Check the effect on scope, quality, dates, team effort and risk. If the deadline stays fixed, say what other work would move. Present practical options, such as adding the work with a later milestone, substituting it for another item or deferring it. An estimate is not an accepted amendment.

For each request, log it, assess its effect on the agreed baseline, decide whether to approve, reject or defer it, and update the plan if it is approved. For client work, identify the decision-maker through the engagement's agreement or governance arrangements. A software role alone does not establish that authority.

Impact Assessment Factors for Scope Changes

Apply and communicate the decision

After approval, update affected deliverables, tasks and dates, and connect them to the decision record. Preserve the earlier baseline so later reports can explain the change. If the request is rejected or deferred, record that result and keep it out of committed work. If urgent work starts under temporary authority, record who authorised it and its limits at the time.

At each client review, show open requests separately from approved changes and current delivery. The client should be able to find the accepted scope, the next decision and the version of each deliverable now due.