Let’s talk about improving change management. In the project management world, there’s a common diagram that states delivery is dependent upon scope, time, and cost. And that if you want to improve one of these, it will adversely affect the others. But imagine if you could improve your time (to market) without changing cost or scope? Or deliver a larger scope without increasing time or cost?
Good news… you can! But guess what – you’ll need to work differently to achieve it.
Digital Transformation and Improving Change Management
I’ve seen first-hand how improving change management is critical to better technology delivery as part of an IT service management (ITSM) approach. At a previous organization I worked for, digital solutions became a key revenue stream.
To ensure that the company kept the ability to adapt and change quickly, we insourced large amounts of our IT. It was imperative that the technology teams delivered solutions to market quickly and effectively yet, as with many companies, there was an inherent contradiction at the heart of change management. On the one hand, there was increasing business pressure to quickly bring products and innovations to market to meet customer demand. On the other, there was the need to comply with standards and internal controls, a key one being ISO20000, required by many large customers.
This is a common issue for modern businesses. The seemingly conflicting tasks of increasing speed to market, while maintaining the controls required to keep technology operations both stable and secure. Traditional approaches such as adopting a single standard or framework to work against, can fail to deliver. Whereas the adoption of multiple standards and frameworks and philosophies, such as ITIL, can help you achieve both of these goals. The key is to understand what your business needs in any one part of your delivery chain and to apply the principles that work best for you.
Constraints and How to Get the Best Out of Them
As well as reducing the time taken for changes, and meeting compliance requirements with ISO20000, we had a third goal – improving change management’s perception among IT and end users. We were convinced that if we could manage the first two we’d also achieve the last. But how could we do it?
The first step was to use the constraints we had to build buy-in. Although ISO20000 puts certain controls on what you’re trying to achieve, it also brought in significant revenue by assuring customers that we comply with best practice standards. To quantify this benefit, we approached the sales teams and asked them to calculate the value of such customer contracts. And by talking in a language that they understood, i.e. money, they were happy to do what we asked. The result was that we gained an understanding of the business need, but also tangible evidence as to why the requirement was there. This triggered almost instantaneous buy-in.
So What Did We Do in Improving Change Management?
Once we had buy-in the next step was to work with both end users and IT users to understand what they’d like in terms of improving change management. We used Agile techniques here to create a list of all the changes or improvements that were requested – a Product Backlog in Agile language. We then ranked these with the process owner, ready for implementation over the next four weeks, and then every four weeks after that. This is a Sprint Backlog in Agile terms, or a set of requirements to anyone else.
To test these process changes we used discrete teams to see if the changes worked each time and to decide whether to amend them before rolling them out to all. With the tool expertize sitting in-house we could control and underpin any changes – such as removing unnecessary fields quickly and effectively. A distinct advantage of this approach was that contributors could see their feedback being acted upon. It created a virtuous circle with more help and buy-in coming from all teams.
It has to be stated that these changes weren’t implemented without control. The change management process does not work in isolation and changes can have knock on effects. A good example is configuration management – any change to the change management fields had to ensure that the information feeding into the configuration management system (CMS) was still adequate. Without this causality awareness you are potentially merely swapping one issue for another.
The final significant change was to introduce a simple good/bad feedback mechanism for users. We used this to understand whether process improvements were going in the right direction. And by doing this from beginning to end of the initiative, we were able to see the overall change in perception of the improving change management process.
What Happened Next and How Did We Measure It?
So how do you prove that you’ve achieved what you set out to do? Well, your metrics need to be the right ones – not just the easy ones. We kept our ISO20000 certification so we were able to demonstrate that easily. We had an increase in user satisfaction (both end users and IT), so again we were able to show success there. But how do you demonstrate that we were able to get to market quicker? More successful changes? Business satisfaction? Increased revenue?
In this situation we worked with the business and agreed a simplified version of a value stream map taken from Lean principles. We mapped a simple change that had been done prior to our work and measured it against three changes afterwards. This clearly and authoritatively demonstrated the reduction in time and the business benefit.
Has your organization been improving change management (ITIL or otherwise) for better business? What principles did you use, and were they successful? I’d love to hear from you in the comments below.
Are you looking for an article on enterprise service management?
Or would you like the latest Gartner ITSM Magic Quadrant report for free?
Rebecca Beach
Rebecca Beach helps IT service management companies and individuals to connect with audiences and communities by developing and running their digital marketing programs.
