22.2 What a Change Request Must Capture
Key Takeaways
- A change request records a unique reference and date, who raised it, the description, the justification, priority, affected configuration items, assessed impact, options, recommendation, the decision and decision maker, and implementation status.
- A request that states what is wanted without stating why cannot be evaluated, because there is nothing to weigh the cost against.
- The decision record — who authorised what and when — is what allows the project to explain later why a baseline moved.
- Assessed impact must span cost, schedule, scope, quality, risk, resources, and benefits, not cost alone.
- Rejected and deferred changes stay on the log with their reasons, which prevents re-raising, manages expectations, and preserves the analysis if circumstances change.
Outcome 24b is deliberately narrow: know what should be captured and recorded in change requests. It is a knowledge outcome, which means it can be tested as a short-response "list" item as easily as in a long response — so learn the content list precisely.
From request content to controlled implementation
Section 16.1 covered the stages of change control. This section deepens what examiners test next: what goes in a change request, how to assess impact and options, how to justify approve / reject / defer, and why updating plans and communicating is part of control — not optional admin. It also links change control to requirements and configuration management so decisions stay consistent with what is actually built and recorded.
What should be captured in a change request
A change request (CR) is the controlled record of a proposed change. Poorly completed requests force guesswork; well-completed requests enable fast, fair evaluation.
| Field / content | Why it is needed |
|---|---|
| Unique ID and date raised | Traceability, ageing, and audit |
| Requester and role | Ownership of clarification; stakeholder context |
| Clear description of the proposed change | Everyone evaluates the same proposal |
| Rationale / business justification | Links to value, compliance, risk reduction, or problem solved |
| Related baseline items | Requirements IDs, WBS elements, configuration items, drawings, backlog items |
| Category / type | Scope, technical, commercial, regulatory, defect vs enhancement (as used by the organisation) |
| Priority and urgency | Supports triage; separates "nice soon" from "safety now" |
| Known constraints and deadlines | External go-live, legal dates, supplier notice periods |
| Initial estimate of impact (if known) | Starting point for evaluation — not a substitute for detailed assessment |
| Attachments / evidence | Specs, incident logs, customer feedback, regulatory notices |
| Status and decision fields | Proposed → under evaluation → approved/rejected/deferred → implemented/closed |
| Decision record | Who decided, when, conditions, and rationale |
Quality of the request
- Describe the change in outcome terms where possible ("retain personal data for seven years to meet regulation X") not only a vague solution ("make the system better").
- Separate defect correction (product does not meet baselined requirement) from enhancement (new or changed need) — both may use the process, but authority and funding treatment can differ.
- Record assumptions explicitly so detailed evaluation can test them.
Scenario A — incomplete request
A supplier emails "we recommend using valve type B." No ID, no impact on programme, no warranty comparison, no link to the baselined specification. Initial evaluation should return for completion, not invent missing facts. A complete CR would identify the configuration item, reason (availability, cost, performance), constraints, and any standards affected.
Why each field earns its place
A change request is not a form for its own sake. Each field exists because a decision maker cannot decide without it, or because someone later needs to reconstruct why the decision was taken.
| Field | Why it is needed |
|---|---|
| Unique reference and date | Allows the change to be tracked, reported, and audited through to implementation |
| Raised by | Identifies who to return to for clarification and who holds the underlying need |
| Description of the change | States precisely what is being requested, in terms that can be evaluated |
| Reason / justification | Distinguishes a genuine need from a preference, and links to benefit or obligation |
| Priority or urgency | Determines whether it can wait for the next scheduled decision point |
| Affected items / configuration items | Identifies exactly which baselined items would change |
| Assessed impact | Cost, schedule, scope, quality, risk, resources, and benefits consequences |
| Options considered | Shows the decision maker the alternatives, including doing nothing |
| Recommendation | Gives an evidence-based professional view for the authority to accept or reject |
| Decision, decision maker and date | Records who authorised what, and when — the audit trail |
| Implementation status | Confirms the change was actually made, not merely approved |
The two fields most often missing
Reason. A request that says what without saying why cannot be evaluated, because there is no way to weigh the cost against anything. "Add a second approval step" is a preference; "add a second approval step because the regulator requires segregation of duties for payments above £50,000" is a justified requirement with a clear consequence for rejecting it.
Decision record. Approving a change verbally and implementing it without recording the decision, the decision maker, and the date leaves the project unable to explain later why the baseline moved. It also breaks the link between the change and the configuration items it altered.
Recording rejections as carefully as approvals
Rejected and deferred changes must stay on the log with their reason. Three benefits follow: the same request is not re-raised repeatedly through different routes; the requester receives an explicit answer, which is expectation management; and if circumstances change, a deferred item can be reconsidered with its original analysis intact rather than re-worked from scratch.
Which set best describes content that should be captured in a change request?
A change is discussed and agreed verbally in a corridor conversation with the sponsor, and the team implements it. Three months later nobody can explain why the approved baseline differs from the original plan. Which change request content was missing?