Skip to content

Creating Change Requests

Change requests are to be raised in Zammad tagged with Change Management.

The change ticket itself should be owned by the individual who is managing the change. This person is known as the change owner. This will usually be the individual implementing the change, but the change owner can be someone who is monitoring the change on behalf of those implementing the change. This can happen if the change is being monitored at a senior level due to risk or impact, if it is being performed by multiple people or is being implemented by an external organisation. The change owner must always be a member of BriCS.

All changes must contain the following information:

  • Change Description: A clear and concise explanation of the change.
  • Scheduled Date and Time: Proposed start and end date and time for the change implementation.
  • Reason for Change: Justification or requirement driving the change.
  • Impact Assessment: Potential impact on systems, users and services.
  • Affected Systems: List of systems or services impacted by the change.
  • Test Plan: A plan to verify the success of the change.
  • Implementation Plan: Steps required to execute the change.
  • Rollback Plan: Procedure to revert the change if issues arise and when/how the decision to rollback will be made.

Additional information which may be useful should also be added. For example if your change is going to be disruptive to the user community you should consider how your change will be communicated and add a Communication Plan to the ticket.

Below is a full description for each plan a ticket is expected to have.

Change Description

The change description provides a clear and detailed explanation of the change being proposed. This should include the nature of the change (hardware, software, network, configuration, etc), the components involved, and a high-level overview of what will be modified. The description should be written in a way that anyone unfamiliar with the system can understand what the change entails while also providing enough technical detail for the Change Management Board or nominated approver to evaluate.

Scheduled Date and Time

The expected start and end date and time of the change. This is the entire duration of the change and not just the period of expected disruption which should be given separately if appropriate. The timing must be an accurate reflection of the amount of time the change is expected to take and it is recommended to include some contingency. If the contingency is a significant percentage of the expected time to conduct the change due to uncertainty this should be detailed in the change request.

Reason for Change

The reason for change is to provide justification for the change. It could be driven by a variety of factors such as resolving a problem, implementing a new feature, software updates, security improvements or system optimisation. Do not assume the change description is sufficient justification by itself.

Impact Assessment

The impact assessment evaluates how the change will affect the current environment. This analysis should identify any potential risks, disruptions or downtime associated with the change. It should also consider dependencies on other systems and any possible effects on performance, security or functionality. In addition to negative impacts, this section can also highlight positive outcomes. A thorough impact assessment helps teams prepare for any complications that might arise during or after the implementation. It will also help you to determine if a change should be taken to the Change Management Board for approval.

Affected Systems

In this section list all systems that will be directly or indirectly affected by the change. This ensures that all teams responsible for those systems are aware of the change and can assess its impact from their perspective. This section may also include information on dependencies with third-party systems that could be influenced by the change or vice versa. Being specific about the affected systems helps avoid unexpected issues and ensures proper coordination between team members.

Implementation Plan

The implementation plan outlines the step-by-step actions required to carry out the change. This plan should be detailed enough to guide the team through each phase of the change from preparation to execution. It should specify who is responsible for each task, the timeline for implementation, and any resources or tools needed. The plan should also take into account any pre-change backups or configurations that need to be performed. A clear and comprehensive implementation plan ensures that the change is carried out smoothly and minimizes the risk of errors or oversights.

Rollback Plan

The rollback plan provides a strategy for reverting to the previous state in case the change fails or causes unforeseen issues. This plan should include specific steps for undoing the change such as restoring backups, reconfiguring systems, or reverting code to a previous version. It should also specify any dependencies or conditions that need to be met before initiating a rollback. Having a rollback plan is important to ensuring that the system can quickly recover from any problems caused by the change, minimising downtime and disruptions to our service.

Test Plan

The test plan outlines how the success of the change will be verified before and after implementation. It should include specific test cases that cover all critical functions of the system being changed as well as criteria for success or failure. The plan should detail who will perform the tests, what tools or scripts will be used, and when the testing will occur (for example, in a test environment prior to deployment or in production after the change is made). The test plan ensures that the change achieves the desired results and that no new issues are introduced.

Communication Plan (if appropriate)

A communication plan outlines how information about the change will be communicated if the change is expected to cause disruption to the user community. A good communication plan should minimise confusion, manage expectations and ensure that users are informed and prepared for the change. If users are expected to take action please be clear as to what those actions are and how they will be communicated.

Approval

Once a change has been raised in Zammad it should be brought to the attention of potential approvers. That may be the Change Management Board for disruptive changes and/or appropriate Lead, Specialist or other delegated/nominated individual for non-disruptive changes.

Change Implementation

Once a change has been raised and approved the change can be implemented as described in the change.