en flag +1 214 306 68 37

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.

How We Manage Change Requests at ScienceSoft
How We Manage Change Requests at ScienceSoft

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.

Change request management - ScienceSoft

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

View all customer reviews

Flexible in Adjusting the Project Scope, Even after the Project Start

A typical software development project lasts 6+ months, and we understand that your business requirements or vision may evolve during this time. We are always ready to go the extra mile and consider any fresh ideas.