Change Request and Change Log Template

Project change request with impact on scope, schedule, cost, quality and risk, options, CCB decision record, change log and flow

프로젝트 관리표준change control업데이트됨 2026. 10. 20.

에디터에서 열기.md 다운로드

사용법: Use whenever a change to an approved project baseline is proposed. Fill the description and justification first, then assess every impact dimension. Main pitfall: approving a change without updating the baselines and plans it affects.

미리보기

Change Request and Change Log: [Project name]

Change request form for proposing a change to an approved project baseline, with impact analysis, options and a recommendation, plus the change control board (CCB) decision record, the change log and the change flow. Based on common project management practice. Replace every [bracketed] value and every row marked Example.

Field	Value
Document ID	[CC-PROJECT-001]
Project	[Project name]
Change manager	[@project-manager]
Change control board	[Sponsor (chair), finance, architecture, operations representative]
Version	[0.1]
Last updated	YYYY-MM-DD

1. Change control rules

Any stakeholder may raise a change request. The project manager logs it within [2] working days, completes the impact analysis within [5] working days and routes it for decision using these thresholds.

Category	Threshold	Decision by	Target decision time
Minor	Cost under [5,000 EUR], schedule under [5] days, no scope reduction, no benefit impact	Project manager	3 working days
Significant	Cost under [25,000 EUR], schedule under [10] days	Sponsor	5 working days
Major	Above sponsor tolerance, changes objectives or benefits	Change control board	Next CCB or extraordinary session
Emergency	Needed to prevent immediate harm or a hard deadline miss	Sponsor, ratified by CCB	1 working day

2. Change request form

Complete one form per change request.

Field	Value
CR ID	[CR-007]
Title	Example: Add accessibility audit before UAT
Raised by	[@name], [role]
Date raised	YYYY-MM-DD
Category	[Minor / Significant / Major / Emergency]
Baselines affected	[Scope / Schedule / Cost / Quality]
Priority	[High / Medium / Low]
Related items	[RSK-014, requirement REQ-NFR-012]

2.1 Description of the change

[What exactly would change: deliverables, requirements, dates or budget lines.]

Example: Add an external accessibility audit of the onboarding front end against WCAG 2.2 AA, followed by remediation, before user acceptance testing starts.

2.2 Justification

[Why the change is needed and what happens if it is not made.]

Example: The legal team confirmed that the service falls under the national accessibility regulation from YYYY-MM-DD. Without an audit the bank cannot publish the required accessibility statement, and a later fix would cost about three times as much.

2.3 Impact analysis

Assess every dimension; write "None" where there is no impact.

Dimension	Impact	Detail
Scope	Example: Added	New work package 1.3.4 Accessibility audit and remediation
Schedule	Example: +5 working days	UAT start moves; go-live protected by buffer (buffer use rises from 40% to 90%)
Cost	Example: +18,000 EUR	Audit 8,000 EUR, remediation 10,000 EUR
Quality	Example: Improved	Accessibility defects found before release
Risk	Example: Reduces RSK-014; buffer exhaustion raises schedule risk	Residual score 4 for RSK-014
Resources	Example: +1 front-end developer for 2 weeks	From vendor
Benefits	Example: None negative	Supports adoption by users of assistive technologies
Other projects	[Impact]	[Detail]

2.4 Options

Option	Description	Cost	Schedule	Main risk
A	Example: Do nothing	0	0	Regulatory non-compliance at go-live
B	Example: Full audit and remediation before UAT	18,000 EUR	+5 days	Buffer nearly exhausted
C	Example: Audit before UAT, remediation in hypercare	18,000 EUR	+2 days	Release with known accessibility defects

2.5 Recommendation

[Recommended option and reasoning, including funding source.]

Example: Option B, funded from contingency. It is the only option that meets the regulation at go-live; the schedule impact stays inside the project buffer.

3. CCB decision record

The decision on each change request is recorded here.

Field	Value
CR ID	[CR-007]
Decision forum	[CCB / Sponsor / Project manager]
Decision date	YYYY-MM-DD
Decision	[Approved / Approved with conditions / Rejected / Deferred / More information needed]
Option chosen	[B]
Conditions	Example: Audit vendor must be on the approved supplier list; report to CCB if remediation exceeds 10,000 EUR
Funding source	[Contingency reserve]
Decided by	[@sponsor, @finance, @architect]
Baselines to update	[WBS v1.2, schedule v1.3, cost baseline v1.1]
Communicated to	[Project team, vendor, steering committee]

4. Change log

All change requests are tracked in the log.

CR ID	Title	Raised	Category	Cost impact	Schedule impact	Decision	Decision date	Implemented	Status
CR-005	Example: Add Spanish language to forms	YYYY-MM-DD	Significant	+12,000 EUR	+0 days	Rejected	YYYY-MM-DD	n/a	Closed
CR-006	Example: Move training delivery one week earlier	YYYY-MM-DD	Minor	0	0	Approved	YYYY-MM-DD	YYYY-MM-DD	Closed
CR-007	Example: Accessibility audit before UAT	YYYY-MM-DD	Significant	+18,000 EUR	+5 days	Approved with conditions	YYYY-MM-DD		In progress
[CR-nnn]	[Title]	YYYY-MM-DD	[Category]	[Cost]	[Days]	[Decision]	YYYY-MM-DD	YYYY-MM-DD	[Status]

5. Cumulative change impact

The cumulative effect of approved changes is:

Measure	Original baseline	Approved changes	Current baseline
Budget	Example: 435,000 EUR	+18,000 EUR	453,000 EUR
Go-live date	YYYY-MM-DD	+0 days (buffer used 5 days)	YYYY-MM-DD
Work packages	32	+1	33
Contingency remaining	43,500 EUR	-18,000 EUR	25,500 EUR

6. Change flow

Change requests move through the following steps.

Standard and licence note

Based on common project management practice for integrated change control and change control boards. This template is original text written for this collection. Template licence: MIT.