15 Tips for Getting Started with Change Management – Part 2
Here, I add another eight to give you the full 15 tips and things to consider when getting started with change management:
8. Don’t blindly follow change management best practices.
Good or best practices are things that have worked at a number of other organizations. But those other organizations aren’t your organization! ITSM tool vendors have also most-likely created UIs, templates, workflows, alerts, and reporting capabilities based on these best practices and/or what their average customer needs. These might fit your organization, or they might not. So don’t blindly adopt either best practice or ITSM tool out-of-the-box ways-of-working if they go against what your company (and its people) want, need, and expect from change management. Hopefully, the best practice will fit but it’s best to check before trying to change IT operations in a way that ultimately won’t work for your organization.
9. Conversely, don’t act as though your organization’s change management needs are totally unique.
Most of what needs to be achieved through change management will be similar across organizations, so many of the best practices will be applicable. As is often quoted about ITIL – the guidance is designed for an “adopt and adapt” approach. So take only what you need and change it to suit your organization’s circumstances. The important thing is to understand what can be used to meet desired outcomes of change management while not adding unnecessary bureaucracy or conflicting with company norms.
10. Understand the benefits and limitations of change management or IT service management (ITSM) technology.
While a change management or ITSM tool might be great in terms of workflow, automation, and improving general organization, change management is really about people, what they know, and the decisions they make. Thus, as with any other ITSM activity, having the right people with the right skills is key (and the right process too). Only then can the technology really start to help.
11. So don’t forget to think “people first.”
Sadly, when people talk of change management, or ITSM per se, it’s easy for them to get bogged down in “the process” and with the enabling technology. It’s so much better for change management to be thought of as people working together to deliver required change and innovation, with the support of process and technology. So don’t spend all your time and money on processes improvement and new technology without thinking about, and then recruiting against, the right type of people qualities for change management roles. Remember that good people can make bad processes or technology work, but sadly the best processes and technology will struggle in the hands of the wrong people.
12. Measure the right things.
Don’t make change management metrics and reporting an afterthought of process adoption. Designing, and agreeing on, metrics and reporting early on in change management introduction has multiple benefits that go beyond fit-for-purpose metrics and reporting. A big one is that it can act as a sense-check for design and implementation. For instance, this can relate to ensuring that change management is delivering against business requirements (when you consider how metrics, KPIs, and critical success factors stack up). And consider your change management metrics carefully. Don’t just blindly steal the metrics suggested by ITIL or those used by other companies that you might have sought help from. Instead, pick metrics that are relevant to your organization and what you need to achieve through change management.
13. Don’t let the change advisory board (CAB) get in the way; and let the CAB get in the way.
Confusing? The point is to ensure that the right requests for change (RFCs) get to the CAB and that the right people use the right techniques to assess these proposed changes in terms of impact and risk. This sounds obvious but ask your peers if their CABs have a reputation for slowing down change (and perhaps even innovation). Your change management metrics should be used to assess how “thorough” (read “successful”) the CAB has been, coupled with the CAB self-regulating what should and shouldn’t have come its way. Wherever possible, the CAB should be adding more change scenarios to the list of pre-defined and pre-approved changes that no longer require its oversight (and the associated delay).
14. Use different “routes” and methods, “change models,” for different types of changes.
For instance, a “non-standard change” will need greater attention than a “pre-defined and pre-approved change/release” based on their relative levels of risk and potential impact. You can find out more about this by looking at the table in my “ITSM Basics: A Simple Introduction to Change Management” It’s also important to set and manage expectations around what is involved with these different types of changes, particularly the required lead times for different changes to be delivered.
15. Don’t ever forget continual improvement.
This might be as simple as stopping activities that add little or no value, or re-engineering a certain part of the change management process to improve things. It could also be more holistic in terms of corporate change management. For instance, the “run the business” teams (IT operations) and “change the business” teams (app dev) might currently work in isolation, when it comes to changes and change management. Here, the adoption of DevOps is an improvement opportunity to better deliver change at speed while maintaining control. Or it could be that better change management might be dependent on starting or improving another ITSM and ITIL activity, such as configuration management say.
Well, there you have it. My list is not definitive but I believe it’s a good foundation. Please tell me – what would you add?
Also, if you want to watch a really great change management webinar, then check out “Never Underestimate the Importance of Change Management” by ITSM industry luminary Ivor Macfarlane.
Posted by Joe the IT Guy