How change requests management in software development works

For many years, we have accomplished dozens of custom software projects. Within these years, we also processed thousands of change requests from our clients. Frequent changes are the reality of every project. They hurt all the stakeholders: customers, vendors, developers, and project managers. A lot of companies are trying to avoid change requests, but the fact is that they still occur.  

Every software vendor has its procedure for change request management. We want to tell you how it works in general and how it works in DICEUS, in particular.  

How change requests management works

Our VP of Engineering, Yuri Karpenko, has kindly agreed to tell us how to manage change requests appropriately. With over 25 years of experience in project management, he knows everything about change requests and their effects on the project’s scope, budget, and timeline. Below he explains how it works. 

At the initial stage of any software project, one of the most challenging things is understanding what a change is and what is not a change. Several stakeholders can conclude if the issue is either a change or a bug.  

This understanding depends on how well and comprehensively requirements are gathered and documented. If there is any double meaning in the requirements, it can cause misunderstandings within the development process. Thus, it’s crucial to properly gather all the functional and non-functional requirements, create software requirements specifications, and build a traceability matrix based on those documents.  

Why is all this documentation important? Firstly, we mitigate future conflicts. Secondly, we can easily set up the change management process. Ultimately, we understand how any change impacts the scope, cost, and timeline of the project.  

So, how does change request management work? Traditionally, a product manager or another responsible person from the client’s side initiates this procedure, which can initially be reported as a bug or a new feature that should be developed. From the vendor’s side, a QA, an analyst, and a PM are responsible for accepting the request and, together with a client representative to triage the request (and here, the traceability matrix becomes one of the most important sources of truth regarding system functionality). If the bug has been identified as a real bug – it will be re-routed to the development team and is supposed to be fixed. Otherwise, the vendor has to proceed (after approval from the client side) with impact analysis.  

That is a common practice that a client is charged for the impact analysis. Moreover, sometimes, the cost of the impact analysis can be higher than the change implementation itself, but all rules and procedures should be agreed upfront. 

It is a vendor that collects all the changes that were requested by the client. It helps avoid unexpected and uncontrolled budget spending, scope creep, and other issues standard to software development. Prior to starting with any change request, it should be approved by the person who has the right to control the budget from the client’s side, as it can have a negative impact on the project budget with no real business value as an outcome. Otherwise, the implemented changes could not be quite what the business needed.  

All the changes during a particular time are submitted to the steering committee for review. The vendor or client representative informs the committee about the number of the requested changes, their status, the impact analysis results (cost, duration, proposed milestone dates), and how much was spent on the analysis.  

Any change can either decrease the scope/budget/duration or increase it. Only after the client has approved the change can the development be started. Also, the client can cancel the change or put it on hold. In the latter case, clients should understand that while placing the change on hold, it is likely to become obsolete when they decide to return to it.  

Traditionally, a vendor must report metrics on the number of changes made, the team’s capacity to process the changes, and the speed with which the change is being implemented from the moment it was requested.  

How we at DICEUS manage change requests 

As we mentioned, during 8 years of our work, we have processed thousands of change requests. Traditionally, our clients ask to increase or reduce the scope and deliverables. However, once the change is implemented, both our clients and we get what was expected.   

Here at DICEUS, we distinguish procedural changes and significant changes reflected in a change control notice (CCN). The type of change determines the way it will be assessed and implemented.   

How we deal with significant changes  

Significant changes modify, add, or reduce the scope. They can also adjust the conditions of the agreement, including service levels, charges, schedule, or statement of work. What do they affect? They can potentially affect project performance and how clients conduct their business.   

Note: Any significant change can increase project costs.  

Significant changes are prioritized as urgent or usual. One change generates a single CCN. Once the CCN is completed, we will provide the following:  

• A detailed description of the change 
• Charge review
• List of deliverables required to implement a change
• Timetable for implementation
• Impact analysis
• Any relevant acceptance criteria
• Assessment of the added value
• Any proposed amendments to agreements

Why is impact analysis important? It helps define how a change will affect any services or deliverables provided. Usually, it considers the following parameters but is not limited to:  

• Scope   
• Cost
• Delivery dates
• Acceptance criteria 
• Disaster recovery plan 
• Roll-back provision, including its cost and impact
• Infrastructure requirements, including new equipment and software

So, if you ask for a change, you will be provided detailed information on how this change impacts the project execution and cost.   

How we deal with procedural changes  

Procedural changes modify the way the services are performed or provided. They have nothing to do with the scope, as when implemented, they don’t add or reduce it.  

Procedural change management is typically described in each statement of work. Both a client and a vendor are responsible for their costs to prepare, assess a CCN, administer, and implement a change.   

Procedural changes are made at no additional cost to the client unless they will increase the costs of performing the services. However, for any additional charge, we provide the following material to support the respective notice:  

• analysis of the reasons why we believe the cost will be impacted by the change + supporting documents;  
• evidence that we are performing efficiently.  

Once a notice is created, it is sent for review and approval. Based on all the documentation, clients review it, and accept or reject it. Also, they may request an amendment on CNN or ask for more information.  

How change requests management works in DICEUS  

Change management in DICEUS is a well-organized set of procedures to process and maintain client change requests. In general, these procedures include the following activities:  

• Reporting on the status of scheduled changes  
• Coordinating all the associated activities
• Performance of the changes in the client’s IT environment
• Moves from development and test environment to production
• Creating a database for every change
• Summarizing

Each year, we review our change management procedures to make them more efficient. Our specialists search for better ways to automate scheduling, tracking, and reporting on changes.