Change Request Log Example: Sixteen Filled-In Entries from a Billing Migration
A change request log records every request to alter agreed scope, cost or schedule, what each one was assessed to cost, who decided it and whether the baseline moved as a result. The example below holds sixteen entries from a fictional billing platform migration, covering approvals, rejections, a withdrawal and two still open.
The example
A utility replaces its customer billing platform. The log below covers roughly nine weeks, from CR-014 to CR-029, during design completion and the first migration dry runs. Two bodies make decisions: a change control board that meets fortnightly and holds authority up to an agreed threshold, and the steering committee, which takes anything above it or anything touching the go-live date.
Cost impact is the assessed figure at the point of decision, not the request. Schedule impact is stated against the critical path. All figures and entries are invented.
| Ref | Raised | Raised by | Change requested | Cost impact | Schedule impact | Decision | Decided by | Baseline updated |
|---|---|---|---|---|---|---|---|---|
| CR-014 | 04 Feb | Billing Operations Manager | Add re-presentation rule for failed direct debits | +18,400 | +5 days to UAT | Approved | Change board, 11 Feb | Yes, plan v4 |
| CR-015 | 06 Feb | Vendor | Replace nightly batch export with API for meter reads | 0, inside contract | None | Approved | Delivery Manager, 07 Feb | No, design only |
| CR-016 | 11 Feb | Finance | Second VAT rate for commercial accounts | +6,200 | None | Approved | Change board, 18 Feb | Yes, scope register |
| CR-017 | 12 Feb | Customer Services | New call handling screen in the agent console | +31,000 | +3 weeks | Rejected, deferred to phase 2 | Change board, 18 Feb | No |
| CR-018 | 19 Feb | Data Lead | Extend history migration from 3 years to 7 | +44,000 | +2 weeks to dry run 2 | Approved with condition | SteerCo, 04 Mar | Yes, plan v5 |
| CR-019 | 21 Feb | Information Security | Multi-factor authentication on the agent console | +9,800 | None | Approved | Change board, 25 Feb | Yes, scope register |
| CR-020 | 26 Feb | Billing Operations Manager | Add usage graph to the printed bill layout | +12,500 | +4 days | Withdrawn by raiser | — | No |
| CR-021 | 03 Mar | Programme Manager | Move go-live from 12 Apr to 10 May | +61,000 run rate | +4 weeks | Approved | SteerCo, 04 Mar | Yes, baseline v2 |
| CR-022 | 05 Mar | Vendor | Use incumbent payment gateway instead of proposed | −7,000 | None | Approved | Change board, 11 Mar | Yes, cost plan |
| CR-023 | 09 Mar | Regulatory Reporting Lead | New complaints reporting field set | +14,000 | +1 week | Approved, mandatory | Change board, 11 Mar | Yes, plan v6 |
| CR-024 | 12 Mar | Test Lead | Add a third migration dry run before cutover | +23,000 | +1 week | Open, assessment due 25 Mar | — | No |
| CR-025 | 16 Mar | Marketing | Apply new brand colours to bill templates | +4,100 | None | Rejected | Change board, 25 Mar | No |
| CR-026 | 18 Mar | IT Operations | Move hosting region to meet data residency requirement | +28,000 | +2 weeks | Approved | SteerCo, 01 Apr | Yes, baseline v3 |
| CR-027 | 23 Mar | Billing Operations Manager | Remove paper bill suppression from scope | −11,000 | −3 days | Approved | Change board, 25 Mar | Yes, scope register |
| CR-028 | 27 Mar | Vendor | Extend hypercare from 4 weeks to 6 | +19,600 | None | Open, awaiting funding decision | — | No |
| CR-029 | 02 Apr | Data Lead | Accept 0.5% reconciliation tolerance on closed accounts | 0 | None | Approved | Change board, 08 Apr | Yes, sign-off criteria |
Reading the example
Reference and date raised
Sequential references with no gaps, and the log starts at CR-001 rather than at the first change anyone thought was significant. The date raised is separate from the date decided, and the distance between them is the most useful unintended measurement in the log: CR-018 took thirteen days, CR-026 took fourteen, and CR-024 is still open after nearly a fortnight.
Raised by
A role, and in this log they come from everywhere: operations, finance, security, regulation, the vendor, the test team, marketing. Two entries were raised by the delivery team against itself — CR-024 asking for another dry run and CR-021 moving the date — which is the honest use of a change log rather than a defensive one.
Cost and schedule impact
Both columns are filled for every entry, including the ones that were rejected and the one that was withdrawn. Three entries are negative or zero: a cheaper gateway, a descoped feature and a tolerance change that costs nothing but alters what sign-off means. CR-021 shows a cost with no build attached to it, since four extra weeks of a running programme is spend even when nothing is being built.
Decision and decided by
The decision text is more than yes or no. CR-017 is a rejection with a destination, CR-018 is approved with a condition, CR-023 is approved and marked mandatory, and CR-020 was withdrawn before it reached a board. Recording who decided matters as much as what was decided — the split between the change board and the SteerCo here is visible in the column, and it matches the thresholds agreed at the start. Where those decisions get presented, the decision log and the change log carry the same references.
Baseline updated
The column that most logs are missing, and the one that makes the rest of it true. An approval that never reaches the plan, the cost model or the scope register produces a project delivering against a baseline nobody agreed to. Here the plan moved through versions 4, 5 and 6, and the baseline itself through v2 and v3 — one for the date change, one for the hosting move. Two approved entries correctly show no baseline change, because neither altered scope, cost or dates. The Change Request Log keeps the field for exactly this check.
What this example leaves out
It holds no impact assessments. Each row summarises a figure that took someone half a day to produce — which components change, what has to be retested, what the vendor quoted. The assessment lives with the request; the log carries only its conclusion.
It does not show cumulative effect. Sixteen entries here add roughly 175,000 of approved cost and seven weeks of schedule, and no single row makes that visible. Running totals against the approved budget and the baselined dates belong in the plan and the status report, drawing on this log rather than duplicating it.
It says nothing about why requests appear. Six of these sixteen would have been avoided by a firmer requirements phase, and one by reading a regulation earlier. That analysis is a lessons learned exercise, not a log column.
And it does not make the decision. The log presents scope, cost and schedule impact side by side so the board is choosing between known positions rather than nodding at a description; who may approve what, and at which threshold, is set by the governance structure before the first request arrives.
Questions
Should rejected change requests stay in the log?
Yes. A log of approvals only cannot show what was considered, and rejected entries are frequently re-raised later — CR-017 here was deferred to a second phase, which is a decision someone will want evidence of.
What is the difference between a change request and a defect?
A defect is the solution not doing what was agreed; a change request alters what was agreed. Logging defects as changes inflates the change log and lets scope gaps hide as bugs, and the reverse hides real scope growth.
Who approves a change request?
Whoever holds the threshold it crosses. Small changes usually sit with a change board or the delivery manager; anything moving the go-live date, the budget envelope or contractual scope typically goes to the steering committee.
When should the baseline be updated?
When an approved change alters scope, cost or dates. Approvals that change design without moving any of the three are recorded as decided but leave the baseline alone, which is why the log carries the field explicitly.