A change request is a subsequent change to software that is to be implemented in addition to the original commission or after completion. Many clients look for guidance at exactly this point: what tasks still arise after go-live or after sign-off, and why does this involve further effort?
This is not just about fixing errors. New requirements, changed processes, additional interfaces, adjustments to roles and permissions, or extensions to the user interface are often added.
This article gives you a practical explanation of how change requests arise, how they are assessed, and how to better judge the effort involved and the follow-on costs.
What a change request actually means
A change request is a formal request for a change to software that has already been planned, developed or is already live in operation. So this does not mean a vague idea, but a specific adjustment that is to be reviewed, assessed and, if necessary, implemented.
One distinction is important: if an already agreed function does not work in the way it was described or agreed, that is generally not a change request. In that case, it is usually about the agreed service or quality assurance, not a new additional request. You can read more about how reviews are classified in a project in the article on Software testing in projects.
Change requests can arise in any phase of a project. For clients, they often become particularly visible after completion, because it is only in day-to-day use that it becomes clear what is still missing, what should be simplified, or what should be added.
Typical examples are:
- a new form
- an additional report
- an extension to a database
- a new interface
- an adjustment for Microsoft 365 or Entra ID
- changed roles and permissions
- an additional approval process
An interface is a connection through which two systems exchange data. A database is the structured storage for an application's data.
A change request is therefore usually not a disruption, but an indication that processes, objectives or framework conditions are evolving. The article Having software developed: how to proceed also explains how such changes fit into the overall project process.
Why further tasks arise after completion
After go-live, software encounters real processes, real data and real users fully for the first time. That is exactly when requirements become visible that could only be identified to a limited extent beforehand in workshops, concepts or tests. In day-to-day use, it often only then becomes clear where information needs to be presented differently, which steps are missing, or which user journeys should be simplified.
Common triggers include, for example:
- new internal processes
- changed responsibilities
- additional locations
- new reporting obligations
- further user groups
- the connection of another system
In addition, new business ideas or organisational changes can also extend the scope of functions afterwards. What was suitable at the time of commissioning may need to be expanded just a few months later so that the software still fits the business.
The technical environment does not stay unchanged either. If cloud services, identity management or existing specialist systems are adjusted, this can create a new need for changes. A cloud service is IT infrastructure or software provided from data centres and used via the internet. You can find a clear explanation in the article on Cloud computing infrastructure.
Additional requests now also arise around AI features, for example for searching company knowledge, an assistant, or extracting information from documents. This refers to software functions that analyse or formulate content.
Project experience illustrates this well with a web platform for managing a sewer network: after launch, additional evaluations, further map views or new approval steps often arise as soon as specialist departments start using it in their daily work.
A project ending therefore usually does not mean that no further work will be needed. Rather, operations, support and targeted further development then come to the fore. If you want to plan for later change requests more effectively, you should also understand technical debt.
How a change request is reviewed and implemented
A change request is best handled in several steps: record the requested change, clarify the objective and impact, estimate the effort, make a decision, implement it, test it and document it.
A description that is as precise as possible is important here. Without a clearly formulated objective, it is difficult to assess which areas of the software are affected and what actually needs to be changed. Questions such as these are helpful, for example:
- What exactly should change for users?
- Which data is affected?
- Which roles should be allowed to see or edit what in future?
- Do interfaces need to be adjusted?
- Which tests are necessary?
By impact, we mean which functions, data flows or workflows are also affected by the change, even if they are not directly part of it at first glance. This is precisely why a small functional adjustment can become technically larger if several components interact.
A structured approach with regular coordination helps during implementation. This makes it possible to identify change requests early, classify them properly and put them into a sensible order. CI/CD is an automated way of reviewing and deploying software changes in a controlled manner.
Quality assurance involves more than a brief visual check. Functional reviews and automated tests are useful. Automated tests are predefined checks that repeatedly verify whether key functions are still working correctly.
Traceable documentation is just as important. The article on technical documentation for software projects explains why it makes later adjustments easier.
What determines the effort and cost of a change request
The effort involved in a change request rarely depends only on the visible change in the interface. What matters is which areas in the background are also affected and how extensively the existing solution has to be adapted.
Typical influencing factors include, for example:
- the complexity of the existing software
- the quality of the starting point
- the number of affected modules
- changes to the database and interfaces
- additional testing effort
- required documentation
- coordination between the specialist department, IT and the service provider
A small functional addition can therefore trigger significantly more work if several parts of the application interact. Sustainably built software often supports later changes better than quickly assembled solutions. Clean Code Development here refers to a way of working aimed at clarity, a clean structure and long-term maintainability.
Conversely, technical debt can increase the effort involved. This means short-term simplifications made in the software that make later adjustments more difficult. In precisely such cases, changes often become more expensive or more time-consuming than initially expected.
Operations and infrastructure also play a part, for example if adjustments in Azure, access rights or the interaction between several environments have to be taken into account. You can find an overview of ballmüller solutions' services here.
If the nature of the extension is already clear, the cost calculator for a rough cost range helps. For unclear or larger projects, the project check with project profile is suitable.
How to manage change requests effectively as a client
It makes sense not to collect change requests casually during a meeting or on the spur of the moment. A defined process is better: capture requests, assess them from a business perspective, prioritise them and then make a deliberate decision about what should actually be implemented.
A simple classification is helpful:
- Must: necessary for operations or the process
- Should: important, but not immediately essential
- Could: useful, but lower priority
This helps you keep an overview, and important adjustments do not get lost among smaller ideas.
Many misunderstandings later on can be reduced before the project even begins. Clear objectives, known user groups, defined processes and a comprehensible requirements basis create a shared understanding from the outset. Specifications, descriptions and early drafts do not prevent every change, but they do improve expectations on both sides.
A prototype is an early draft that makes workflows and usability tangible and testable before the full solution is created. If you are still in the preparation phase, the articles on enquiries and preparation and on the effective use of a prototype will help.
Tests are equally important so that changes can be deployed into live software in a controlled way.
Frequently asked questions about change requests
Is a change request the same as a software bug?
No. A change request is a new or altered request that goes beyond the originally agreed scope. A bug, on the other hand, usually exists when an already agreed function does not work in the way it was described, tested or signed off.
In practice, the distinction is not always obvious at first glance. A helpful question is: should something additionally be changed, or is something agreed not working properly? This distinction is important because it affects assessment, priority and effort.
Who should approve a change request within the company?
A clear functional and organisational responsibility makes sense. Approval should not happen at random, but by a party that can assess the impact on benefit, process and budget.
Depending on the organisation, this could for example be:
- project owners
- heads of department
- IT management
- senior management
Above all, it is important that responsibilities are clarified in advance. Otherwise, requests are started without a clear decision on what is actually necessary.
Why does a small change in the interface often seem bigger than expected?
Because the visible adjustment is often only one part of the work. A small change can involve further steps, for example in the database, roles, interfaces, tests or documentation. If several areas are connected, the effort quickly extends far beyond the screen view alone.
Can change requests be avoided before the project begins?
They usually cannot be avoided completely. Software only fully encounters real processes and users in day-to-day use. However, the need for later changes can be reduced through clear objectives, clean requirements and early coordination.
If you would like to assess a project in advance, a contact and non-binding initial consultation can help.
What is more sensible: implementing individual changes immediately or collecting several requests?
That depends on the nature of the request. Urgent changes with a direct impact on operations should be assessed quickly. Less urgent points can often sensibly be grouped together so that priorities, dependencies and tests can be planned more effectively.
This classification is often practical:
- review immediately: operationally relevant or business-critical
- collect: smaller optimisations
- bundle: related extensions
You can also get an impression of possible solutions by looking at reference projects and client testimonials.
Support with extensions, operations and further development
After quality assurance and go-live, many solutions enter the phase in which support and targeted further development shape day-to-day work. This is exactly where change requests arise regularly: when processes need refining, new requirements need adding, or existing workflows should be simplified.
ballmüller solutions develops and operates bespoke software with Microsoft .NET, SQL databases and Microsoft Azure. Design and development are carried out by the company's own developers and designers in Germany.
Its services include, among other things:
- app development
- web development
- database development
- hosting and operations
If you would like to classify a change request or planned extension from a business and organisational perspective, a non-binding initial consultation via Microsoft Teams is also possible. Selected reference projects also provide further insight.