A change request process is a formal, auditable workflow that captures proposed project changes, evaluates their impact, and produces a documented approval or rejection before any work begins. Project managers and IT teams should use it for anything that alters scope, schedule, cost, or deliverables. The recommended first move: adopt a standard change request form and log every submission in a change register with a unique ID, starting today.
TL;DR:
- Detailed impact thresholds should be defined for your organization, such as dollar limits or schedule days, to differentiate between minor, major, and emergency changes.
- Impact analysis must be completed within 24 to 48 hours, with a consistent checklist considering scope, schedule, cost, quality, risk, and dependencies to ensure objective decisions.
- Approval authority should be tiered: project managers handle standard and minor changes, delegated leaders review mid-level requests, and a change control board manages major alterations.
- Every change request form must include unique IDs, impact categories, and decision records to maintain clear audit trails and prevent scope creep.
- Implemented changes require updating project plans, assigning owners, conducting QA, and recording actual impacts before closure to sustain control and clarity over project scope.
Table of Contents
- What Is a Change Request and Why Formalize the Process?
- Types of Change Requests and How They Route
- Change Request Form: The Fields You Actually Need
- The Change Request Lifecycle, Step by Step
- How to Assess Impact: A Practical Checklist
- Approval Authority: Building a Change Control Board
- Implementing and Verifying the Approved Change
- Sample Change Requests and a Register Entry
- Best Practices for Managing the Change Request Process
- How Requestum Supports Change Control in Software Projects
- Three Non-Negotiables I Enforce in the First 90 Days
- Get Help Implementing Change Control in Your Software Project
- Primary Sources and Further Reading
- Sources
- FAQ
What Is a Change Request and Why Formalize the Process?
A change request is a formal proposal to modify a project's scope, schedule, budget, deliverables, or approach after the baseline has been set. That distinction matters more than it sounds: an issue is something broken that needs fixing within existing scope, while a change request asks permission to alter the scope itself. Confusing the two is one of the fastest ways a project loses control of its own boundaries.
Formalizing intake and decision-making around change requests solves a problem every technical team eventually hits: verbal agreements evaporate, and nobody remembers who approved what six weeks later. A structured change control process captures, evaluates, approves or rejects, implements, and documents every proposed change, which gives you something a hallway conversation never can, a paper trail.
The operational payoff shows up in three places:
- Audit trail: Every decision has a record, a rationale, and a timestamp, which matters during compliance reviews or client disputes.
- Control: Scope creep gets caught at the door instead of discovered during a budget review three months later.
- Stakeholder alignment: Everyone works from the same documented version of "what changed and why," not competing memories.
Frameworks from PMI and Prosci both treat change governance as a discipline, not an afterthought bolted onto project management. Prosci's research, cited in change management literature from Harvard Business School Online, frames change control as something to establish immediately after the baseline is set, not once problems start piling up.
Types of Change Requests and How They Route
Not every change deserves the same level of scrutiny. Most mature organizations sort requests into four categories, and the category you assign determines who reviews it, how fast, and through what path.
- Standard changes are pre-approved, low-risk, and repeatable, like a routine server patch or a template update. These often skip formal review entirely because the risk profile is already known.
- Minor changes affect a small slice of scope, schedule, or budget, typically under a threshold like 5% of the project budget or two to three days of schedule impact. A single approver, often the project manager, can usually clear these.
- Major changes cross bigger thresholds, a scope addition worth $10,000 or more, or a schedule shift of two weeks or longer, and they typically require a change control board (CCB) review before anyone touches the work.
- Emergency changes address something breaking in production or a critical business risk right now. These use an expedited path with verbal or single-approver sign-off, followed by retroactive documentation within 24 to 48 hours.
Response times and categorization are commonly defined by service level agreements or internal policy, which means your organization should set its own dollar and day thresholds rather than borrowing someone else's numbers wholesale. What counts as "minor" for a $2 million enterprise platform build is very different from what counts as minor for a six-week mobile app sprint.
Change Request Form: The Fields You Actually Need
A change request form only works if it forces the requester to answer the questions a reviewer will ask anyway. Skip a field, and you'll be chasing the requester by email a day later, which defeats the purpose of having a form at all.
A professional change request form should capture the requester's name, a unique request ID, the date, the project name, a detailed description, business justification, impact category, and the final decision record. That last field is the one most templates forget, and it's the one that prevents undocumented scope creep from sneaking back in later.
| Field | Why It Matters |
|---|---|
| Request ID | Unique identifier that ties the form to the change register entry |
| Requester name & role | Establishes accountability and a point of contact |
| Date submitted | Anchors the SLA clock and audit trail |
| Project name | Prevents cross-project mixups in shared registers |
| Description | Plain-language summary of what's changing and why |
| Business justification | The "so what" that lets reviewers weigh urgency against effort |
| Impact category | Scope, schedule, cost, quality, resources, risk, flagged individually |
| Priority/urgency | Standard, expedited, or emergency, drives routing |
| Attachments | Supporting diagrams, quotes, or requirement docs |
| Decision & approver | Approved, rejected, or revised, with name and date |
| Change register link | Cross-reference to the master log |
Digital intake through a shared tool beats paper or email chains for one simple reason: version control. A paper form gets lost or edited without a trace. A digital form logged directly into a change register creates a timestamped, unchangeable record the moment it's submitted, which is exactly the kind of documentation you want if a dispute ever surfaces months later.
The Change Request Lifecycle, Step by Step
Every change request moves through the same six stages regardless of industry or project size. Skipping one, especially impact analysis, is how "quick favors" turn into unbudgeted rework.
- Submission and completeness check. The requester fills out the form; someone, often the project coordinator, verifies every required field is populated before it enters the queue. Incomplete forms bounce back immediately rather than clogging the review pipeline.
- Logging to the change register. The request gets a unique ID and an entry in the master log the moment it's accepted for review. This single step is what makes the entire process auditable later.
- Impact analysis. A cross-functional review, usually involving the project manager, a technical lead, and sometimes a business analyst, assesses scope, schedule, cost, quality, risk, and resource impact. This is the step Microsoft's own project change evaluation guidance centers on: does a workaround exist, is new funding needed, will the schedule slip, and which stakeholders need to sign off.
- Decision routing. Based on category and thresholds, the request goes to a single approver, a delegated authority, or a full change control board. The rationale for the decision gets documented in the same record, not in a separate email thread.
- Implementation assignment. Once approved, the change gets assigned to an implementer, the project plan and baseline get updated, and the team communicates the change to affected stakeholders.
- Verification and closure. The implementer confirms the change works as intended, the change manager records actual versus estimated impact, and the request closes with a note in the post-implementation review.
Pro Tip: Assign the impact analysis step a hard deadline, 48 hours for standard requests, 24 for expedited ones. Analysis paralysis kills momentum faster than a bad decision does, because at least a bad decision can be revisited.
How to Assess Impact: A Practical Checklist
Impact analysis fails most often not because teams skip it, but because they do it inconsistently, one reviewer weighs cost heavily, another weighs schedule, and the recommendations that come out the other end aren't comparable. A shared checklist fixes that.
Run every request through the same six lenses:
- Scope: Does this add, remove, or alter a deliverable, and by how much?
- Schedule: How many days or weeks does this add to the critical path?
- Cost: What's the dollar impact, both direct labor and any new procurement?
- Quality: Does this introduce technical debt or risk to acceptance criteria?
- Risk: What's the probability and severity of something going wrong if this is approved, or if it's rejected?
- Dependencies and stakeholders: Who else needs to sign off, and does this ripple into other workstreams?
A simple scoring model works well here: rate each dimension 1 to 5 for severity, multiply by a weight reflecting your organization's priorities, and sum the total. A request scoring above a set threshold, say 60 out of 100, automatically routes to the CCB regardless of its category label. This keeps the decision objective rather than dependent on who happens to be reviewing it that week. Cassandra's guide to incremental impact assessment breaks down a similar scoring logic for teams evaluating change at scale.
The blind spot teams hit most often isn't cost or schedule, it's dependency mapping. A change that looks contained to one module can quietly break an integration three teams over, and nobody catches it until testing.
Approval Authority: Building a Change Control Board
Who gets to say yes matters as much as the form itself. Most organizations structure approval in tiers rather than routing every request to the same person.
- Tier 1, single approver: The project manager clears standard and minor changes within pre-set thresholds, typically under 5% of budget or a few days of schedule slip.
- Tier 2, delegated authority: A program manager or department lead approves changes that exceed PM authority but don't warrant a full board, often up to $25,000 or a two-week schedule shift.
- Tier 3, change control board (CCB): A cross-functional group, usually including the project sponsor, technical lead, finance representative, and PM, convenes for major changes affecting budget, contract terms, or multiple workstreams.
A CCB doesn't need to meet weekly if the pipeline doesn't justify it. Biweekly or on-demand works fine for most mid-sized projects. What it does need is a consistent agenda: request summary, impact analysis findings, recommendation, and a documented vote or decision. Skipping the documentation step is the single most common CCB failure; verbal consensus in a meeting room evaporates exactly like the hallway conversations this whole process was built to replace.
Emergency changes bypass the tier structure entirely through a conditional approval path: a single authorized approver signs off verbally or via a fast-track digital form, work begins immediately, and full documentation follows within 24 to 48 hours.
Implementing and Verifying the Approved Change
Approval is the easy part. Turning it into working software, or a working process, without breaking something else is where discipline actually gets tested.
- Update the plan and baseline. Revise the project schedule, budget, and scope documents to reflect the new approved state, and preserve the original baseline separately so you can always compare planned versus actual.
- Assign an owner. Someone specific, not "the team," takes responsibility for delivering the change, with a deadline tied to the SLA the category dictates.
- Build in QA checkpoints. Define acceptance criteria before implementation starts, not after, so testing has a clear target rather than a moving one.
- Test and validate. Run the change through whatever QA process the project normally uses, unit tests, user acceptance testing, or a staging environment review.
- Handle failure explicitly. If the implementation doesn't meet acceptance criteria, roll back to the prior baseline and document what went wrong before attempting a fix, rather than patching forward under pressure.
- Close and record actuals. Log the actual cost, schedule, and scope impact against the original estimate. This closing step feeds directly into the post-implementation review process that improves your next impact analysis.
Sample Change Requests and a Register Entry
Seeing the process applied to real scenarios makes the abstract steps concrete.
A minor change example: a client asks to swap a button color scheme on a mobile app's onboarding screen. It scores low on every impact dimension, so the project manager approves it within a day, no CCB needed, and it's logged and closed within a week.
A major change example: a client wants to add a payment gateway integration mid-build, adding three weeks to the schedule and $18,000 to the budget. This triggers full impact analysis and a CCB review, since it crosses both the cost and schedule thresholds.
An emergency change example: a production database query is timing out under load, threatening a client's live e-commerce checkout flow. The technical lead approves an expedited fix verbally, work starts within the hour, and full documentation follows the next business day.
Best Practices for Managing the Change Request Process
The strongest change control processes share a few habits that separate them from the ones everyone complains about.
- Recommend revisions instead of flat rejection. Experts generally advise a recommended revisions path where the requester and PM negotiate a scaled-down version, preserving the relationship instead of a hard no.
- Document every rejection with rationale. A rejected request without a documented reason invites the same request to resurface in a month.
- Communicate decisions fast. Prompt, documented communication about approvals or rejections reduces resentment and keeps stakeholders aligned, rather than left guessing.
- Avoid over-bureaucratizing small changes. Right-touch governance means a $50 CSS tweak doesn't need the same CCB review as a $50,000 scope add.
Pro Tip: Keep a one-line template ready for decision communication: "Request CR-#### [approved/rejected/revised] on [date] by [approver]. Rationale: [one sentence]." Send it within 24 hours, every time.
How Requestum Supports Change Control in Software Projects
The company builds change governance into how it delivers custom software rather than treating it as paperwork bolted on after the fact.
That shows up concretely across the delivery lifecycle:
- Business analysis upfront: The business analysis practice documents baseline requirements early, giving every later change request something stable to compare against.
- Case studies in structured delivery: Some projects involved iterative scope refinement, managed through documented requirement updates rather than ad hoc rework.
- QA verification tied to change closure: Implemented changes run through quality assurance checkpoints before a request closes, keeping the "verify before you close" discipline the lifecycle above depends on.
- Backlog and plan updates: Approved changes get reflected in project backlogs and updated plans immediately, not retroactively, keeping baselines honest.
Three Non-Negotiables I Enforce in the First 90 Days
Every project I've reviewed that lost control of scope had one thing in common: no preserved baseline to measure drift against. That's the first fix, lock the original plan before anything else moves.
Second, mandatory intake fields with unique IDs, no exceptions, not even for the CEO's "quick favor." Verbal changes are how audits fall apart. Third, every decision gets documented and communicated within 24 hours, approved or not. Teams that skip this step don't lose control all at once. They lose it request by request, until nobody can say what the project actually promised anymore.
— Dmitry
Get Help Implementing Change Control in Your Software Project
Everything above works whether you run it in-house with a spreadsheet or a dedicated tool. If your team would rather have change control, business analysis, and QA verification built directly into delivery from day one, that's where a development partner earns its keep.
Requestum's web development services fold change governance, impact analysis, and QA checkpoints into the delivery process itself, so approved changes get implemented, tested, and documented without derailing your timeline. This guide is vendor-neutral; every step here can be run entirely in-house with the form and register described above. If you'd rather have a team that already builds this discipline into custom software delivery, reach out to Requestum to discuss your project and get a quote.
Primary Sources and Further Reading
- Change Control Process: Steps and Template for Projects, ReWork
- 5 Steps in the Change Management Process, Harvard Business School Online
- How to Evaluate Project Change Requests, Microsoft Support
- What Is the Change Management Process?, APQC
- Understanding Change Requests: A Guide
Sources
- Change Control Process: Steps and Template for Projects
- Understanding change requests: a guide
- BVOP — change requests guidance
- 5 Steps in the Change Management Process | HBS Online
- How to evaluate project change requests (Microsoft Support)
FAQ
What is the change request process?
It's a formal workflow for proposing, evaluating, approving or rejecting, implementing, and documenting a change to a project's scope, schedule, cost, or deliverables after the baseline is set.
What are the seven steps of the change management process?
Common frameworks vary in exact count, but the core sequence is: submission, completeness check, logging, impact analysis, decision routing, implementation, and verification/closure, with communication running throughout.
What are the four types of change requests?
Standard, minor, major, and emergency, sorted by risk and impact, with each type routed through a different approval path and SLA.
Can you give examples of change requests?
Common examples include a minor UI color change approved by a single project manager, a major scope addition like a new payment gateway requiring change control board review, and an emergency production fix approved through an expedited path.