Change Request

A change request is a proposal to alter a product or system, often brought up by the customer or another team member. During a project, this can happen when a customer wants to change or alter the agreed upon deliverables. Change requests can also be initiated internally as well and can include things like changing or upgrading software.

In general, there are two types of change requests: those that are inside the scope and those that are outside the scope of the project. Change requests that are inside the scope involve small corrections to an existing requirement. They usually have minimal impact on the budget or the rest of the team. On the other hand, change requests that are outside the scope take a considerable amount of time to implement and have a more sizable impact on the budget.

Once a change request has been made, the entire team should be informed and they can come to an agreement about how to satisfy the request without using unnecessary resources. There are three important questions to ask about any change request:

  • What is the change about?

  • What is the benefit?

  • How important is it to you?

Change Request Management Cycle

image7.png
  • Determine the scope of the Change Request – The first question to consider is what exactly the scope of the change request is. A change request could be related to the business, stakeholder, or functional requirements. Along with identifying what the change is, it is important to identify the benefit of making change or the business need driving the change. This will help stakeholders determine whether or not the proposed change is worth the effort.

  • Determine and Analyze the impacts of the Change Request – Once understood what the proposed change is and its importance appreciated, the project team will need to formulate a response to the proposed change. This typically means identifying the impact of the change on the technical design and project schedule, putting together a high-level implementation plan, and determining the level of effort to make the change.

  • Approve or Reject the Change Request – Change requests pass through an Approval process, where the proposed change is analyzed, its impact is assessed, and its requirement is validated and justified. Change approval is done to ensure that the proposed benefits of the change are valid. If approved, the change can then be implemented with minimal risk.

  • Communicate and Implement the approved Change Request – Once the change request is approved, the project team needs to be notified and project deliverables need to be updated.

Relationships to other Sciforma Objects

The relationships available for Change Requests are as follows:

Change_Requests_Relationships.png

Green_Arrow.png

Transformed into

This relationship will be created when the Change Request reaches the “Closed” Workflow State. The Change Request can thereupon be transformed into another object, while allowing the user to keep track of its evolution.

Change Requests can be turned into Issues (1-1), Actions (1-1), and Tasks (1-1).

Attached_to.png

Attached to

The Change Request can be attached to another object, allowing the user to associate some or all of the elements they respectively share with each other. This connection can be created and deleted without any consequences.

Actions (1-N), Backlog Items (N-N), and Attachments (1-N) can be attached to the Change Request.

LoopGrey

Duplicate & Attach to

The relationship will be created when the Change Request reaches the “Duplicate” Workflow State. The Change Request can thereupon have a Parent-Child relationship with another Change Request.

A Change Request can be attached to another Change Request (N-N) when “connecting” them together.

In this section