If you have ever been involved in a software project, you have probably heard the term “Change Request”, usually written as “CR”. For non-technical teams, this can sometimes feel confusing or even frustrating, especially when you thought something was already included in the original scope.
This guide explains, in simple terms, what a CR is, why it exists, and how it actually protects both you and the software team.
What Exactly Is a Change Request (CR)?
A Change Request is a formal request to add, change, or remove something from the agreed-upon scope of work.
A CR is used when:
- The feature was not part of the original requirement
- The requirement has changed due to new business needs
- New ideas or improvements come up during development
- External parties change something (for example, payment gateway provider updates their API)
In other words, a CR is not a punishment. It is the correct way to handle new work that falls outside the initially agreed plan.
Why Do CRs Exist in Software Projects?
Software development is not static. Requirements evolve as both sides learn more about the real problem. CRs help keep the project organised and prevent the entire plan from derailing.
A CR protects:
You (the client)
- You get clarity on additional timelines, costs, and impact
- You can choose to proceed, postpone, or reject the change
- You avoid hidden charges and surprises later
The development team
- They can plan their manpower and timelines properly
- They avoid building something incorrectly
- They keep the project on schedule
A CR creates transparency. Without it, everything becomes a “verbal agreement”, which leads to misunderstandings or scope creep.
What Counts as a Change Request?
A CR could be:
- Adding a new report or dashboard
- Changing an existing user flow
- Introducing new roles or permissions
- Adding a new type of notification or automation
- Integrating with a new third-party system
- Extra screens not in the original wireframes
- Additional logic during UAT (“Can we also make it work like this?”, "Can we add in a new field in the customer sign up flow?")
A CR is usually NOT supposed to be:
- Fixing bugs in the existing agreed scope
- Clarifying something that was already documented
- Correcting mistakes in implementation
- Adding small text changes or spelling fixes
If the work changes how the system behaves, introduces new logic, or adds effort that was not initially planned, it is generally a CR.
Why CRs Sometimes Feel Frustrating
Most CR frustrations come from one of these situations:
- “I thought this was included earlier”
- “This sounds simple, why does it require a CR?”
- “But it’s only one more field”
- “Other systems have this feature, so shouldn’t it be standard?”
- “Isn't it common sense to have this here? Why is it a CR?”
This is completely normal, because what we see on the interface is only one part of the work. Even small adjustments often require changes behind the scenes:
- Updating the database
- Adjusting the UI
- Changing validation rules
- Updating reports
- Rewriting API logic
- Retesting the entire flow
So the CR is not about charging more. It is about acknowledging that even small changes have real effort behind them.
A Good CR Process Helps You, Not Just The Developer
At Double Dot, we use CRs to keep projects predictable.
A proper CR includes:
- A clear explanation of the requested change
- Impact to the existing system
- Required man-days
- Cost implications
- Updated timeline
- A decision point: Accept or Reject
This helps to keep everything documented and aligned, so the project never goes out of control.
When Should You Raise a CR?
You can raise a CR when:
Your business process changes
Example: Your team now requires a manager's approval before a refund can be processed.
A department gives new input after UAT
Example: Finance requests for an extra column in the report to they can match it with their accounting system.
Additional logic needs to be added to the system
Example: If the customer's branch is East Malaysia, the request must be sent to the Penang team instead of to HQ.
You want the system to “also do X”
Example: "Can we send a Welcome email after a successful customer sign up?"
There are new compliance requirements
Example: PDPA now requires explicit consent for marketing messages, so a new checkbox and consent-tracking logic need to be added to the sign up flow.
A stakeholder realises a better way to handle a flow
Example: After reviewing during UAT, the ops team decided to split the form into 2 separate pages to reduce human error.
If you’re unsure, ask the development team. They will tell you whether it’s covered or needs a CR.
Conclusion
A Change Request is not a barrier. It is not designed for charging more. It is a simple tool that helps keep the project structured and aligned between both the client and development team.
It makes sure that both sides understand what is being added, how it affects the timeline, and whether it fits the overall plan.
As your development partner, our goal is to keep things transparent, predictable, and fair. CRs help us do exactly that.
