Consulting Change Requests: Keep Client Decisions and Delivery Aligned

Manage a consulting change request by recording what the customer wants changed, assessing its effect, obtaining an authorized decision, and updating the working plan. Make the process easy enough to use during normal client work. A change hidden in a meeting note can become an unapproved commitment before anyone notices its effect.

Atlassian recommends a visible scope baseline and an approved change process. Atlassian scope-creep guidance. Atlassian describes acceptance criteria as testable conditions for a requested outcome. Atlassian acceptance-criteria guidance. The practical workflow below is a proposed management approach, not a claim that a particular tool or provider produces guaranteed results.

Distinguish clarification from changed work

Some questions explain an existing deliverable. Others add outputs, change assumptions, introduce new stakeholders, or alter acceptance. The project owner should compare the request with the agreed scope and involve the appropriate technical or commercial reviewer when the distinction is unclear.

Do not make the customer argue over a label before you understand the need. First capture the desired outcome and why it matters now. Then explain whether the request fits the current commitment or requires a decision about scope, timing, resources, or commercial terms. The purpose is a visible trade-off, not a reflexive refusal.

Use a short request record

Record the request once and link it to the relevant project item. Include the customer's words, the business reason, the requester, the affected deliverable, and the date a decision is needed. Keep proposed solutions separate from approved instructions.

• Requested change and desired outcome.
• Existing scope or assumption affected.
• Technical impact and validation owner.
• Effect on schedule, responsibilities, and other commitments.
• Options: include, defer, replace existing work, or decline.
• Authorized customer and internal decision-makers.
• Decision, rationale, and updated working record.

A small firm may manage this record in its existing project system. A larger operation may need a more formal approval route. The essential control is that the people executing the work can identify the current approved decision and understand what changed.

Assess impact before promising the answer

Ask delivery to evaluate dependencies, required skills, testing or review, and any effect on existing work. Ask the commercial owner to review the agreement and proposed terms where relevant. Do not turn a rough comment made during a client call into a delivery estimate without the necessary review.

Consider the cost of interruption as well as the new task itself. A small request can displace a planned workshop, require another stakeholder review, or reopen accepted work. Explain the practical consequence in language the customer can use to decide. Avoid unsupported precision when the team still needs information.

Give the customer a real choice

Where possible, present options with clear consequences. The customer may choose to replace a lower-priority deliverable, move the request into a later phase, approve an amended engagement, or retain the original scope. The technical and commercial teams should validate which options are actually available.

Do not imply that every change must create an additional charge. The treatment depends on the agreement and approved decision. Equally, do not train the team to absorb every request informally. A visible decision protects the customer from surprise as much as it protects your delivery plan.

Illustrative example: a new stakeholder requests another business unit

Imagine a process-mapping engagement originally covering one operating team. During a review, a new stakeholder asks to include a second business unit with a different workflow. The consultant wants to be helpful and agrees to explore it immediately. This scenario is hypothetical.

A controlled process captures the new unit's requirement, checks whether existing findings apply, and evaluates the additional interviews and review. The customer can then choose whether to expand the current work, substitute the new unit, or plan a separate phase. The consultant can remain helpful without independently changing the firm's commitment.

Update the plan people actually use

After approval, update the relevant scope reference, project tasks, dates, acceptance criteria, and billing coordination record as appropriate. Tell the affected team members what changed. A signed change document is not enough if delivery continues using the old task list.

Preserve the previous version and decision trail. Later questions should be answerable without reconstructing several conversations. If a request is declined or deferred, record that outcome too so it does not reappear as an apparently new instruction at the next meeting.

Keep urgent requests accountable

Define who can authorize an urgent exception and how the decision will be documented. Urgency can justify a faster route, but it should not erase technical review or approval authority. The operating owner should know which activities may begin and what must wait.

After an urgent exception, close the record and confirm the effect on other commitments. Avoid a process where temporary permission becomes a permanent expansion through inertia. The customer and your team should return to a shared understanding of the current engagement.

Review patterns that reveal a scope problem

Track repeated request types, work started before approval, changes caused by missing discovery, and accepted changes that were not reflected in the project plan. These signals can improve both sales preparation and delivery management.

Begin with the most common informal request your consultants receive. Give it a small, clear decision route and test it in normal client conversations. A useful change process lets a firm adapt to real needs while keeping ownership, expectations, and the delivery plan understandable.

Put clear ownership around the work

Escencion provides Managed Sales & Business Operations for technology companies. Our current client focus is MSPs and MSSPs. Explore our Managed Business Operations approach, or discuss the responsibilities you need managed. Your technical team retains technical validation, approved commitments, engineering, and service delivery.