Change Request¶
At a glance
- Purpose: Record a proposed change to an agreed baseline, force its impact to be estimated, and give one named person the authority to accept or reject it.
- Use it when: Anyone asks for something that alters scope, schedule, cost, or quality after the baseline is agreed. Discussing it informally instead is how baselines quietly stop meaning anything.
- Owner: The project manager assesses and records; the sponsor or change authority approves within agreed limits.
- Related: Module 11 · Lab 19
- Spreadsheet version:
csv/change-log.csv
How to use this template¶
- Log first, discuss second. Giving the request an ID and a date means it cannot be absorbed silently, and it creates the audit trail that configuration management requires.
- Require an impact assessment before a decision: effect on scope, schedule, cost, quality, risk, and on other in-flight work. "It's small" is contradicted by the assessment or unnecessary to say.
- Put the change against the untouched baseline in the same units. Comparing a change against an already-overrunning plan makes every change look free.
- Record the decision, the reason, and the authority — including rejections and deferrals. A rejected request with a reason is a valuable artefact; an untracked one will be raised again.
- Present options, not a single price: do it now, do it later, do less, do something else instead. The value of the process is the comparison, not the arithmetic.
Field descriptions¶
| Field | What goes in it | Watch out for |
|---|---|---|
| Change ID | Stable reference (CR-007) | Free-text change descriptions in email |
| Requester and date | Who asked, and when | Requests attributed to a department |
| Description | What is being changed | The reason smuggled in as justification |
| Reason | The need, with any evidence | "Management wants it" |
| Type | Scope, schedule, cost, quality, technical, or regulatory | Changes that are really defect fixes |
| Impact — scope | Requirements added, changed, or removed | Impact left to the reader to infer |
| Impact — schedule | Days or dates, and whether critical-path work is touched | Unsigned schedules |
| Impact — cost | Money, at the same rates as the baseline | Rates invented for the occasion |
| Impact — risk and quality | New risks, testing consequences | Registering only the benefit |
| Options | Do now / later / reduce / alternative, with costs | One option presented as the only choice |
| Recommendation | The project manager's view and reason | No recommendation, leaving the sponsor to guess |
| Decision | Approved, rejected, deferred, and by whom | "Approved" with no authority named |
| Baseline update | What changed, when, and by whose authority | Changes never reflected in the baseline |
Blank template¶
# Change Request — CR-[nnn]
| | |
| --- | --- |
| **Raised by** | [Requester, role] |
| **Date raised** | [YYYY-MM-DD] |
| **Baseline affected** | [Scope / schedule / budget / all, with version references] |
| **Type** | [Scope / schedule / cost / quality / technical / regulatory] |
| **Current status** | [Submitted / assessed / decided / implemented / closed] |
## 1. Description of the change
[What is being changed, described precisely enough that an independent reader could implement it.]
## 2. Reason
[Why it is needed, and any evidence. State whether the need is new information, a correction of an
earlier assumption, a defect, or a preference.]
## 3. Impact assessment
| Dimension | Impact | Basis |
| --- | --- | --- |
| Scope | [Requirements added, changed, or removed, by ID] | [Requirements list] |
| Schedule | [Days, dates, and whether critical-path work is affected] | [Schedule version] |
| Cost | [Amount, in the baseline's currency and rates] | [Estimation basis] |
| Quality and testing | [Additional or reduced testing needs] | [Quality plan] |
| Risk | [New risks, and their exposure] | [Risk register entry] |
| Other work affected | [Dependencies, other projects, support] | [Dependency note] |
## 4. Options considered
| Option | Cost | Schedule effect | Benefit | Risk |
| --- | --- | --- | --- | --- |
| A — Do it now | | | | |
| B — Do it in the next phase | | | | |
| C — Do a reduced version | | | | |
| D — Do not do it | 0 | 0 | [Value forgone] | |
| E — Do something else instead | | | | |
## 5. Recommendation
[The project manager's recommendation, with the reason. Name the option, not a preference.]
## 6. Decision
| Decision | Decided by | Date | Conditions or follow-up |
| --- | --- | --- | --- |
| [Approved / Rejected / Deferred] | [Named person and role] | [YYYY-MM-DD] | [Conditions] |
## 7. Baseline update record
| Baseline document | Version before | Version after | Date | Authority |
| --- | --- | --- | --- | --- |
Worked example¶
From Lab 19, on the admission portal — invented figures for teaching. A change request arrives in week 9:
| Dimension | Impact | Basis |
|---|---|---|
| Scope | Adds requirement FR-12: applicants may amend a submitted application before the deadline | Requirements matrix |
| Schedule | +7 working days, of which 4 fall on the critical path via the eligibility rules engine | Schedule version 1.0 |
| Cost | +[amount at the baseline day rate] for 7 person-days, plus 2 days of regression testing | Estimation basis in the business case |
| Quality | Two additional acceptance scenarios; the "immutable submission" rule must be reversed in the design | Quality plan |
| Risk | New risk: amendment history becomes an audit question, which the records office has not answered | New register row, exposure 2 × 3 = 6 |
| Option | Cost | Schedule | Benefit | Risk |
|---|---|---|---|---|
| A — Do it now | 9 person-days | +7 days | Meets the applicant need before the window | Audit question unresolved |
| B — Next release | 8 person-days | 0 | Same benefit, after the admission window — effectively useless here | Low |
| C — Reduced: amend only before submission is acknowledged | 4 person-days | +2 days | Covers the common mistake case | Low |
| D — Do not do it | 0 | 0 | Applicants must contact the office to correct details | Support load rises |
The recommendation would be C, because the underlying need — correcting a typo — is solved by C at less than half the cost of A, while A's schedule impact lands directly on the critical path identified in Lab 10. Presenting all four options is the point: a request carrying a single price invites a yes/no decision on someone else's framing.
Common mistakes¶
- A verbal change absorbed into the work. By the time it is measured, the baseline has already moved and no one can say what it cost.
- Impact assessed after the decision. An assessment produced to justify a predetermined answer is documentation, not analysis.
- One option, one price. No comparison means no real decision.
- Comparing against a slipped plan. Every change then looks affordable.
- Costs in different units from the baseline. Rates created for the occasion are indefensible.
- Rejections not recorded. They will return, and the reasoning will have to be reconstructed.
- Confusing defects with changes. A defect against an agreed requirement is fixed through the defect process; a change to the requirement is a change request. Mixing them hides quality problems inside scope growth.
- Baseline left stale. An approved change that never reaches the baseline documents reappears as an unexplained variance later.