Go to ScienceSoft Global
How We Manage Change Requests at ScienceSoft
With 35 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.
When made
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.
Who makes
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.
How made
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
|
Client-side stakeholders waste time to understand the submission process by trial and error and feel uncertain whether their CRs are properly accepted and considered. |
At the start of a project, ScienceSoft explains to the client a change request flow: from different submission variants to CR evaluation and prioritization principles. |
|
Not informing about a CR cost
|
A client thinks that CR implementation is included in the agreed contract cost and doesn’t expect extra fees. |
ScienceSoft calculates the implementation cost of each CR individually and shares the calculations with a client before approving/rejecting a CR. |
|
Chaotic CR management
|
CRs can be neglected or implemented too promptly without the final client’s approval. In such cases, a client can end up with either software not meeting their needs or extra costs. |
ScienceSoft has a structured process in which CRs pass through all key steps, from submission and assessment (feasibility, cost, priority) to implementation or rejection. |
|
No visibility into the CR status
|
An initiator of the CR feels confused about whether their input has been heard, approved or rejected. |
ScienceSoft stores all CRs with statuses (e.g., pending, approved, rejected) in a single project space and shares the access with a client. |
|
Not registering verbal CRs
|
Verbal CRs can be lost. |
ScienceSoft assigns a responsible person (usually a project manager or a business analyst) to record verbal CRs. |
|
Implementing all CRs blindly
|
CRs can be a waste of time and budget if they don’t add to the value of software. Besides, reckless implementation of CRs may lead to functional conflicts. |
ScienceSoft first evaluates the feasibility and business impact of a proposed change. If we confirm the change is desirable, we assess its criticality, as well as the cost and time needed for implementing it. |
|
Confusing software defects and CRs
|
Not distinguishing clearly between CRs (paid extra by a client) and defects (reimbursed by an IT vendor) means unfair costs for either a client or a vendor. |
We check a functional specification. If the software doesn’t behave according to the specification, we deal with a defect. If something beyond the initial scope is requested, it’s a pure CR. |
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
CR submission
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.
CR description
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.
CR evaluation
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.
CR prioritization
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:
Must-have
Essence:
The change arises from a newly emerged business requirement critical to be covered by the software.
Implementation urgency:
It’s important to include the change into the nearest software release.
Should-have
Essence:
The change adds tangible value to the software. Still, without the change, the software will function well and meet business requirements fully.
Implementation urgency:
The change is not urgent and can be included in subsequent software releases.
Could-have
Essence:
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.
Implementation urgency:
The change can be implemented only if there is extra time and budget.
Will-not-have
Essence:
Cost significantly outweighs benefits, or the change poses serious risks to one or several software aspects.
Implementation urgency:
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.
CR implementation
- 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
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.
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.
