Project delivery
Change request form
Description, justification, impact assessed across scope, schedule, cost, quality and risk, the options considered, a recommendation, and a decision block naming who is entitled to decide.
What it is
A change request form exists so that a baseline changes by decision rather than by accumulation. Without one, scope arrives in conversations, the plan is quietly adjusted, and by month six nobody can say what was originally agreed or who approved the difference.
The five impact fields are the template. A request that estimates only effort is what lets schedule damage arrive unnoticed, because effort is the field people fill in and schedule, quality and risk are where the cost usually sits. Assessing all five takes a few hours and is the whole value of the process.
The part most often skipped is options. A change request is rarely a yes or no. Setting out do it now, do it later, do a reduced version and do nothing turns an approval into a choice, and the reduced version is frequently what the requester actually wanted.
When to use it
- Somebody has asked for something that was not in the agreed scope.
- The plan has drifted from the baseline and nobody can point to when or why.
- A change was approved and the baseline was never reset, so the project now reports as failing.
- Requests keep arriving informally and being absorbed by the team.
What is in it
- What is being asked for
- Why
- Impact assessment
- Options considered
- Recommendation
- Decision
- How to use this
The template
Reference. CR-014
Raised by. Name, role
Date raised. Date
Project. Project name
What is being asked for
One paragraph in plain language. What would change, stated so that somebody who has not been in the discussion understands it.
Operations have asked that the exception queue support bulk reassignment, so a supervisor can move a batch of breaks to another analyst in one action rather than reassigning them one at a time.
Why
The reason, and what happens if it is not done. A request with no stated consequence of refusal is a preference, and preferences should not consume a change process.
Volume forecasts put the queue at around four hundred exceptions a day. At current handling rates a supervisor would spend roughly forty minutes a day on reassignment alone. Without it, the team either accepts the overhead permanently or works around it with a spreadsheet, which puts break handling outside the audited system.
Impact assessment
Assess all five. A change request that only estimates effort is what lets schedule damage arrive unnoticed, because effort is the field people fill in and the others are where the cost usually is.
| Dimension | Impact | Detail |
|---|---|---|
| Scope | Addition | One new capability in the exception queue. No existing scope removed |
| Schedule | 9 working days | 6 days build and test, 3 days regression on the queue. Sits on the critical path because the queue is the last component before certification |
| Cost | 14000 | 9 days at blended rate, plus 2 days of business analysis already spent assessing this |
| Quality | Neutral | Adds a path through the queue that needs its own tests. Definition of done unchanged |
| Risk | Increases | Certification is booked for 6 March against the current forecast. A 9 day slip puts the booking at risk, and the acquirer's next slot is 4 weeks later |
Options considered
Rarely one. State them, so the decision is a choice rather than a yes or no.
- Do it now. Nine days, and the certification slot is at risk.
- Do it after go live. No effect on certification. Operations carry the manual overhead for roughly two months.
- Do a reduced version now. Reassign a filtered view rather than an arbitrary selection. Three days, meets most of the need, and the filtered view is what supervisors described using anyway.
- Do nothing. The workaround puts break handling in a spreadsheet, which the compliance position does not support.
Recommendation
The project manager's view with reasoning, so the board has something to accept or reject rather than a blank page.
Option 3. It delivers the substance of what was asked for inside the float available, and it keeps the certification booking. Option 1 buys a feature nobody has described using at the price of a four week delay.
Decision
| Field | Entry |
|---|---|
| Decision | Approved, rejected, deferred, or approved as amended |
| Decided by | Name and role of whoever holds the authority for a change of this size |
| Date | |
| Conditions | Anything attached to the approval |
| Baseline effect | Which baselines are reset and to what |
How to use this
Assess before deciding, not after. The five impact fields take a few hours and they are the whole value of the process. A board asked to approve a change with only an effort estimate is being asked to approve something nobody has understood.
An approved change resets the baseline, and that is the point. Once approved, the schedule, budget and scope baselines move to include it, and performance afterwards is measured against the new ones. A project that approves changes without moving the baseline reports itself as failing against a plan that no longer exists.
Match the authority to the size. Most changes should not reach a board. Set a tolerance in the charter below which the project manager decides, and route only what exceeds it. A process that sends every request to a monthly board produces five week decision latency and teaches people to bypass it.
Reject properly. A rejected request gets the same record as an approved one, with the reasoning. Otherwise the same request returns in three months with a different sponsor and nobody remembers why it was declined.
Keep the reference. Change requests are the audit trail for why the project is not what was originally authorised. A charter, a set of baselines and a numbered sequence of change requests explains the whole of it.
Questions people ask
- Should every change go through this?
- No. Set a tolerance in the charter below which the project manager decides. A process that sends every request to a monthly board produces five week decision latency and teaches people to bypass it.
- What happens to the baseline when a change is approved?
- It moves to include the change, and performance afterwards is measured against the new one. A project that approves changes without resetting baselines reports itself as failing against a plan that no longer exists.
- Do rejected requests need the same record?
- Yes, with the reasoning. Otherwise the same request returns in three months with a different sponsor and nobody remembers why it was declined.