Consulting Scope Changes: Assess and Approve Additional Work

Make the approved scope usable

The scope of work defines what the assignment includes and excludes. A deliverable is something the consultant hands over, such as a report or process map. An outcome is the intended effect of using it, such as less delay. The baseline is the approved version used to assess new requests.

Acceptance criteria define how both parties check whether a deliverable is ready for handover. For example, a process map might need to show steps, responsibilities and approval points. Change control means recording a request, assessing its effects and deciding on it before altering commitments.

Start with the agreed outcomes, deliverables, boundaries, assumptions, client inputs and acceptance criteria. A list of activities alone may not explain what the client will receive. Identify the person authorised to approve changes and the people who must advise on operational, financial or technical effects.

The management consulting overview explains the broader engagement. ISO 20700:2017 provides guidance for effective consultancy delivery. The process below is a suggested practical approach, not a reproduction of the standard’s clauses. It supports clarity between the parties; it does not replace the signed agreement or applicable professional and legal advice.

Make the request understandable and comparable

A change request is a documented description of a proposed revision, not permission to implement it. Describe the desired result instead of using broad phrases such as “develop the system” or “improve the study”. Identify the affected deliverable, what the client wants added or revised, why it is needed and the date by which the change would be useful. Include an example where it improves understanding, without sharing confidential information unnecessary for assessment. Clear requests support more reliable estimates and a useful discussion of alternatives.

Compare the request with a specific item in the approved scope. If the assignment covers process analysis for one branch, extending findings to branches that operate differently requires assessment. Correcting an error in the agreed branch’s process map should be considered against the original quality obligation. Do not classify a request from its title alone. A small-sounding change may have a wide effect, while a seemingly substantial request may simply clarify an agreed deliverable.

Give each request an explicit status, such as under assessment, approved, deferred or rejected. Identify the decision owner and any missing information. Recording a request in meeting notes does not approve it, and an estimate does not commit either party to delivery. Distinguishing these states helps the delivery team know which work can begin and which work must wait.

Classify the request before pricing it

Ask whether the request corrects an agreed deliverable, clarifies an existing requirement or adds a new outcome. A correction needed to meet agreed acceptance criteria should not automatically be relabelled as extra scope. Conversely, an additional business unit or new implementation stage may materially expand the work.

Use the baseline and evidence rather than memory. If the original wording is ambiguous, resolve that ambiguity openly before assigning blame or assuming a fee. Record the interpretation and update the working description so the same disagreement does not recur.

Assess the full effect

Describe the requested change, its purpose and the consequence of not making it. Estimate additional effort, timetable, fees and client input. Identify dependencies: the activities or inputs on which delivery relies. Explain uncertainty in the estimate and identify what must be confirmed. Check effects on work already completed and on related deliverables.

In a hypothetical example for illustration, a process-mapping assignment covers one service. The client asks to include a second service with different systems and approval roles. The assessment should consider interviews, data access, validation and documentation, not just the time needed to draw another diagram. It should also identify whether the original completion date remains realistic.

Explain the assumptions behind the estimate

An estimate may depend on data availability, employee participation or another party’s approval. Place those assumptions alongside the proposed duration and effort, and explain what changes if they do not hold. Where evidence is insufficient, a limited discovery activity may be proposed before a larger commitment, with its output, boundaries and acceptance arrangements defined under the existing agreement.

Do not reduce the impact to consultant hours alone. The client may need to review records, provide specialists or test a revised output. Discuss that contribution with the people responsible before fixing the schedule. Also examine the sequence of work: can the addition run in parallel, or must previously accepted work be revised? Explaining the difference supports realistic timing and reduces delivery surprises.

If one output replaces another, state clearly what will leave the scope. Do not call an arrangement a substitution while the team continues to deliver both outputs. Check how removal affects other outcomes and stakeholder expectations, then update the reference deliverables list so a later review does not assess the project against an obsolete version.

Offer explicit options

• Approve the addition with the stated changes to time and cost.
• Replace a lower-priority item while preserving an agreed limit.
• Defer the request to a later phase.
• Reject the request and retain the current baseline.

Explain the consequences of each option. Do not imply that more scope can always fit the same budget and deadline. Where urgent work is necessary, use the agreed emergency authority and record the decision promptly; urgency should not become an undocumented standing exception.

Record authority and update the baseline

The authorised parties should confirm the selected option, revised deliverables, price or pricing basis, dates and acceptance conditions before the additional work proceeds, subject to the agreement’s provisions. A casual discussion with a stakeholder may identify a need without authorising expenditure.

Give the change a reference and effective date. Update the plan, responsibilities and dependencies, then tell affected participants what they must do differently. Preserve the previous version so the reason for the revised commitment can be traced.

Close the change with a clear handover

Link completed work to the change reference and its acceptance criteria. Explain which documents or models were revised, where the approved version is held and what follow-up the client must undertake. If a defined reservation remains, record its owner and treatment instead of describing the handover as complete without explaining the limitation.

At the end of the assignment, review the change log for patterns that can be improved. Repeated requests may arise because an operational representative was absent during scoping or because an assumption was not tested early enough. Apply those lessons to the next assignment. The purpose is not to prevent every change, but to make each change understandable, justified and agreed, with commitments traceable from request to handover.

Start with one change and control its progress

Take one current request: compare it with the approved scope, classify it, assess its effects and assumptions, and present options. After an authorised decision, update commitments and inform participants, then verify delivery against clear criteria. If the request is rejected, keep it out of the delivery plan. This makes changes traceable without treating every clarification as additional paid work.

The Business and Operation Modelling service can help define processes, interfaces and responsibilities. A controlled change should leave both parties able to describe the same commitment.