When there is a need to alter a software system, the details of the modification required are documented. This documentation is initiated by the entity which requests the change. The entity which has to implement the change in the software also makes contributions to the Change Request (CR) document. The CR document just specifies the task to be accomplished and does not provide details of how the modification has to be carried out. The objective of a Change Request is to facilitate change management and to track its execution.
Requests for modification to a system may arise due to many reasons, some of which are listed below.
- End user wants an enhancement to the existing system.
- Other related systems or interfaces have undergone changes that have a ripple effect on this system.
- Hardware upgrades / software platform upgrades / operating system changes have been made and the system has to be updated to accommodate the upgrade.
- The business management wants to alter the system to suit its need.
A Request for Change document is not created when the system user requires a bug to be fixed in the software or if some change is required to satisfy the system’s acceptance criteria. The CR document is created when some aspect of the system is working well as expected, but needs to be altered to suit a new business requirement. This distinction is important because the funding for bug fixes is borne by the organization that develops the software, where as the funding for a change request is often provided by the organization (client) that requests the change. A Change Request could be a request for new functionality or an enhancement to existing functionality.
Details to be captured on a Change Request document
- Name of the project
- Change Request title
- Change Request initiated by
- Document prepared by
- Document reviewed by
- Document Approved by
- Section for version control (This is required because the CR document may itself undergo several revisions before approval.)
- Date of submission
- Date of approval
- To be implemented by
- Responsibility
- Change Request ID (for tracking)
- List of reference documents / urls
- Reason for requesting the change
- Priority (Low / Medium / High)
- Definition of the change required
- Scope of work
- Impact of the change (For example, a disruption of service while the change is being implemented)
- Configuration Items (infrastructure components) affected by the change
- Alternatives (if any)
- Potential risks associated with the change, risk management strategy and roll-back options
- Verification and acceptance criteria for the change
- Expected completion date
- Estimated effort and cost
- Section to record approval or rejection and sign off
- Status (Initiated / In-progress / Completed)
A Change Request document must be approved and signed off by the requestor and implementer. If, for any reason, the request for change is rejected by the organization that was expected to implement the change, the reason for rejection is recorded on the Change Request document. Rejection is also signed off by both parties.
A Change Request document aligns the expectations of the requestor and deliverer with regards to budget and timeline. Change is inevitable and the Change Request document is a starting point to manage and control change.