Every IT team faces the challenge of managing a constantly changing IT infrastructure, whether it’s rolling out new technologies, managing existing ones, or keeping up with a never-ending churn of updates and upgrades. The rate of change is also increasing as we accelerate into a “services first” world, and on top of that, demanding regulations require IT teams to provide a detailed audit history of system changes. To manage change successfully, IT teams need a repeatable, streamlined process that captures the appropriate data and meets regulations. Change management is used to manage these changes and to help to improve the availability of IT services, especially the services that are critical to the business.
The 4 core IT processes
- Service Request Management – A formal request from a user for something to be provided e.g. ‘I need a new Macbook for dev work’
- Incident Management – An unplanned interruption to an IT service or reduction in the service quality e.g. ‘The website is down!’
- Problem Management – Eliminate recurring incidents & minimize incidents that cannot be prevented e.g. ‘That reporting application issue is back!’
- Change Management – Standardized method to control changes to IT system to minimize the the impact on services e.g. ‘Database upgrade is now complete’
Change management 101
A formal change management process aims to minimize risks (disruptions to the IT services) while making changes to critical systems and services. There are 3 types of changes, as defined by the Information Technology Infrastructure Library (ITIL):
Standard change
A change to a service or infrastructure that is pre-approved and has an accepted and established procedure to provide a specific change requirement. They are considered relatively low risk, are performed frequently, and follow a documented (and change management approved) process. The process for a proposed standard change is presented to change management to review and approve. The proposed standard change describes how the change and associated risks will be managed. Once change management has approved the standard change, it can be carried out in production as needed. If standard changes start causing incidents, change management can bring the standard change back for review and request changes as needed. The primary purpose of standard changes is to provide a way of streamlining the process to enable rapid implementation of frequent changes while managing the risk. A standard change must have a documented process that’s been reviewed and approved by change management.
Normal change
A change raised by a request from the initiator that requires the change. They are the run of the mill, not ‘standard’ and non-emergency changes that require change management review. They are raised as Request for Change (RFC), reviewed by CAB (Change Approval Board), and approved or rejected by the Change Manager. Normal changes are often non-trivial changes to services, processes, and infrastructure.
Emergency change
Arise when an unexpected error or threat occurs, such as when a flaw in the infrastructure related to services needs to be addressed immediately. A security threat is another example of an emergency situation that requires changes to be made immediately urgency is sometimes required and these should be designed carefully and tested before use if at all possible – or the impact of the emergency change may be greater than that of the original incident. Change details are often captured at a later date’.
Organizations have two expectations of the services provided by IT — services need to be stable, reliable, and predictable, and services need to adapt to rapidly evolving business requirements — however, these expectations are in conflict. The purpose of change management is to help IT teams meet both expectations – rapid change with minimal disruption to services.
Lean change management
Change management is often a heavy process that requires days of lead time, is usually plagued by a lack of information sharing between IT and development (especially when it’s difficult for the development team to capture changes) and the approval process is often complex, which slows down the process. The Atlassian approach to change management provides a path toward lean change management, which can meet the pace of your IT team while enforcing your change policy.
Streamlined change intake using the Jira Service Desk customer portal, leveraging peer reviews to speed up the approval process, integrated IT and development teams to improve coordination on infrastructure and software development life cycle, and moving critical documents (aka change plans) into Confluence, all make it easier for teams to collaborate. So what does this lean change management process look like with Jira Service Desk?
Change Management with Jira Service Desk
Raising a change request is easy by using the customer portal as a centralized place to raise all change requests. The customer portal is easy to find and documentation can be accessed from the request – for example, some teams provide Confluence links to change request processes (such as examples for classifying changes and determining risks). We also see a lot of customers using Confluence for creating detailed change planning pages for major system upgrades, which helps break down barriers across teams because they can collaborate around a central online document. These types of pages can then be referenced in the change request when it’s created.
PRO-tip
A change schedule (sometimes known as a change calendar) helps you keep track of change requests and coordinate them with business events and scheduled releases. Confluence Team Calendars can be used as a single source of truth for managing all change requests. It provides visibility into which times are best for implementation and which times are blocked out from making changes. You can provide easy access to this type of calendar from the Jira Service Desk Project links. Access to a centralized calendar is critical to preventing change collisions with other planned changes or when application blackout periods occur.
Once the IT team has completed planning and peer review, they are ready to send it for approval – the change type determines if and what type of approval is needed. Authorizing a change request for many IT teams usually means complex approvals that are difficult to manage, however, we’re seeing many teams adopt peer reviews that streamline this process and take much of the burden off the Change Approval Board (CAB). Jira Service Desk makes it easy to implement approvals that match your change management process and Confluence provides a way to document your approval process so everyone is following the same procedure. Many IT teams also use the SLAs to monitor change approval times to ensure the team stays on track.
The Jira Service Desk automation framework can be used to automate steps in the change processes and keep it on track. The automation is flexible enough that you can create automation rules that define when certain things happen in a service desk project. IT teams can leverage the power of Jira Service Desk automation to improve and streamline their change management process. These are just a fraction of the ways that an IT team can use Jira Service Desk for change management as it’s flexible and adaptable depending on the needs of the team.
Jira Service Desk also provides simple ITIL certified workflows that get IT teams up and running in no time.
Happy bootcamping! 🙂