A scope change request process is a way to evaluate and authorize a proposed change to an agreed project commitment. It captures what is changing, why it matters, what else would be affected, and who can decide. Its purpose is to make tradeoffs visible, not to prevent useful learning.
The Association for Project Management defines change control around proposed changes to an approved baseline, including evaluation and approval, rejection, or deferral. The lightweight process below is an adaptation for team use. Apply your organization's contractual, financial, security, and governance requirements where they are stricter.
First distinguish a change from ordinary elaboration
Not every newly discovered task changes scope. A team may uncover implementation work needed to deliver an already agreed result. That affects the forecast or method without necessarily changing the commitment itself.
Ask what the approved scope and acceptance criteria already require. A request can be a clarification, a defect correction, a changed deliverable, or a new obligation. The classification should follow the agreement rather than the requester's preferred label.
Agile delivery also needs room for adaptation. Reordering work inside an authorized boundary is different from changing a contractual milestone or adding an unsupported operating commitment. Define decision rights so small, reversible choices do not wait for a committee, while material changes receive the review they need.
If no one can identify the current agreement, resolve that ambiguity first. Comparing a request against a remembered promise is unreliable.
Use a short request that exposes the decision
A useful change request can start with one page:
| Field | What to include |
|---|---|
| Current agreement | Relevant scope, acceptance criterion, and baseline version |
| Proposed change | The specific difference, including exclusions |
| Reason | The need, new evidence, or obligation behind the request |
| Timing | When the decision and result are needed, and why |
| Options | Accept, reduce, substitute, defer, or decline |
| Impact | Delivery, cost, capacity, quality, operations, dependencies, and risk |
| Recommendation | Preferred option with its main tradeoff |
| Decision | Authorized owner, outcome, conditions, and date |
Avoid “no impact” without a basis. A change can consume little coding time yet require training, support preparation, translation, data migration, or external approval. Ask the people who will receive those obligations.
Use estimates with their uncertainty. A range and the assumption driving it are more decision-useful than a precise number invented to make the request easy to approve.
Follow the request through six steps
1. Capture it. Give the request an identifier and record the requester and date. Keep a single reference so related discussions do not become conflicting versions.
2. Clarify the need. Identify the problem the request is trying to solve. A requested feature may be one way to meet the need rather than the only acceptable answer.
3. Assess the options. Compare the smallest viable response, the full request, and doing nothing for now. Include the effect on other commitments and the work that would have to move.
4. Obtain a decision. Send the recommendation to the person or group with authority for that impact. Record approval, rejection, or deferral, including conditions and the reason.
5. Update affected agreements. For an approved change, update the scope, schedule, acceptance, operating plan, and communication as needed. Retain the earlier version and decision history.
6. Verify the result. Confirm that the authorized change was implemented and accepted, and that its downstream obligations have owners. Approval is not evidence of completion.
The administrative effort should be proportionate. A low-impact choice may need only a recorded decision by the authorized owner. A material commitment change may require formal review and supporting evidence.
Worked example: an urgent reporting request
In this hypothetical scenario, a team is preparing an internal reporting rollout. A stakeholder asks for a new export one week before operational acceptance. The requester describes it as “just another button.”
The team clarifies the need: a finance group needs a weekly reconciliation file. The current scope covers on-screen analysis, not a supported export. The full request would require field definitions, access rules, test cases, and an owner for format changes.
Three options emerge. Build the permanent export and move the rollout; provide an approved temporary report through an existing route; or defer the need to the next phase. The temporary option has its own cost: a named analyst must prepare and check it each week until a defined end date.
The sponsor approves the temporary route for four weeks, with the finance owner accepting the format and the analyst's manager accepting the capacity tradeoff. The permanent export remains a separate decision. The dates and duration are invented for explanation, not a recommended service arrangement.
The team records the condition and review date. Without that limit, a temporary workaround could quietly become an indefinite support obligation.
Handle urgency without losing accountability
An urgent request may justify a faster decision path, but urgency does not eliminate consequences. Identify who can authorize emergency action, which checks remain necessary, and what must be reviewed afterward under the existing policy.
Do not use a retrospective board as a substitute for required approval records. A discussion can clarify impact and surface options, while the authoritative decision belongs in the project's approved system.
If the authorized decision maker is unavailable, make that blockage explicit. The team should not infer permission because nobody replied before the requested date. Choose an allowed fallback or escalate through the established route.
Likewise, a deferral needs a trigger. “Later” leaves the requester with no information. “Reconsider after the operating model review, using the accepted file definition” explains what must happen next.
Learn from repeated requests
A single request can be reasonable even if it arrives late. Repeated late requests may point to missing stakeholder involvement, unclear acceptance, or a planning process that hides uncertainty.
Bring a small sample to a team retrospective. Compare when the need became known, when the team heard it, and when the decision was made. Avoid assuming the requester caused the problem simply because their name appears on the form.
Choose one improvement to test, such as reviewing operating obligations with the receiving team before committing a rollout. Use the retrospective action-items guide to define the owner, evidence, and review date.
The measure of a good change process is not how many requests it rejects. It is whether consequential changes receive clear decisions early enough to act on them.
Frequently asked questions
Does every new task need a scope change request?
No. New tasks can be implementation detail within existing scope. Compare the request with the agreed result, acceptance criteria, and decision rights. Use formal change control when the relevant baseline or authorized tolerance is affected.
Who should approve a scope change?
The person or group authorized for the impact involved. A delivery lead may be able to change implementation while a sponsor must authorize a revised commitment. Follow the project's governance rather than assuming the requester has approval authority.
How do we stop a small change becoming permanent support work?
Record the operating owner, capacity, acceptance, and any expiry or review date before approval. Verify those obligations after implementation. A temporary workaround needs an explicit end condition or it can become an unplanned ongoing service.