“Why have you rejected this Change!?” questioned the Application Team manager of the IT Change Manager, after waiting patiently in a Change Advisory Board (CAB) meeting for the last two hours. “This Change delivers crucial functionality for our commercial platform and will place us a step ahead of our competitors”, they continued.

The Change Manager’s response? Take any, or a combination of, the following:

• You didn’t complete the Request for Change (RfC) form correctly.
• I wasn’t comfortable with the completeness of the implementation plan and backout plan.
• I feel it’s too risky at this time.
• The required stakeholders haven’t been engaged.
• You didn’t provide sufficient time for the Change Advisory Board (CAB) to review.

Some of you reading this have likely been in this position at least once before, with frustrations boiling over at the time. Most of the rejection reasons given were no doubt based on sound judgement. But how did you get to that point in the first place? How did a Change go out for approval ‘not ready’ or ‘too late’? And why do a cast of thousands need to approve a Change that your agile team are the experts in?

We regularly work with clients to help their IT Change Management activities transition from Change prevention to a more flexible, lighter, customer focused, Change enablement practice that drives accountability, and objectively balances risk with reward. This article provides an insight into our recommended approach.

Service Change Management basics

Firstly, the basics need to be clear to all:

What is an IT Service Change (or ‘Change’)? – any amendment, addition or deletion to the IT estate. Sounds clear-cut, but rarely is. Each organisation will have Changes which reside in a grey area that they may turn a blind eye to (e.g. Changes to User Acceptance Testing (UAT) environments, automated Changes, configuration Changes, etc.). Weed those out, and remove ambiguity.

Why is IT Service Change Management needed? – to improve the quality of Changes / reduce disruptive Changes, enable effective Change “go/no-go” decisions, and provide a clear audit trail of Changes made to IT services (for Changes made to financial IT Services this could be a regulatory requirement). Effective Change Management should be an enabler for change, not a blocker. For the avoidance of doubt, IT Service Change Management is not the same as Project Management (albeit there are critical relationships, see next point below), Business Change Management, nor Organisational Change Management.

What are the drivers for a Change?

• Projects (initiated via a Work Request)
  – this could result in multiple Changes being required. The Project should have already been assessed by Project Service Transition Assurance, ensuring a quality delivery as well as avoiding surprises / delays in the run up to implementation.
• Service Requests.
• Incidents – resolving or preventing.
• Maintenance activity.

Who is responsible for raising a Change? – the ‘Change Owner’. This is the technology team responsible for delivering the Change e.g. App team, Infrastructure team, Integration team, etc. For the avoidance of doubt, for Project driven Changes, this is not the Project Manager.

Key aspects of effective Service Change Management

When the basics are well understood and adhered to , there are four key ingredients to providing a flexible and effective approach to Change Management.

1. Provide Change Owners with the tools they need to be successful:

• An effective Service Management tool (e.g. ServiceNow, Cherwell, etc.) – these tools workflow, automate and improve visibility of Changes, reducing effort and the likelihood of mistakes being made
• Clear Change Readiness criteria – We provide 35 recommended criteria that flex depending on the type of Change (see point 4). They include:
  • Basic details such as proposed change implementation date/time, purpose summary, impact of not proceeding, and Configuration Items (CIs) being changed (or IT services impacted if your Configuration Management Database (CMDB) is not fully in place)
  • User readiness such as user communication plans and knowledge articles
  • Change readiness such as testing completeness, implementation plan and backout plan
  • Risk profile (see next point below).

2. Use a common and objective ‘Change Risk Profile’.

We recommend employing the tried and tested ‘Probability’ and ‘Impact’ risk factors, with clear criteria on how to assess each:

Probability – How has the IT service that is the subject of the Change recently performed? what is the track record for the team deploying this Change? what level of testing has been conducted? etc.

Impact – How business critical are the IT services being impacted by this Change? when is the Change taken place in comparison to when the IT service is used? how effective and proven are the backout and backup solutions? etc.

The Change Risk is then plotted on the Risk Profile below to determine the level of risk being carried (points), the minimum approval timescales (these can flex depending on your need), and the approvals required (see point 3):

3. Streamline approvals: 

Service Provider Change Manager (the senior manager of the team who is responsible for delivering the Change). This is the only mandatory approval required. They know their people and the IT components they are responsible for. They are best placed to make Change decisions and be accountable for successes and any disruptions.  Perspective – is this Change technically sound, and is the Risk Profile a fair reflection of the actual risk to the business?

Business Service Owner – this approval is required if there will be definite user impact (one of the Change Readiness criteria) or the Change is not low risk (i.e. in the orange or red zone). Perspective – is this an appropriate time to deploy the Change and this is within our risk appetite?

IT Service Owner – required if a new IT Service is being introduced or, if an existing IT Service, is the Run cost / service level impacted? Perspective – are you ready to take on the new / amended IT Service Owner responsibilities, and, if there is Run cost impact, has the budget been updated?

IT Change Manager / CAB – only required if the Change is high risk (red zone). These high-risk Changes are the Changes that require ‘whites of their eyes’ discussion. Perspective – given this is high risk, do the benefits really outweigh the cost? Has everything possible (within constraints) been done to reduce the risk of this Change?

Note – Depending on the quality of your IT Service Catalogue, all approvals can be automatically assigned to the Change, reducing effort and removing the risk of human error.

4. Use Standard Changes and Change Models / Templates:

Standard Changes – if the same type of Change is regularly raised and it is low risk (D4), raise a request to classify the Change as Standard. If approved by the CAB, a Change Template will be created and approvals removed. Future Changes can then be raised and ‘approved’ within seconds.

Change Models / Templates – For regularly raised Changes, regardless of risk, a Change Template can be created. This prepopulates relevant Change Readiness criteria within he Change record, as well as pre-configuring any required approvals. Future Changes can then be raised in seconds with quality content, and approvals further streamlined.

Benefits

Taking the above approach drives accountability, improves the quality of Change records and reduces effort, all while:

• enabling faster, and more effective quantitative Change decisions
• allowing the business to balance risk vs risk appetite, which is likely to vary during the year
• providing a process to adapt to any business requirement.

Enabling Change while protecting service. Now that’s a Change that should receive approval.

If you want to find out more about our services click here.

Disclaimer – opinions expressed in the text belong solely to the author, and not necessarily to the author’s employer or organisation.

Author: Chris Good

Published: LinkedIn