During 8 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, 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 requests 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 specification, 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.
Would you like to know more about traceability? Read expert content on this topic.
So, how does change request management work? Traditionally, a product manager or another responsible person from the client’s side initiates this procedure, which initially can be reported as a bug or a new feature that should be developed. From the vendor’s side, a QA, an analyst, and PM are responsible for accepting the request and together with a representative of the client 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 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 who 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 start 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 occur to be not quite what the business needed.
All the changes during a particular time are submitted to the steering committee for the 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 for the analysis.
Any change can either decrease the scope/budget/duration or increase it. Only after the client has approved the change, the development can 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 come back 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.
Need assistance in software project development? We build custom software solutions for dozens of industries and provide IT consulting.
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 the way the 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 provide:
- 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:
- 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 costs on 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, accept or reject. 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 change requests from clients. 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 on every change;
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.
Want to know more about how we deal with change requests? Contact with us.