Stop Doing Changed Work Before the Client Approves the Tradeoff

Scope changes rarely arrive looking official

A client asks you to review one more supplier proposal. An implementation call uncovers another location. The executive recap turns into a custom board presentation. Somebody says, "Can we add this while we are here?"

None of those requests sound unreasonable. Some are small. Some improve the work. Some should be included because they help you deliver the outcome you already promised.

The trouble starts when your team treats every reasonable request as already approved work. The project expands, the original date stays put, and the advisor absorbs the analysis, meetings, supplier coordination, and follow-up. Nobody made a bad decision because nobody made a decision at all.

You do not need to turn every client question into a formal contract negotiation. You do need a consistent point where the team stops, checks the current commitment, and chooses how the new request will be handled.

Start with the record, not your memory

Before you call something out of scope, compare the request with the agreement and the working plan.

Pull the signed terms, proposal, stated deliverables, exclusions, assumptions, revision limits, client responsibilities, and timeline. Then check the project record. Teams often discover that the contract is broad while the working plan is narrow, or the proposal promised something the delivery team never saw.

Ask five plain questions:

1. Does the request support a deliverable already promised?
2. Does it add a new deliverable, location, system, stakeholder group, supplier, or approval cycle?
3. Does it require different expertise, more validation, or another party's work?
4. Will it change the date, fee, capacity, risk, or quality of the original work?
5. Who has authority to approve that change for your firm and the client?

The contract and applicable requirements control the obligation. If the language is unclear or the change carries meaningful legal or commercial risk, use qualified counsel. Your operating process should make that review easier by preserving the request and the evidence around it.

Give every request one of four treatments

A useful scope process does more than label work "in" or "out." It gives the advisor and client four honest options.

Include it

The request is already part of the promised outcome, or the effort is minor enough that the firm intentionally absorbs it. Record that choice anyway. Include does not mean invisible. Name the work, owner, and expected effect so the same exception does not get rediscovered in three meetings.

Trade it

The new work matters more than something in the current plan, so the client swaps priorities. A second supplier analysis might replace a lower-value deliverable. A faster executive readout might reduce the depth of another report. Write down what enters, what leaves, and whether the date stays credible.

Change it

The request adds enough work, risk, time, or cost to require revised approval. That may be a change order, an amended proposal, a new phase, or another form your signed terms allow. Describe the added outcome, work, assumptions, owner, fee, timing, and effect on the original plan before delivery starts.

Decline or defer it

The request does not fit the engagement, the team cannot deliver it responsibly, or it would weaken the work the client already bought. Say why, then offer a useful next step if one exists. That could mean a later phase, a qualified specialist, or a decision to leave the work with the client.

This is not about charging for every extra email. It is about making the tradeoff visible. A free exception can be a good commercial decision when the firm chooses it with open eyes. Repeated untracked exceptions are just an undocumented service model.

Do not let the person doing the work approve the commercial change

Scope expands fastest when the person closest to the client can commit the firm in real time.

A project coordinator wants to be helpful. A technical specialist wants to solve the problem. An advisor wants to protect the relationship. Each one can say yes to a request that looks small from their seat and creates a much larger delivery obligation for somebody else.

Set decision rights before the request appears. Your rule might allow the project owner to absorb minor work within a defined reserve, while anything that affects a deliverable, date, supplier dependency, fee, or client responsibility goes to the engagement owner. Material contract changes may need executive or legal approval.

The threshold should fit your firm. The important part is that the team knows who can promise what. Delegation works better when authority travels with clear boundaries, which is the same discipline behind moving work off the founder without losing the client relationship.

Reply with choices before you reply with a date

The worst response to a vague extra request is a confident delivery date.

A better response sounds normal: "We can help with that. I need to compare it with the current work plan and come back with the cleanest option."

Then return with the decision. For example:

• We can include the review without changing the current fee or date.
• We can add the review if we move the supplier scorecard into the next phase.
• We can add the review through a scope change that moves the delivery date by one week.
• We should keep this outside the engagement because it requires expertise the current team does not have.

Do not hide the effect to make the yes easier. The client should be able to see what changes in the work, price, timing, responsibilities, or risk. If nothing changes, say that too.

This is easier when the original proposal process produced a clear decision brief and the firm already defined acceptance before the project started. Weak scope at the start makes every later request harder to classify.

Keep one scope decision record

Do not leave the request in chat, the estimate in email, the approval in meeting notes, and the revised task list in somebody's head.

Keep one record with:

• The request, requester, and date
• The current scope evidence reviewed
• The business reason and desired outcome
• The effect on deliverables, timing, cost, capacity, suppliers, and client responsibilities
• The chosen treatment and rejected alternatives
• The internal and client approvers
• The revised tasks, owners, dates, and documents

Connect that record to the client and project. If the decision changes commercial terms, connect the approved document too. If it creates follow-up, put the action in the same follow-up system your team already reviews.

The record protects more than margin. It gives a new project owner the context behind the change. It helps the team explain why a date moved. It keeps the final acceptance conversation tied to the work the client approved, not the work everybody vaguely remembers discussing.

Review the pattern, not only the request

One scope change may be normal. Five similar changes across different clients are operating evidence.

Review changed work each month. Look for requests you keep absorbing, deliverables clients repeatedly misunderstand, supplier work you consistently underestimate, and approvals that sit open while the team keeps moving.

Then fix the source. Update the proposal language. Add an exclusion. Reprice a service. Adjust the delivery reserve. Train the team on decision rights. If the new work has become standard, stop pretending it is an exception.

This review also belongs in your capacity planning process. Approved changes consume real delivery time. A pipeline forecast that ignores changed work can make the next project look available when the team is already committed.

Make scope control part of the operating system

Advisor OS CRM connects client records, activities, proposals, tasks, projects, contracts, and reporting. That gives an advisory firm a shared place to keep the original commitment, the changed request, the decision, and the delivery work connected.

The software cannot decide whether your firm should absorb an extra request. It can stop that decision from disappearing between inboxes and project meetings.

Take the last three projects where the work changed after kickoff. Find the original request, who approved it, what moved, whether the client saw the effect, and where the final decision lives now. If the answer depends on asking the person who was there, your scope process is not ready to scale.

Use the free Advisor OS agency scorecard if project commitments, client activity, ownership, and follow-up still live in separate systems.