Writing effective Change Requests

Change always happens. No matter what project you are on, no matter how well a requirement is documented, many situations arise where the requirements must change. Client Business logic has changed, new regulatory requirements arise, internal teams have discovered a need to update the solution; no matter the situation, signed-off requirements may need to be updated, changed, or removed.

Depending on the project methodology your organization uses, be it Waterfall, RUP, Agile, Hybrid-Agile, an effective way to track project requirement changes is via the use of Change Requests. This blog post will delve into the creation of the Change Request, but not the approval process behind it, as various development methodologies have different ways of approving the Change Request.

A Change Request document, in itself, is a formal document that allows you to capture how a simple or complex business or technical change impacts the existing implementation of a project.

Below are some key components of an effective Change Request:

• The project name;
• The request number;
• The requestor;
• Description of the change;
• The reason for the change;
• The impact of the change;
• The proposed action to be taken;
• The business priority of the change;
• The status of the change (approval block).

The Project Name

• This should contain the unique project name or identifier that your organization uses to identify projects, initiatives, or solutions.
• Additionally, if a solution is in production, it would be good practice to identify which release version is impacted.
• This element ensures that the Change Request is applied to the correct area of the solution.

The Request Number

• This should be a unique identifier for the Change Request.
• Having a unique identifier makes it easier for stakeholders to reference specific Change Requests, and helps when capturingChange Requests within the Project Change Log.

The Requestor

This section identifies who requested the change -

• Internal Stakeholder & team;
• Client Stakeholder.

Description of the Change

This section should contain meaningful information that allows those who pick up the Change Request to understand, at a glance, what the Change Request pertains to.

• A concise but clear description of the change that is being requested.
• Avoid being overly verbose or adding detailed business logic/requirements into this section, as that information can be captured elsewhere in the Change Request.

The Reason for the Change

This section allows you to document the reason(s) behind the Change Request. This section also provides the readers of the Change Request with further context into the drivers behind the change.

• Changes to client business logic;
• Changes to technology;
• Regulatory change requirements, etc.

The Impact of the Change

This section should identify the areas of the solution or document artefacts that will be impacted by the Change Request:

• Changes to specific (signed-off) Business Requirements;
• Changes to specific(published) Business Documentation (manuals, specification documents, etc.);
• Changes to Product Specifications;
• Changes to application modules;
• Changes to Business Rules/Logic;

The Proposed Action to be Taken

This section provides the details of the action(s) that will be taken to address the change requirement

• This section should include some or all of the following:
• Details of Application modules or functionality to be changed;
• Details of Business requirements to be modified (detailed text);
• Details of Business Rules/Logic to be updated (detailed update with any logic examples);
• Details of the updated solution configuration or development work;
• Details of updates to Business Documentation;
• Details of updates to Product Specifications
• This section may be completed by multiple contributors, including (but not limited to):
• Business Analysts
• Data Analysts
• Solution Architects
• Enterprise Architects

The Business Priority of the Change

This section would provide the context to the importance of the change to the Requestor making the request.

• You can use the priority hierarchy that your organization uses, which may be a variant of:
• Critical
• High
• Medium
• Low
• Defining the Business Priority allows Development Leads, QA Leads and Project Managers to allocate the correct resources to the change initiative.

The Status of the Change (Approval Block)

The Status of the Change allows readers to identify where, along the approval process the Change Request lies.

• Use the status hierarchy that your organization uses, which could be a variant of:
• New
• In Review
• Approved
• Rejected
• The Change Request Approval is typically provided by the Project Sponsor, and may not necessarily be the Change Request requestor.
• As a matter of ensuring accuracy, the Change Request should be reviewed by the requestor to ensure that the Change Request accurately captures the changes required.

Author — Francis Roque, DLT Labs™

About the Author: Francis Roque is a seasoned Senior Business Analyst with vast experience and extensive knowledge. His experiences span Fintech, Financial Regulation, Human Resources, Telecom, Consulting, Managed Services, and now Freighttech and Distributed Ledger technology.