Change Request Process
Scope changes are normal in software work; surprise is what causes disputes. The change request process gives every proposed change a written description, an impact assessment on cost, time and risk, a named decision-maker and a record, so scope moves only by agreement.
Start your project
Why change needs a process
Most delivery conflict comes from unrecorded change: a small request in a meeting, an assumption that something was included, a feature that grows during build. Each is reasonable alone; together they move cost and dates without anyone having decided to move them.
A light, consistent process keeps the conversation factual. It does not exist to refuse change but to make its consequences visible before it is accepted.
What counts as a change
- Adding, removing or materially altering a requirement stated in the agreed scope.
- Altering an acceptance criterion after work against it has begun.
- A new integration, platform, device or language not in the original plan.
- A change in priority that displaces committed work.
- A client-side delay or dependency that alters the plan.
- A correction that is a defect against the written scope is not a change; it is fixed under the normal process.
How Renvric approaches a change request
Raise
Anyone authorised on either side records the request: what is wanted, why, and by when.
Clarify
The delivery lead confirms understanding with the requester and checks it against scope and acceptance criteria.
Assess
Engineers estimate effort, test impact, dependencies and risk, and identify what could be traded off instead.
Decide
The named approver accepts, defers, amends or rejects, usually within a short, agreed decision window.
Record and apply
The decision is logged, the plan and budget updated, and the change appears in the next report.
Share the outcome you need and Renvric will recommend the smallest useful next step.
What a good change record contains
Each record carries an identifier, requester, date, description, reason, options considered, effect on cost, schedule, quality and risk, the decision, who made it and the date. If a change affects contractual terms, it is documented as a signed amendment rather than a note in a meeting.
For example, a retailer asks to add gift-card payments mid-build. The record would show the extra payment integration and testing, the effect on launch date and the option of releasing it in a second phase.
Roles in a change
Requester
Describes the need and its business value, and supplies any information needed to size it.
Delivery lead
Owns the record, coordinates assessment and keeps the plan consistent.
Client approver
Has authority to commit budget and schedule, named at the start so decisions are not delayed.
Technical lead
Judges feasibility, architectural effect and risk, and advises on alternatives.
Controls that keep it honest
Related areas to explore: Compare Engagement Models, Business Process Automation and Large language models.
- A single register of change requests, visible to both sides at all times.
- No work begins on an unapproved change, except an urgent fix agreed in writing for safety or security.
- Thresholds define which changes the delivery lead can approve and which need the steering group.
- Cumulative effect of changes is reported, so small items cannot hide a large drift.
- Contingency, where included, is drawn down only through recorded decisions.
Common questions
Who raises and approves a change request?
Authorised people on either side may raise one. Approval rests with the client approver named at the start, since only they can commit your budget and schedule. Renvric's delivery lead manages the process and the record, and can advise but does not approve on your behalf.
What information is needed to assess a change?
A clear description of the outcome wanted, the reason, any deadline, affected users or systems, and any constraints. If the request is vague, a short clarification conversation usually precedes assessment, because an estimate on unclear scope is unreliable.
What happens after a change is approved?
The record is closed with the decision, the plan, budget and acceptance criteria are updated, affected tests are revised, and the change is reported in the next status update. Work then proceeds as part of the agreed scope.
Does every small request need a formal record?
Anything that alters agreed scope, cost or dates is recorded, however small. Trivial clarifications that sit within existing acceptance criteria are not changes. The test is whether doing the item would alter what has been agreed, and the delivery lead helps judge borderline cases.
Can a change be rejected or deferred?
Yes. Rejection, deferral to a later release or a modified version are all valid outcomes, and each is recorded with reasons. Often the best result is to swap the item with work of similar size so the overall plan does not move.
Other ways to work together
In a project-based engagement, changes adjust the agreed scope, price or dates. In an agile team, change is absorbed by reprioritising the backlog, and a formal request is needed only when it affects the agreed capacity or budget ceiling. The principle is identical: an explicit choice by someone with authority.