# 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*.

<!--
Guidance: How to use this template
- Use this for changes to the scope, schedule, cost or quality baselines of the
  project. Operational IT changes to live services belong in the IT change process.
- Copy section 2 once per change request; keep sections 4 to 6 as the running log.
- Analyse impact on every dimension, even when the answer is "none". Hidden impacts
  are the main reason changes later go wrong.
- A change is not approved until the decision is recorded and baselines are updated.
-->

| 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

<!-- Guidance: Summarise the thresholds from the project management plan so requesters know who decides. -->

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

<!-- Guidance: Describe the change and why it is needed before discussing solutions. Justification should link to objectives, regulation or a real problem. -->

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

<!-- Guidance: Record the decision, any conditions and who decided. A decision without conditions and actions is incomplete. -->

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

<!-- Guidance: One row per change request, open or closed. This log is the audit trail for baseline changes. -->

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

<!-- Guidance: Track the total effect of approved changes against the original baseline, so the steering committee can see drift. -->

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

<!-- Guidance: Show the process so requesters know what happens after they submit. -->

Change requests move through the following steps.

```mermaid
flowchart TD
  A["Change raised"] --> B["Logged by PM"]
  B --> C["Impact analysis"]
  C --> D{"Within PM tolerance?"}
  D -->|Yes| E["PM decides"]
  D -->|No| F{"Within sponsor tolerance?"}
  F -->|Yes| G["Sponsor decides"]
  F -->|No| H["CCB decides"]
  E --> I{"Approved?"}
  G --> I
  H --> I
  I -->|Yes| J["Update baselines and plans"]
  I -->|No| K["Close and inform requester"]
  J --> L["Implement and verify"]
  L --> M["Close CR"]
```

## 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.