Project change request process flowchart (scope, cost, schedule)

What the project change request process flowchart (scope, cost, schedule) process is

A project change request asks to alter something that has already been agreed: the scope, the cost or the dates in the approved baseline. That is what separates it from ordinary replanning. Resequencing tasks, moving a person between workstreams or absorbing a two-day slip inside float is the project manager's job and needs no request. This process starts when someone asks for something the baseline does not currently promise, and it ends either with a baseline that says something different or with the request closed and the reason recorded.

This is project change control, not IT service change management. If your decision is whether to release a change into a live service, with a CAB, a change calendar, a downtime window and a rollback plan, the change management process flowchart at /templates/change-management-process and the general change control process at /templates/change-control-process cover that ground. The questions here are different in kind: what the change costs, what it moves, who funds it and whether the business case still stands. This is also not organisational change management, the people-side discipline behind models such as ADKAR, and it is not a stage gate. If you are deciding whether to proceed at the end of a phase rather than whether to alter the baseline, use the go/no-go decision process at /templates/go-no-go-decision-process.

Two decisions carry the chart. The first is tolerance: whether the change is small enough for the project manager to approve under delegated authority, or large enough to need the steering group. Without written limits either everything reaches the board, which turns it into a queue, or nothing does, and changes get made informally. The second is what the change authority is allowed to answer. Approve and reject are straightforward; defer is the one most registers handle badly, because a change parked with no review date is indistinguishable from one that was ignored. Here deferral has its own route back to a later review, and rejection has an explicit closed state rather than silence.

What this flowchart covers

In this template

• Five swimlanes (Requester, Project manager, Project team, Finance, and Change authority / steering group) across five stages: Request, Impact assessment, Authorisation, Baseline update, and Implementation and closure.
• Intake across the Requester and Project manager lanes: raise a change request with its description and rationale, log the change in the register, then a "Request clear enough to assess?" gate that sends thin requests back to the requester to add detail and rationale before re-entering the same check.
• The impact assessment in the Project team and Finance lanes: assess scope, schedule and quality impact, estimate cost and assess risk, validate the cost and funding source, then record one impact assessment record (options, recommendation and the do-nothing option included) rather than a comment thread.
• The tolerance decision, "Within the project manager's tolerance?", which routes Within to approval under delegated authority and Exceeds to escalation to the steering group.
• The change authority decision, "Approve, reject or defer?", with three labelled branches: Approve into the baseline update, Reject to a closed terminator in the requester lane, and Defer to a hold step that re-tables the change at a later steering group review.
• Baseline update through to closure: update the project baseline, Finance updates the budget and cost forecast, communicate the change to stakeholders, the project team implements the change in the plan, and delivery is confirmed before the change record is closed.

When to use this template

• You are writing the change control section of a project management plan or a PMO handbook and want the route from request to re-baselined plan on one page.
• Changes are being agreed in meetings and chat threads, so nobody can say later what was approved, by whom, or what it added to the cost and the end date.
• You need to settle delegated authority before the next project starts: what the project manager may absorb, and what has to go to the steering group.
• You are handing a project to a new manager or briefing a new steering group, and need to show how scope, cost and schedule changes get authorised.
• A PMO or programme is standardising change control across projects that each do it differently, before configuring a change register in a delivery tool.

How it works

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.