Change Request Checklist for Reviewing Scope, Schedule and Cost

A change request checklist helps reviewers avoid approving half a change. The request may describe the new work but forget the cost. It may price the work but forget acceptance criteria. It may mention schedule but not who is authorized to approve.

Use this scenario: during a consulting strategy review, the client asks the team to add competitor interviews. The current SOW includes internal interviews, document review and a recommendations report. Competitor interviews may be valuable, but they change effort, risk, evidence and timing.

Official templates show the recurring pattern. The SSA archived change request template asks for scope, cost, schedule, rationale, impact on approved baseline and approvals SSA change request template. CA-PMF says consistent change information helps approvers make better project-wide decisions CA-PMF templates.

Reason for change

Checklist questions:

• Does the request identify the approved baseline by date or version?
• Does it explain the business reason, not just the desired task?
• Does it state the consequence of not changing?
• Does it identify the requester and date?

Draft language:

The approved SOW dated [date] includes internal stakeholder interviews only. The sponsor requests competitor interviews because the recommendation will be reviewed against external positioning at the [meeting]. If the change is not approved, the report will rely on internal evidence and publicly available materials only.

Annotation: the final sentence makes the no-change option real.

Scope impact

Checklist questions:

• What work is added?
• What work is removed or replaced?
• What deliverables change?
• What evidence or access is needed?
• What remains excluded?

Draft scope table:

If the work creates confidentiality, consent or legal questions, route those before approval. Do not make the project manager guess.

Schedule and cost implications

Checklist questions:

• Does the request show current and proposed dates?
• Does it identify milestones affected downstream?
• Does it state fee, expenses and tax treatment where relevant?
• Are estimates labeled as estimates?
• Does approval expire if delayed?

Draft language:

Schedule impact is [number] working days if approval is received by [date]. Fee impact is [amount], based on up to [number] calls and one appendix. If approval is received later, the team will confirm revised dates before starting.

Decision and authorization

Checklist questions:

• Who can approve, reject or defer?
• Is the decision recorded with date and conditions?
• Does the change update the baseline?
• Have affected stakeholders been notified?
• Are rejected/deferred requests retained?

Draft approval block:

Decision: approved / rejected / deferred. Conditions: [conditions]. Approved by: [name/title]. Date: [date]. Baseline documents updated: SOW v[version], project plan v[version], decision log entry [number].

A change is not complete when someone says yes. It is complete when the new baseline is visible to the people doing the work.

Red flags that should stop approval

Pause the request if it says "no schedule impact" but adds work, if fee impact is blank, if the approver is a user without commercial authority, if acceptance criteria are unchanged despite new deliverables, or if dependencies are outside the project team's control.

Also pause if the change request tries to rewrite legal terms, data handling, liability, confidentiality or regulated obligations without the appropriate reviewer for the jurisdiction.

Checklist in action: competitor interviews

Suppose the request says, "Add competitor interviews so the recommendation is more market-informed." The phrase sounds reasonable, but the checklist should slow it down until the work is concrete.

First pass result:

The revised request could say:

Add up to five external interviews with named market contacts supplied by the client. Consultant will prepare the discussion guide, conduct 30-minute calls, summarize themes and add a two-page external-evidence appendix. Raw notes will be stored in [location] and will not be included in the main report. If fewer than three contacts accept by [date], consultant will use publicly available source review instead and no appendix will be produced.

This version gives reviewers something to test. "Competitor interviews" becomes a bounded method, a deliverable and a fallback route. It also exposes the competing choices: richer primary evidence versus schedule certainty.

The checklist should then force a recommendation:

Approve the external interviews only if the sponsor can provide contacts by [date]. Otherwise keep the baseline and add a public-source positioning note to the existing report.

That recommendation follows from the dependency. The consulting team cannot promise interviews without contact access, and the sponsor should not pay for a delay caused by an uncertain outreach list. If contacts are ready, the change may improve the recommendation. If they are not, the checklist points to a smaller evidence update that stays closer to the current plan.

The same example also shows why a checklist needs separate rows for deliverable and evidence. The main deliverable may still be called "recommendations report," but the work behind it changes. Add two review questions:

• Will the report include a new appendix, source note or limitation statement?
• Who decides whether external interviews are sufficient to influence the recommendation?

For this request, the answer might be:

The report will include a two-page external-evidence appendix if at least three interviews are completed by [date]. If fewer than three interviews are completed, the report will include a limitation note and rely on public-source review for external positioning. Sponsor will decide whether the evidence is sufficient for the executive discussion.

That is better than pretending every attempted interview produces equal evidence. It gives the reviewer a threshold and a fallback. It also stops a thin set of calls from carrying more weight than it deserves.

Now test the schedule line again. "No impact" still does not survive:

Proposed schedule impact is three working days if client supplies contacts by [date]. If contact supply is later, the report date moves one working day for each working day of delay, up to a maximum hold of [number] days before the fallback public-source review is used.

This is specific enough for the sponsor to manage. They can reduce delay by supplying contacts, approve the fallback or decide the external input is worth moving the report.

If the request names competitors directly, the checklist should also ask whether those names belong in the change request or in a restricted working note. The approval record needs the method and impact; the outreach list may have a narrower audience.

Finally, the checklist should capture the communication path after the decision:

If approved, [project manager] updates the project plan and tells interviewers, report reviewers and the finance contact by [date]. If rejected, [engagement lead] adds the public-source positioning note to the existing report outline.

The rejected path matters. It prevents the team from continuing to pursue external interviews informally after the change has been declined.

Start from an editable Word draft

Use the consulting change request template as the review record for baseline, impact, options and the final decision on the requested change.