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.
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.
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 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.
Need assistance in software project development?We build custom software solutions for dozens of industries and provide IT consulting.
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.
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:
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:
So, if you ask for a change, you will be provided detailed information on how this change impacts the project execution and cost.
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:
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.
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:
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 us.
Software solutions bringing business values
USA (Headquarters)+16469803276 2810 N Church St, Ste 94987, Wilmington, Delaware 19802-4447
Denmark+4531562900 Copenhagen, 2900 Hellerup, Tuborg Havnepark 7
Poland+48789743438 ul. Księcia Witolda, nr 49, lok. 15,
Lithuania+4366475535405 Alytus, LT-62166,
Faroe Islands+298201515 Smærugøta 9A, FO-100 Tórshavn,
Austria+4366475535405 Donau-City-Straße 11 - Ares Tower, 1220 Wien
UAE+4366475535405 Emarat Atrium, 423 Al Wasl Area, Dubai, P.O. Box 112344
Ukraine+4366475535405 Vatslava Havela Boulevard, 4,