Project change request process flowchart (scope, cost, schedule)
A project change request process flowchart covering the change register, impact assessment, the tolerance decision, steering group approval and re-baselining.
How it works
Rename the lanes to your real roles
Replace Requester, Project manager, Project team, Finance and Change authority / steering group with the roles you actually have. On a small project the change authority may be a single sponsor and Finance may be a business partner who reviews the numbers by email. Merge lanes rather than drawing governance bodies that do not exist, and keep the lane count at five or fewer so the chart stays readable.
Write your tolerances next to the decision
"Within the project manager's tolerance?" is only useful with figures behind it. Record the cost and schedule variance the project manager may authorise, plus a scope rule such as no change to agreed deliverables, benefits or contractual commitments. If you run PRINCE2, this is the tolerance the project board delegates, and it may come with a change budget so routine changes never reach the board. Agree the limits at initiation, not the first time they are tested.
Define what the impact assessment must contain
Turn "Record the impact assessment" into a real template: effect on scope, schedule, cost, quality and risk, the funding source, the options considered, a recommendation and the do-nothing option. Name who assesses each dimension and how long they get, because an assessment that takes three weeks turns into a decision made without one.
Name the change authority and its cadence
At the steering group review, record who the approvers are, whether a quorum is needed, how often they meet and the cut-off for getting on the agenda. Decide explicitly what happens between meetings: either a named person may authorise urgently and report it at the next review, or the change waits. Leaving that undefined is what produces changes approved in corridors.
Make deferral time-bound
A deferred change needs a review date, an owner and a live status in the register, which is why the Defer branch here returns to a later steering group review rather than to a terminator. Check deferred items at every review and close the ones that have been overtaken, with the reason recorded, so the register reflects decisions rather than accumulating them.
Set the re-baselining rule, then publish and version the chart
State which approved changes trigger a formal re-baseline and which are absorbed into the forecast, and require the change reference to be recorded against the new baseline version. Keep earlier baselines so a variance can still be explained months later. Then share the diagram where the work happens — next to the change request form and in the project handbook — and keep its own version history so you can show when the procedure changed and why.
Frequently asked questions
What is the difference between a project change request and IT change management?
They answer different questions. A project change request asks whether an agreed baseline — scope, cost, dates and often benefits — should be altered, and the decision is commercial: what it costs, what it delays, who funds it and whether the business case still holds. IT change management asks whether a change to a live service should be released, and the decision is operational: risk to users, testing, downtime window and rollback. If the conversation involves a CAB, a change calendar and a rollback plan, use the change management process flowchart. If it involves a steering group, a revised end date and a budget line, this is the right diagram.
What should a project change request include?
Enough for someone else to assess it without a meeting: what is changing and why, who raised it and when, the trigger — a new requirement, a defect, an external dependency, a reversed decision — the urgency, who is affected, and what happens if nothing changes. The assessment adds the rest: effect on scope, schedule, cost, quality and risk, the funding source, the options considered and a recommendation. Keep the two as separate records. The request is the requester's words and the assessment is the project's answer, and merging them makes it impossible to see later what was actually asked for.
Who approves a project change request?
It depends on size, which is what the tolerance decision in this chart is for. Changes that fit within the variance the project manager was delegated at initiation are approved in the Project manager lane and recorded. Anything beyond that goes to the change authority, normally the steering group, project board or sponsor. PRINCE2 names the change authority as a role the project board can delegate to, sometimes with a change budget attached so routine changes do not need a full board decision, and PMI's integrated change control uses a change control board for the same purpose. Whatever you call it, write the limits down: an undefined tolerance means either everything is escalated or nothing is.
What does deferring a change actually mean?
That the decision is postponed rather than refused — usually because the impact is not yet clear, the change depends on another decision, or it belongs in a later phase or release. It only works if the deferral is time-bound. In this chart the Defer branch routes to a hold step that re-tables the change at a later steering group review, not to a terminator, because a deferred change with no return path is a rejection nobody had to justify. Give each deferred item a review date, an owner and a visible status in the register.
Do you have to re-baseline after every approved change?
Re-baseline anything that changes what the project has committed to deliver, by when or for how much. Otherwise variance reporting measures against a plan you have already agreed to abandon, and every status report needs a verbal explanation. Keep the previous baselines rather than overwriting them, record the change reference against the new version, and note the approval date. Small changes approved within tolerance are usually absorbed into the forecast instead of triggering a formal re-baseline — state which is which in your plan so two people reading the same report arrive at the same number.
How does this process stop scope creep?
By making the cost of a change visible before it is agreed rather than after it is delivered. Scope creep is rarely a single large decision; it is a series of small additions absorbed by a team that never sent them for assessment. The controls that matter here are the register, so every request has a record; the impact assessment, so nobody approves an addition without seeing what it does to the dates and the budget; and the tolerance limits, so the project manager knows exactly where their own authority stops. The process cannot prevent changes, and should not — it makes them deliberate and attributable.