How We Manage Change Requests at ScienceSoft
With 34 years in software development, ScienceSoft knows that changes are inevitable in any project, and it’s important to have a structured process to record, assess, prioritize, and implement feasible change requests.
Why Controllable Change Request Management Is a Must at ScienceSoft
Let’s first agree on what we mean by a change request (CR) and dispel some myths along the way.
A change request is a formal proposal to alter functional or non-functional characteristics of the software or any component of the IT infrastructure.
Change requests are made after the functional specification has been created and approved by a client and before the final product has been released and accepted. Development and user acceptance testing are key stages when change requests are actively submitted.
Despite the frequent opinion that changes can be requested by the client only, a development team (most commonly, business analysts, project managers, and developers) can also initiate change requests.
Change requests may not necessarily be filed using a unified submission form — they can be discussed during calls or in emails. Still, it’s important to record such requests afterward to create a single source of truth for the project stakeholders.
We need a formalized process for change request management to guarantee that:
- All change requests are recorded and considered so that each stakeholder’s input is heard and valued.
- We avoid scope creep by assessing the feasibility of each change request.
- Change requests do not mount in an uncontrollable backlog — they are prioritized and timely implemented.
- All project stakeholders can track the status of change requests centrally.
Bad Practices in CR Management — And How ScienceSoft Makes a Difference
What can go wrong
What ScienceSoft does differently
Not informing a client about a CR submission process
Not informing about a CR cost
Chaotic CR management
No visibility into the CR status
Not registering verbal CRs
Implementing all CRs blindly
Confusing software defects and CRs
Change Request Management at ScienceSoft
For us, it’s important to handle change requests effectively, avoid excessive bureaucracy, and easily integrate the practice into daily software development activities.
To have CR management running smoothly, we do some preparation work at the project start:
- We assign a responsible team member to drive the process: accept change requests, initiate the discussion with the team, update requests’ statuses, etc.
- We explain to client-side stakeholders how they can submit change requests and walk them through a common process. To prevent misunderstanding and conflicting situations, we explain the difference between change requests and software defects.
- We share a change request form.
A typical change request management process
We register every change request no matter how it is submitted:
- A unified CR form. This is the fastest way, as we immediately place a submitted form in the project’s space and trigger further processing.
- A CR initiated during project communication (e.g., meetings, phone calls, emails). In this case, we are responsible for creating a formal change request and launching its consideration.
Having received a change request, we elaborate on its details:
- Summary: name, status, owner, date.
- User story: a desired action written from an end-user perspective (e.g., I can see x in the user profile).
- Assumptions: prerequisites that we consider true (e.g., a user profile contains the same fields in mobile and web versions of the app).
- Acceptance criteria: what should be done (e.g., to add x field to the user profile).
- Optional: UI wireframes to illustrate suggested changes.
To assess the feasibility and desirability of a change, we analyze:
- The impact on software value and risks: how the change will affect user experience, software performance, availability, reliability, security, and compliance.
- The impact of not implementing the change.
- The cost-benefit ratio of change implementation.
Upon the analysis, we prioritize the changes to schedule their implementation and avoid mounting backlog and significant time delays in the project progress. We commonly distinguish between four main priority groups:
The change arises from a newly emerged business requirement critical to be covered by the software.
It’s important to include the change into the nearest software release.
The change adds tangible value to the software. Still, without the change, the software will function well and meet business requirements fully.
The change is not urgent and can be included in subsequent software releases.
The change adds certain value but is not important for the software’s core functions. Besides, the change may pose risks, and we need more time and effort to mitigate them.
The change can be implemented only if there is extra time and budget.
Cost significantly outweighs benefits, or the change poses serious risks to one or several software aspects.
The change is rejected.
If the change request is approved and scheduled for implementation, we create a task for developers in the project management software and add its link to the change request form for traceability.
- We prepare artifacts to describe a required change: additions to the functional specification, UI wireframes, architecture diagrams, test scenarios, etc.
- Depending on the defined priority, we add change requests to the project’s roadmap and implement them as scheduled.
- We indicate the date of change implementation in the initial change request.
- To keep the team informed on the progress of each change request, we timely update its status to Approved, On hold, In progress, Implemented, or Rejected.
Clients Value How We Adapt to Their Changing Requirements
Triad Fitness Group
We are thankful for the comprehensive suite of product redesign and app evolution services provided by ScienceSoft. The team’s flexibility is beyond praise, as any time we brought up new ideas, they quickly adapted to our changing requirements.
Two years ago, we commissioned ScienceSoft to audit and upgrade our partially developed AI-based software for clay pigeon shooting tracking. In the course of the project, we decided to enrich software functionality. ScienceSoft’s team promptly reacted and developed new software functionality fully adhering to our requirements.
Electrochemical Cell Design and Test Engineer
Unilia Fuel Cells
We commissioned ScienceSoft to build a flexible database. We were satisfied with the quality and efficiency of the team’s work regardless of arising challenges. For example, ScienceSoft’s experts promptly reacted to new solution requirements that appeared during the project without stalling its progress.
ScienceSoft’s team was extremely responsive and flexible and was eager to adjust to the changing requirements. The document management system developed by ScienceSoft perfectly met specific document management needs of a really narrow niche – nuclear facilities.