When is a change request required? Here is the simple rule I use: if a change would move the approved baseline, it needs a change request. The baseline is the scope, schedule, budget and quality criteria the sponsor signed off. If the change fits inside that baseline and its agreed tolerance, the team just manages it. If it pushes any of them out, it goes through change control, however small it looks.
That rule protects you from the most common way programmes drift: a long run of small, reasonable requests that nobody ever added up.
What is a change request in project management?
PMI's Lexicon of Project Management Terms defines a change request as a formal proposal to modify a document, deliverable or baseline. In plain words, it is a written ask to change what was agreed, with the impact spelled out, so the right person can say yes or no.
Uncontrolled change is common. PMI's Pulse of the Profession 2018 found that 52 percent of projects completed in the previous 12 months had scope creep or uncontrolled changes to scope, up from 43 percent five years earlier. Scope creep is not usually one big decision. It is lots of small ones made without a change request.
- 52%of projects had scope creep or uncontrolled scope changes
- 43%had the same problem five years earlier
Source: PMI Pulse of the Profession, 2018
When is a change request required? The baseline test
Before you can apply the rule, you need a baseline. That means a signed scope document, a baselined plan with milestones, an approved budget and agreed acceptance criteria. Without those, every conversation about change turns into an argument about what was promised.
Raise a change request if the change would
- Add, remove or materially alter something in the signed scope
- Move a baselined milestone or the go-live date
- Spend money beyond the approved budget or draw on contingency
- Change an acceptance criterion, a quality gate or a test exit criterion
- Need people or suppliers the plan does not include
- Change a design decision already signed off by the design authority
Needs a change request
- A new interface to a system not in scope
- Adding a country to the first release
- Moving go-live by two weeks
- A fourth mock data load not in the plan or budget
Normal project management
- Swapping two tasks inside the same sprint
- Reassigning work within the agreed team
- Fixing a defect against the signed design
- Using float that does not touch a milestone
Who can request a change?
Anyone can request a change: a business user, a workstream lead, the supplier, a tester who finds a gap. Make it easy to raise. A short form with what, why and who is asking is enough to start. What matters is that every request has an owner who takes it through assessment, and a clear person who decides.
Watch for changes that arrive as defects. If the system works as designed but the business now wants it to work differently, that is a change, not a bug. Calling it a defect skips the impact assessment and lands the cost on the project without anyone approving it.
How to assess the impact: time, cost and risk
A change request without an impact assessment is just a wish. Before it goes for approval, the owner should answer three questions in numbers, not adjectives.
- Time: How many days does it add, and does it move a milestone or the critical path? Name the milestone.
- Cost: What is the extra effort, licence or supplier cost, and is it inside contingency or new money?
- Risk: What new risk does it create, and what risk does it remove? Doing nothing has a risk too.
Also say what else it touches: testing, training, data migration and cutover. A small design change late in the programme can mean retesting, rewriting training material and changing a load file. Those knock-on costs are where budgets really go. If you want the bigger picture, see why projects go over budget.
Who approves a change request?
Approval follows the tolerances you agreed. Small changes inside tolerance sit with the programme director. Larger ones go to a change board or the steering committee, with the sponsor deciding when money or dates move. PMI's lexicon describes a change control board as a formally chartered group that reviews, approves, delays or rejects changes and records those decisions.
The change request flow
- Raise
Anyone logs the request: what, why, who is asking and how urgent it is.
- Assess
The owner works out the impact on time, cost and risk, plus the knock-on effect on testing, training, data and cutover.
- Decide
The right approver for that size of change approves, rejects or defers it, with a reason on record.
- Rebaseline
If approved, update the plan, budget and scope so the new baseline is the one everyone works to.
- Tell people
Let the requester, the workstreams and the steering committee know what changed and why.
The rebaseline step is the one teams skip. If an approved change never reaches the plan and the budget, your next status report is measuring against a baseline that no longer exists. Big changes belong on the steering committee agenda, so read how to make a steering committee decide too.
Managing change requests in ProjectCAPEX
In ProjectCAPEX, change requests live in the programme alongside the plan, budget and RAID log. Each one records its type, such as scope, timeline or budget change, plus its priority, workstream, budget impact, timeline impact in days and an impact description. You name an approver, who sees the request in their approvals inbox and records a decision with a comment. When you save an approved change request that has a budget impact, ProjectCAPEX offers to add it to the cost log, so the money is not left off the books.
To walk through a change request on a working programme, try the demo or start free.