How to Handle a Project Change Request (Process + Template)

A verbal "can you just add this?" on a busy site, in a clinic corridor, or over a quick call can feel harmless. Days later the schedule has slipped, the budget is tight, and nobody can remember who agreed to what. Informal changes wreck projects not because the ideas are bad, but because nobody logged the request, checked the impact, or updated the plan.

This guide walks you through a practical project change request process you can use on construction and field work, healthcare operations, small business projects, and multi-team delivery. You'll get clear steps, a copy-ready form, a short worked example, and tips for avoiding the most common mistakes.

What is a project change request?

A project change request is a written proposal to alter something that was already agreed: the scope, schedule, budget, quality expectations, deliverables, or how work will be done. It can come from a client, a sponsor, a crew lead, a vendor, or someone on the project team.

It is not the same as day-to-day task updates. Moving a subtask by one day because materials arrived late is normal schedule management. Adding a new room, swapping a major supplier, or extending the go-live date because of a new requirement is a change that should go through a formal request.

The request itself does not approve the change. It only starts a review so the right people can decide with the impact in front of them.

Why a formal change request process matters

• It protects the baseline. Scope, schedule, and cost stay meaningful only if changes are recorded against them.
• It makes impact visible. A "small" ask often affects dependencies, risk, quality, and who else is waiting on the work.
• It creates a clear decision trail. You can show who requested the change, who assessed it, and who approved or rejected it.
• It keeps conversations fair. Saying "yes" or "no" becomes about documented impact, not about who asked loudest.
• It reduces rework. Teams stop chasing half-remembered instructions and work from an updated plan instead.

The project change request process in 7 steps

1. Log the request

Capture every change request in one place as soon as it appears. Note the date, who submitted it, and a short title. Do not wait until someone has "thought about it." If it is not logged, it is easy to treat as already approved.

2. Describe and justify the change

Ask the requester to explain what should change and why. Good descriptions are specific: "Add a second inspection checkpoint before handover" is usable; "make it better" is not. The justification should say what problem the change solves or what opportunity it creates.

3. Assess impact on scope, schedule, cost, quality, and risk

Review the request against the current plan:

• Scope: What deliverables or work are added, removed, or altered?
• Schedule: Which tasks move, which dependencies break, and does the end date change?
• Cost: What extra labor, materials, or vendor fees appear, and what savings if any?
• Quality: Does the change raise, lower, or redefine acceptance criteria?
• Risk: What new risks appear, and which existing risks grow or shrink?

Involve the people who will do the work. Field leads, department supervisors, and vendors often spot knock-on effects that a desk-only review misses.

4. List options, including do nothing

Before a decision, spell out realistic options. Typical choices are: approve as requested, approve a smaller version, defer to a later phase, or reject. Always include "do nothing" so the cost of standing still is explicit too.

5. Decide: approve, modify, or reject

Use an agreed decision path. On small projects that may be the owner and project lead together. On larger ones it may be a short change board. Record the decision, the date, and any conditions (for example, "approved if the client accepts a two-week extension").

6. Update the baseline and the working plan

An approved change is incomplete until the plan catches up. Update the scope statement or exclusions if needed, revise affected tasks and dates, adjust budget entries, and refresh risks. Tell the people whose work changed.

7. Close the request

Mark the request closed with the final outcome. Store the form where the team can find it later. Closing the loop stops old requests from floating around as if they were still open.

Copy-ready project change request form

Use these fields as a one-page form. Copy them into a document, spreadsheet, or note template and fill them in for each request.

• Request ID / date:
• Requested by (name, role, organization):
• Project name:
• Short title of the change:
• Detailed description of the proposed change:
• Reason / business justification:
• Priority (low / medium / high / urgent):
• Desired effective date:
• Impact on scope:
• Impact on schedule (tasks, dates, end date):
• Impact on cost / budget:
• Impact on quality / acceptance criteria:
• Impact on risk:
• Options considered (including do nothing):
• Recommendation:
• Decision (approve / approve with changes / reject / defer):
• Decision maker(s) and date:
• Conditions or follow-up actions:
• Plan updated? (scope / schedule / budget / risks / communications):
• Closed date:

Worked example: clinic equipment install

The example below is a made-up illustration for a small healthcare operations project. Adapt the detail level to your own work.

• Project: Install two new exam-room monitors and mounts in Clinic B.
• Original plan: Cabling and mounts in week 1, device install and staff walk-through in week 2, reopen rooms on Friday.
• Change request: Operations asks to add a third monitor in an overflow room that was out of scope.
• Impact: Extra mount and cable run; electrician needs a half-day; staff walk-through grows; budget rises by the hardware and labor cost; reopen date slips by two working days unless overtime is approved.
• Options: (1) approve third room now with a two-day extension; (2) approve only if overtime keeps the Friday reopen; (3) defer the third room to a follow-up mini-project; (4) do nothing.
• Decision: Defer. The sponsor keeps the Friday reopen and logs a new follow-up project for the overflow room.
• Plan update: Scope exclusions clarified; schedule left unchanged; a note is added on the project so the team is not pulled into informal "while you're here" work.

The useful part is not which option won. It is that the team compared impact before saying yes.

Tips for different teams

Construction and field teams

Route site instructions through the same change log used in the office. Capture photos or sketches with the request when the change is physical. Check trade handoffs and inspection dates before approving anything that looks "quick."

Healthcare operations

Spell out which units, shifts, and patient-facing services are affected. Note whether the change can happen without interrupting care, and name who can approve operational changes versus facilities or IT changes.

Small businesses

Keep the form to one page. The owner and project lead can be the whole decision path. The point is still the same: write the ask down, check schedule and cost, then update the plan.

Project managers

Agree the decision path during kickoff, before the first surprise arrives. Tie every approved change back to owners on the schedule so comments and file links sit on the tasks that actually moved.

Common change request mistakes

• Treating verbal agreement as approval. If it is not written and decided, it is not a controlled change.
• Skipping impact on dependencies. One added task can push several Finish-to-Start successors and the end date.
• Approving the work but not updating the budget. Cost impact belongs in the same decision as schedule impact.
• Ignoring the do-nothing option. Sometimes the best choice is to defer or reject.
• Leaving the request open forever. Close it with an outcome so the log stays trustworthy.
• Updating the plan only in someone's head. The team needs the revised tasks, dates, owners, and risks in the shared plan.

After approval: updating the plan with GanttMaster

Once a change is approved, the plan has to show the new reality. GanttMaster is our iPhone and iPad project manager, and it fits naturally at this stage:

• Add or reshape tasks and subtasks. Create tasks for new work, break them into subtasks, set start and due dates, priorities, and an assigned user or team.
• Repair the Gantt sequence. Relink work with Finish-to-Start, Start-to-Start, and Finish-to-Finish dependencies so successor tasks move with the change.
• Mark short checkpoint tasks. If the change adds a review or inspection gate, add it as a short regular task and link it with Add Dependency so it stays tied to the work around it.
• Update risk and budget when they are hit. Log new or changed risks with likelihood, impact, owner, and mitigation. Adjust the project budget and record related expenses by category.
• Leave a trail on the work itself. Use comments and file links on the affected tasks for the signed change form, drawings, or decision notes.
• Keep daily focus clear. The Today view and reminders help the team see what is due now after dates move.
• Keep roles and the whole team aligned. Role-based access (Project Manager, Team Manager, User) and real-time notifications help the right people see assignments and updates, with no extra cost per team member.

Final thoughts

A project change request process does not have to be heavy. If every meaningful change is logged, assessed for scope, schedule, cost, quality, and risk, decided by the right people, and then reflected in the live plan, you prevent most of the quiet drift that turns healthy projects into fire drills. Start with a one-page form, agree who decides, and close every request with a clear outcome.