Chatbots & Virtual Agents
IT Asset Management
Service Asset & Configuration Management (CMDB)
IT Financial Management
Intelligent Knowledge Management
Myths are a funny thing…If something is around long enough, myths will form, and like rolling a snowball down a hill, get larger over time. This is the case with ITIL, the core best practices guiding ITSM solutions today. It’s frightening how many falsehoods are still touted as truths. If you are responsible for your service management, you don’t want to miss this article. Read on through this series to separate the myth from truth for the most prevailing ITIL fables today, and be the “smartest guy in the room” the next time one comes your way.
Lucky for us, Vawns Murphy, ITIL expert and Principle Analyst and Research Director at ITSM.Tools, will be our guide in this truth-seeking adventure. Vawns is a 15+ year industry veteran with an expansive skillset as an ITIL V2 Manager (red badge), ITIL V3 Expert (purple badge), and owner of further qualifications in COBIT, ISO 20000, PRINCE2, and Microsoft. She has seen and heard it all through her professional experiences which include Senior ITSM Analyst at Enterprise Opinions, Change Specialist at Virgin Media, and ITIL Consultant at Pink Elephant.
In this week’s segment, Vawns exposes the top myths surrounding Change Management. Not only is she correcting misinformation, she’s also providing actionable advice and best practices to counter each fable. Check out the three major misconceptions below and be on the lookout for more myth busting posts that will expose truths on Incident Management, Problem Management, Configuration Management, and Service Request Management.
Short answer: Not true! While it’s definitely easier to do Change Management with the support of a CMDB so you have a definitive impact on what you’re changing, Change Management can still bring some much needed control, support and governance to your estate. It can also be used as a spring board for a Configuration Management process.
A lot of people argue that you can’t do Change Management without Configuration and a really mature CMDB in place. But the reality is that’s a very theory-driven mindset. The CMDB is a bit like a unicorn. Everyone talks about it, but how often do you actually see one in real life? Sure, having Change Management alongside a CMDB is the dream scenario because it allows for really accurate impact assessments. But what do you do if you don’t have a CMDB? Do you just not do Change Management? With Gartner and Forrester both saying that around 65-70% of incidents are caused by Change activity in some shape or form, skipping Change Management is just not an option.
So how do we manage without a CMDB?
Short answer: Not true…If Change Management is seen as an inhibitor rather than an enabler then, in the nicest possible way, you’re doing it wrong! Templates, models, and standard Changes can all be used to ensure Change can be delivered both efficiently and safely, all while saving time.
This is something I hear time and time again. When I arrive at a client’s site to put in, or improve, Change Management, I’m often met with looks of distrust. The general attitude being: “We’re too busy to raise Changes.” But in reality, you’re too busy not to raise Changes. Following the Change Process means your Change is going to be deployed effectively, efficiently, and safely by making sure that all the appropriate checks are carried out. This includes answering questions like: Who’s making the Change? Is any downtime needed? What approvals and communications are necessary? How will the Change be tested? Who’s going to be supporting the Change? What’s the plan if something goes horribly wrong? Do we fix on fail? Do we roll back? Is the person making the Change that night empowered to make that decision? And the list goes on and on.
Getting all your ducks in a row ahead of time will most certainly save time in the long run. I’ve seen horror stories where a Change was deployed to production, time was running out, and deploying to DR was completely forgotten about. Then six weeks later a disaster or business continuity issue occurred where invoking Disaster Recovery was necessary but impossible because the code was weeks out of date. If you were too busy before, just imagine having to deal with that nightmare!
Making sure to carry out the appropriate post-change verification checks ensures everything is as it should be. And the process doesn’t have to be complex. A lot of organizations complicate the matter by trying to implement Change Management without looking at their specific business and environment. They just chuck the ITIL books at it when there’s actually a lot that can be done with models, templates, and standard Changes. When I go to implement Change Management, I spend an afternoon with each support team and ask what Changes they’re raising all the time. For the ones that are low risk/low impact we follow the standard change route and for everything else we just template. It becomes a simple matter of selecting the right template, plugging in the dates, and then detailing any exceptions so it takes thirty seconds to a minute to raise a Change instead of ten to thirty minutes and beyond. There really is no excuse. I cannot stress the importance of sitting down with your support teams and writing everything up because that way, it’s a quick win. You get the detail you need, it only takes them minutes to raise the Change, and everyone’s comfortable.
Short answer: As a former Change Manager I can honestly say that the Change Advisory Board (or CAB) is one of the most important and useful meetings a service-orientated organization can have. It sets out a view of what’s happening to key services over the next week, reviews previous Change activity and looks at CSI—so what’s not to like? Use templates, models, and standard Changes to ensure that the CAB meeting can focus on the major, high category Changes that need to be sanity checked and talked through.
This is a really frustrating mindset. Sometimes it feels like you have to drag people to a CAB call kicking and screaming. But in reality, if your focus is on delivering value to your customer, the CAB meeting is one of your most important meetings. Not only does it give you that forward view of planned work, it also lets you look at the work that you did last week. Did it go well? Did it not go well? If it didn’t go well, what was the impact? And if it did go well, fantastic! Can we template it? Can we have some more Change Models? Is this a new Standard Change? It’s also a place to discuss CSI. For example, if something went well, it’s looking at the positives and the lessons learned that can be applied to other projects or programs.
Tips for getting the most out of your CAB meeting:
Read the entire ITIL Mythbuster Series!