Change Request Best Practices for Client Delivery

Good change request practice is not bureaucracy for its own sake. It is how a delivery team keeps useful flexibility from turning into invisible rework. The point is to make the decision visible before changed work becomes the new assumption.

This article uses a consulting example: a client has approved a strategy review engagement with discovery interviews, analysis review, and a recommendations report. Midway through discovery, the client asks for extra stakeholder sessions and an earlier leadership readout. The request may be reasonable, but it changes the approved baseline.

For U.S. federal contracts, FAR Part 43 distinguishes bilateral modifications signed by both parties from unilateral changes made under authorized clauses, and it says government change orders are issued in writing by the contracting officer where the clause permits that change (FAR Part 43). Private consulting projects are governed by their own agreements and jurisdiction, but the practical lesson travels well: material change needs a written authority trail.

Start With The Reason For Change

The reason section should explain the business need, not merely repeat the requested task. “Add four interviews” is an activity. “Validate whether implementation handoffs are causing onboarding delays” is the reason.

Weak wording:

Client wants more interviews, so we will add them to discovery.

Better wording:

Reason for change: Initial discovery interviews indicate that onboarding delays may occur during implementation handoff. The approved interview list does not include implementation managers, so the team cannot verify this finding against the current evidence plan.

Annotation: the stronger version names the emerging fact, the gap in the approved plan, and the decision problem. It does not promise that the extra interviews will prove the theory.

A useful reason section also names what happens if the baseline remains unchanged:

If not approved: The recommendations report will note implementation handoff as an unverified hypothesis and will not include implementation-team evidence.

That sentence helps the sponsor choose deliberately. It avoids the quiet middle ground where the team keeps the old scope but writes as though new evidence exists.

Define Scope Impact In Boundaries

Scope impact should describe what changes, what stays outside the change, and which baseline document is affected. If the original project brief approved eight interviews, the change request should say whether the new total is ten, twelve, or a different phase.

Example:

Scope impact: Add four implementation-manager interviews to discovery. Update the evidence log and interview summary to include this group. This change does not add process redesign workshops, implementation planning, software configuration review, or additional executive interviews.

The “does not add” sentence is not defensive. It is useful project hygiene. Many disputes begin when a change request describes the added work but leaves neighboring work implied.

Decision analysis: suppose the sponsor says the new interviews are urgent because the leadership meeting is two weeks away. The delivery lead should compare three options.

The best option depends on the client’s decision need. If leadership only needs directional risk language, the limited validation call may be enough. If the recommendation will drive operating model changes, the full interviews may be worth the schedule effect.

Show Schedule And Cost Implications Together

Schedule and cost are connected. A request to keep the same deadline while adding work usually changes staffing, review depth, or the amount of work that can be done confidently.

Use paired language:

Schedule impact: Discovery extends by five business days if interviews occur after [date]. If all four interviews are scheduled by [date], the final report date can remain [date] with the analysis review shortened from two rounds to one.

Cost impact: Additional fee is [amount] for interview preparation, facilitation, notes, evidence-log update, and report revision. Estimate assumes one scheduling cycle and no new stakeholder group beyond implementation managers.

Annotation: the schedule section gives a condition. The cost section says what is included in the estimate. Both are easier to approve than a vague note that “fees may increase.”

For government work, FAR Part 43 says change orders that are not forward priced can require a change order plus a later supplemental agreement reflecting the equitable adjustment in contract terms (FAR 43.204). That is U.S. federal procurement language, not a rule for every business contract. Still, it points to an important habit: separate authorization to proceed from unresolved pricing only when the agreement and approver allow it.

Keep the supporting calculation alongside the approval record. Project budget spreadsheets from Stackrows can hold the cost detail behind a proposed change. Summarize the resulting financial impact in the request and retain the workbook version used for the decision.

Record The Decision And Authorization

A change request should make the decision easy to record without rewriting the document. Avoid an ending that says “please confirm.” Give the decision-maker options.

Use a decision block:

Example authorization wording:

Authorized decision: Approved with conditions. Implementation interviews may be added only if the client provides interview availability by [date]. If scheduling slips, the team will proceed with the original report date and mark the issue as unverified.

This wording solves a real delivery problem. It prevents a conditional “yes” from becoming an unlimited promise.

Decision analysis: if the client approves extra interviews but refuses the fee increase, the team has not approved the same change. The next version should either reduce scope, consume an agreed contingency, or record a commercial exception. Do not hide the mismatch by writing “approved” and hoping finance catches up later.

Use Evidence Without Overloading The Form

The change request should cite enough evidence to support the decision. It should not become a filing cabinet.

For the consulting scenario, attach or reference:

• Approved project brief version and date
• Interview plan showing the original participant group
• Discovery notes or decision log entries that triggered the request
• Fee estimate or delivery-plan update

The Department of the Interior’s acquisition guidance for advisory and assistance services asks whether statements of work describe deliverables or require progress reporting where contractor recommendations may influence agency decisions (DIAR 1437.1). In a private consulting change request, the same discipline means connecting added work to the recommendation or decision it affects.

Keep evidence labels neutral:

Evidence reference: Interview notes from operations and support identify handoff delays. These notes support further validation; they do not yet prove implementation is the sole cause.

That sentence protects the integrity of the recommendations report. It also reduces pressure on the change request to sound more certain than the project record supports.

Keep Approval Connected To The Baseline

The most common failure is not a badly written request. It is an approved request that never updates the working documents.

After approval, update:

Worked example: the client approves four added interviews but keeps the final presentation date. The delivery lead updates the plan to show one combined review instead of two separate review cycles. The status report says the report date is unchanged because the client accepted a compressed review path. Without that note, the team may later be blamed for not offering two rounds.

Second worked example: the client rejects the additional interviews. The report can still mention handoff risk, but it should say the finding is based on existing interviews and has not been validated with implementation managers. That is not a failure. It is an honest record of the approved scope.

The consulting change request template gives you an editable Word structure for reason, impact, options, decision and authorization. Use it as a working record, then adapt the approval route to your contract, organization and jurisdiction.