Every technology project changes along the way. New ideas come up in testing, the business shifts, or a requirement turns out to be more complex than anyone expected. That’s normal. What matters is how those changes are handled.
A change request is the process for adding, removing, or changing work after the scope has been agreed. This guide explains how it works and why it protects your project.
What counts as a change
- A new feature or report that wasn’t in the approved design.
- A different way of doing something that was already designed and built.
- Additional data, integrations, users, or practice areas.
- Removing or deferring work that was in scope.
A defect is different. If something doesn’t work the way it was designed, it’s fixed as part of the project. A change is when the design itself needs to change.
Why changes happen
- People see the system for the first time and realize what they really need.
- The business changes during the project.
- Discovery missed a process or an exception.
- A new opportunity comes up, such as an integration or report that wasn’t planned.
How the process works
- Describe the change. What’s needed, and why.
- Assess the impact. The team evaluates the effect on budget, timeline, and other work.
- Decide. You approve the change, defer it to a later phase, or decline it, with full information.
- Update the plan. Approved changes are added to the scope and schedule, and the documented design is updated.
Why a formal process helps you
Without a clear process, changes are either absorbed quietly, which puts the schedule and quality at risk, or discovered later on an invoice. A formal change request puts every decision in front of you, with its cost and impact, before work begins. It also keeps a record of what changed and why, which helps everyone months later.
How to keep changes under control
- Invest in discovery. The more thorough the discovery, the fewer surprises later.
- Review the design carefully before approving it.
- Keep a “later” list. Capture good ideas for a future phase instead of adding them mid-build.
- Name a decision-maker who can approve changes quickly.
- Ask about impact first. Before asking for a change, ask what it would affect.
To see how change requests fit into a BRIO project, read what to expect when you work with BRIO. For Litify projects, the implementation timeline shows where changes most often come up.
Frequently asked questions
What is a change request?
A change request is the process for adding, removing, or changing work after a project’s scope has been agreed, including an assessment of its impact on budget and timeline.
What is the difference between a bug and a change?
A bug is when something doesn’t work as designed and is fixed as part of the project. A change is when the design itself needs to change.
How can we avoid too many change requests?
Invest in thorough discovery, review the design carefully before approving it, and keep a list of ideas for a later phase instead of adding them mid-build.
