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.
Meet the Queen of ITSM Mythbusting
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.
Myth 1: You can’t do Change Management without a comprehensive Configuration Management process in place.
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 ITIL 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?
- Look to your Service Desk. Check out Incident Management to see what is already documented in terms of business critical services and who supports them. Chances are the same people who are fixing incidents are going to be the same people raising Changes so you can do some impact assessment that way.
- Look at your Service Catalog if you have one. Your Service Catalog will give you a view of all your live production services, or at least the most critical ones. Make a point of matching the services flagged in a Change record against the Service Catalog to give you an idea of impact.
- Make affected services a mandatory question on your Change Form. Asking your Change Owners or the person raising the Change to list the affected business services against the planned works that they’re doing is key. If they don’t know, that means talking to people until they find someone that does—whether that’s the business, the Service Desk, relationship managers, service catalog managers, service deliver managers, etc. It’s all about building those relationships up.
Myth 2: I don’t have time for formal Change Management in my organization. Too much red tape, right?
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.
Myth 3: CAB meetings are just a box ticking exercise.
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:
Respect People’s Time. If you have special guests that will only be talking about one or two Changes, then have those Changes discussed first so they can drop off. There’s nothing more soul destroying than spending two hours in a meeting when you’ve only been needed for the first five or ten minutes. Be mindful of special guests and let them drop off when they’re done representing.- Don’t Discuss Everything. If it’s a Standard Change where it’s zero risk/zero impact, you really shouldn’t be discussing it at CAB. That’s something that can be pre-authorized ahead of time. CABs are there to capture the important, high-impact Changes. Focus on the Changes that will be visible to the business and could cause all kinds of pain if things go wrong. Don’t clutter up your CAB with minor Changes like making a network port live or a small desk move.
- Keep it Fast-paced. This reminds me of a customer engagement where I was brought in to turn Change Management around. The first CAB went on for two hours and someone actually fell asleep. I had to make the decision whether to wake him up or take a picture for social media. Don’t worry! I woke him up discreetly. But in all seriousness, it’s about setting the expectation that the purpose of CAB is a quick recap. It should really be about two to three minutes per Change. What you don’t want is people getting confused or breaking out the Change record verbatim. This is just the high level information that enables the rest of the CAB to make effective decisions.
- Have a Terms of Reference. Make sure everyone knows the agenda and understands their roles and responsibilities. Then when you’re in the middle of a CAB meeting, no one can say: “I’m not sure if I can actually improve this or not?” or “I don’t know if I’m the right person to do this?” The person that attends has to be empowered to make decisions. And if someone can’t attend, then a substitute can be sent who is empowered to make decisions on that persons behalf.
- Share the Schedule of Change. I recommend sending out a quick email with the link to the Schedule of Change. This reminds CAB members to read it beforehand so they come armed with all the questions and concerns that they have. The same goes for after the CAB meeting as well. Issue your report as a Change Schedule – a list of approved Changes that you can filter by date and service, that way everyone knows what’s going on. Another report that’s useful to share post approval is the Projected Service Availability report. I know, I know, ITIL 3 called it the Projected Service Outage report but let’s take a step back for a moment. No one in a business facing role wants to hear the word outage associated with their service. Outage has big scary connotations such as uncontrolled downtime, leading to incidents and complaints. Let’s not frighten the horses here. Stick to PSA – it implies that you’re in control and that any downtime associated with Change activity has been planned, communicated and authorized.
Next Steps
Read the entire ITIL Mythbuster Series!
- ITIL Mythbusting: Change Management Truths You Needed Yesterday
- ITIL Mythbusting: Incident Management Facts That Will Supercharge Your Processes
- ITIL Mythbusting: Problem Management vs. Incident Management? Think Batman vs. Columbo
- ITIL Mythbusting: Is Configuration Management too difficult for little gain?
- ITIL Mythbusting: Service Request Management Facts to Keep IT and End Users on Cloud Nine
Do you have an ITIL myth you want busted? Send it to us in the comments or reach out to us on Twitter @EasyVista and @vawns.
For more ITSM expertise, Follow Vawns Murphy on Twitter and check out her articles on ITSM.Tools and archives on TheITSMreview.com.
