Free Change Request Form Template — Word Download

01 — Form Sections

What's in the Form — All 7 Sections

The template is structured so that a change request can be submitted by any stakeholder but assessed in a consistent, repeatable way. Each section captures information needed at a different stage of the change control process.

Header / Identification

Unique CR number, date raised, who raised it, the project name, PM and priority level. The CR number links this form to the change register entry.

CR Number Date Raised Raised By Priority

Change Description

A clear, specific description of what is being changed, added or removed. Guidance in the template prompts the requester to describe the change precisely — not just name it.

What changes What is added / removed

Business Justification

Why is this change needed? What risk, issue, opportunity or requirement is driving it? The justification must make the case for why the project is better off making this change than not.

Driver Risk if not approved

Impact Analysis Most Critical

Six separate impact fields — one per baseline. This is integrated change control: every baseline must be assessed even if the change seems to affect only one area. The schedule and cost fields include prompts for quantified values, not just qualitative statements.

Scope Schedule (+/- days) Cost (+/- $) Quality Resources Risk

Options Considered

Three option slots: implement as described, an alternative approach, and do nothing. Each option shows its impact so the CCB can compare genuinely. Do nothing is always an option.

Option A — Implement Option B — Alternative Option C — Do Nothing

PM Recommendation

The PM's recommended course of action with rationale. This is not the decision — that is for the CCB. But a clear PM recommendation anchors the discussion and makes it harder to approve a poor change without justification.

Recommended option Rationale

CCB Decision & Implementation

The formal CCB decision (Approve / Reject / Defer / More Info), any conditions attached, decision date, CCB chair signature, implementation owner, planned implementation date and date closed.

Decision Conditions Signature Implementation date Date closed

02 — Impact Analysis

The Impact Analysis Section — Getting It Right

Section 4 is the most critical and most frequently done poorly. A good impact analysis assesses every baseline — not just the obvious one. A scope change that looks simple on the surface often has cascading effects on schedule, cost and risk that only become visible when you look deliberately.

🎯

Scope Impact

What deliverables, features or requirements are being added, modified or removed? Update the scope baseline and WBS if approved.

"Adds 3 new API endpoints to the integration layer. WBS elements 1.3.2 and 1.3.3 to be updated."

📅

Schedule Impact

Express as +/- days to the nearest milestone and to the project end date. If the critical path is affected, say so explicitly.

"+ 8 days to milestone M3 (System Testing). No impact on project end date — absorbed within existing float on the integration path."

💰

Cost Impact

Express as +/- $ with a breakdown. Show your assumptions. "Approximately $12,000" is not enough — "3 developer days × $450/day + $2,000 testing = $3,350" is.

"+ $3,350 (3 dev days × $450 + $2,000 QA). Within contingency reserve — no budget increase required."

⭐

Quality Impact

Does the change affect any quality standards, acceptance criteria or testing requirements? Does it introduce technical debt?

"No change to acceptance criteria. Additional regression testing required — covered in the cost estimate above."

👥

Resource Impact

Does the change require additional or different resources? Does it affect team members already committed to other work?

"Requires the lead integration developer for 3 days — currently allocated to CR-012. Sequencing with CR-012 to be confirmed."

⚠️

Risk Impact

Does the change introduce new risks, increase existing risks or reduce them? If new risks are introduced, add them to the risk register.

"Increases integration complexity — adds new risk RK-018 (integration failure at go-live). Mitigation: additional integration test cycle."

💡

The most skipped field: Risk impact is the most commonly left blank in change request forms. PMs often focus on the tangible cost and schedule impacts and skip the risk column. This is a mistake — many changes that look cost-neutral or schedule-neutral introduce significant risk to delivery that only surfaces later. The risk register should be updated every time a change is approved.

03 — CCB Decisions

The Four CCB Decision Outcomes

Section 7 of the template includes all four decision outcomes a CCB can reach. Each has different follow-on actions that the PM must take — the template includes fields for all of them.

✅

Approved

Change is authorised. Update all affected baselines, notify stakeholders, assign implementation owner and set a target date.

❌

Rejected

Change will not proceed. Record the reason. Close the CR in the register. Notify the requester with the rationale.

⏸

Deferred

Decision postponed to a later date — often for budget cycle reasons or dependency resolution. Set a review date.

❓

More Info

CCB cannot decide without additional data. Specify exactly what is needed, who will provide it and by when.

Writing a Strong Change Description

The quality of the change description in Section 2 determines whether the CCB can make a quick, confident decision or has to ask for more information. Here is the difference between a weak and a strong description:

❌ Weak description

"The client wants to add some reporting functionality to the dashboard. This will require development work and may affect the timeline."

Vague. "Some reporting functionality" could mean 2 hours or 2 weeks of work. "May affect the timeline" is not an impact assessment. The CCB cannot approve or reject this.

✅ Strong description

"Add a PDF export button to the Executive Summary dashboard report. On click, the report renders as a 2-page A4 PDF including all charts. Triggered by CR-021 from the client review meeting on 14 March."

Specific. The CCB knows exactly what is being added, in what form, and why. Impact analysis can now be completed accurately against this description.

04 — Best Practice

Setting Up a CR Numbering System

A consistent CR numbering system makes the change register easy to navigate and audit. The template uses CR-XXX format (CR-001, CR-002 etc.) — a simple sequential number that works for any project size. For larger programmes with multiple work streams, consider a prefix that identifies the stream: INT-CR-001 (integration stream), MIG-CR-001 (migration stream) etc.

What to Number and What Not to

Number every change request from the moment it is formally submitted — even if the PM has already decided informally that it will be approved. The CR number is the audit trail. If a dispute arises later about whether a change was properly authorised, the CR number links the decision in the register to the signed form in the document repository.

Do not number informal queries, stakeholder questions or exploratory discussions. Only formal submissions on the Change Request Form get a CR number. This distinction keeps the register clean and the process credible.

📌

PMP exam note: In the PMI framework, a change request can be corrective, preventive, defect repair or an update to project documents or baselines. The PMP exam tests whether you know that even corrective and preventive actions must go through the Perform Integrated Change Control process — they are not informal PM decisions. See our 200 PMP practice questions for scenario questions on change control.

05 — FAQ

Change Request Form — 4 Common Questions

A change request is a formal proposal to modify any aspect of a project — its scope, schedule, cost, quality standards or project documents. Change requests can be initiated by any stakeholder but must go through the project's change control process before being actioned. They may be approved, rejected or deferred by the Change Control Board. In PMI frameworks, raising a change request is the correct response to nearly any situation that would alter the project baseline — including corrective actions, preventive actions and defect repairs.

A complete change request form should include: a unique CR number and date; the change description; the business justification; impact analysis covering scope, schedule, cost, quality, resources and risk; options considered (including do nothing); the PM's recommendation; and the CCB's decision with rationale, decision date and authorising signature. The impact analysis section is the most critical — every baseline must be assessed even if the change appears to affect only one area.

A change management plan defines the process — how changes will be raised, assessed, approved and implemented on the project. A change request form is the document used to raise and document an individual change through that process. The change management plan is the rulebook; the change request form is the individual submission. Every project has one change management plan but will have many change request forms throughout its lifecycle.

It depends on the change management plan's approval thresholds. For minor changes within the PM's defined authority — typically small schedule adjustments or costs under an agreed threshold (e.g. under $5,000 and under 3 days schedule impact) — the PM can approve and log the change without a CCB meeting. For anything above the PM's authority, the change must go to the CCB or higher. A PM should never unilaterally approve a change that materially affects scope, budget or the business case — that undermines project governance and creates personal accountability risk.

Free Change Request Form Template Word Download