Welcome back to the ITIL Mythbuster series! Configuration Management can be a complicated and mighty feat for any organization. Perhaps that’s why there is so much misinformation swirling around this particular ITIL process. No worries! Vawns Murphy, ITIL/ITSM expert and Principle Analyst and Research Director at ITSM.Tools, is here to debunk the top Configuration Management myths she’s encountered during her 15+ years in the business. In this post, you’ll get the true story directly from our interview with Vawns along with actionable recommendations for process improvements.
Myth #1: It’s all or nothing.
Short answer: Not true. Normally I’m the first to say “either go big or go home” but that’s not the case with Configuration Management; it’s much too important. Done well, Configuration Management is the process that can help you manage, control, and protect your production environment and has the power to improve every other ITSM process.
Oftentimes when I meet with a client to discuss putting in or fixing Configuration Management, they start having flashbacks to when they first tried to accomplish this task years ago. Maybe an expensive Configuration Management tool was purchased or previous consultants were brought in but for whatever reason it didn’t work. After years of experience, I can confidently say that 9 times out of 10 the reason the project did not succeed was because they never set a scope or their scope was too broad. With Configuration Management it’s so easy to say you’re going to do everything under the sun—until things have snowballed into this unmanageable endeavor. The problem is long-term sustainability. When you run out of tools, people, or budget, all of a sudden you’ve spent massive amounts of effort and money without actually achieving anything. The key is to start small and work your way up.
Here are my own tried-and-true recommendations for Configuration Management:
- Start with your most business critical process. I always recommend to build up Configuration Management over time. Start with the service that everyone uses and couldn’t survive ten minutes without.
- Talk to the business and your service desk. Not sure what your most business critical service is? Look at your Service Catalogue or your SLAs. If you don’t have that, it’s time to speak to your end users. Not an option or not sure who to ask? Talk to your Service Desk. Ask them which service is a nightmare to support. Find out which one falls over the most often and takes the longest to get back up and running—causing an angry mob to start gathering their pitchforks.
- Map out your service from end to end. Now that you’ve figured out which service to start with, get the process mapped out perfectly. Check with everyone involved from a support perspective and get it documented and added to your CMDB.
- Play with the data. Ask your techies try to impact assess changes and have your Service Desk try to get the impact of Incidents. Be sure to have people do a sanity check and tinker with the data you collect. Look at the best ways of collecting it and make it repeatable by using templates. Or, have a core set of data and attributes that you plan to collect along with the relationships.
- Repeat. Use that first service as a prototype. Once you have that service nailed (and sanity checked), you’ve now got an approach that makes it easy to repeat the process again for the next most painful service, and so on. Keep going until you have captured all your most critical systems.
- And again, keep it simple. It’s always easier to build up over time or add things as you go along. Whereas if you start trying to collect a hundred different things about each individual attribute, before you know it, you will have tons of data that is adding no value.
Myth 2: The tool will fix everything.
Short answer: If only! The temptation to chuck a tool at a situation in hopes that it will solve all your problems is a big (yet common) mistake. Like Julia Roberts in that shopping scene in Pretty Woman, “Big mistake. Big. Huge.” A tool is only as good as underpinning information and processes. If you don’t get those right, then your tool will just sit there gathering dust.
After spending money and time on a new tool, people expect that it will just fix everything. But in reality, it’s just a tool. You can have the most state-of-the-art, sparkly tool in the world, but if you don’t have the right data, people, and processes in place to support it, it’s all over. The tool is not going to get the job done and it won’t perform to optimal levels.
It’s frustrating to hear people say, “We bought this tool and it’s going to solve all our problems.” That’s when I start asking questions like: Did you work with the vendor? Did you train people? Did you hire a Configuration Manager? Typically these clients respond “No” to all of the above, thinking that everything would magically work once the tool was switched on. Unfortunately, it doesn’t work like that. (The person who invents a tool that produces CMMI level 5 Configuration Management with the flip of a switch is going to make billions!) But it’s not just about the tool-success hinges on your people and processes.
People - You will need a full, experienced team in place to do Configuration Management. You’ll also need your supporting players, like Change Management, to make sure that everything is under control. For example, if you don’t update your Configuration Management system, or your CMDB, every time you make a change, it’s going to get out of date.
Processes - I recommend having touch points across the processes. For example, in Change Management a Change should not be marked off as successful until the entry for what’s been changed (a server, a piece of software, a patch, etc.) has been updated in the CMDB as well. That way everything stays in sync.
Additional considerations for successful Configuration Management
As you can see from the above examples, Configuration Management is not just a tool. Anyone who says “Buy this solution and you’re all good” is totally off base. Having the right people and a solid process in place is vital. That said, there are a number of other considerations to take into account:
Planning - Do you have the right plan in place? It’s important to develop a plan that details your scope, including what you’re going to attack first.
Baselining your existing environment - Can you use automation? Can you use a tool? How do you verify that? What checks do you have in place? This step is all about identifying the key services captured at the planning stage and adding the details to your CMDB. By carrying out a baselining exercise, not only do you have your key services captured, you also have a “snapshot” of your environment at that point in time, something that will live and breathe as your Configuration Management process matures.
Control – If you’re not sure about what controls to put in place then look to your Change Management policy and process. Eventually, everything under the control of Change Management should also be supported by Configuration Management. That way, what you have in the CMDB really does match what you have in your real life environments. If your production environment is going to be under the control of Change Management what about any kind of development, test, or QA environments as well? If they’re not under Change control, is it worth adding them to the CMDB because there are no guarantees that this information is going to be kept up to date.
Looking at the lifecycle of things - Make sure that one of the key attributes you capture is where something is in its lifecycle so that you can tie into things like IT Asset Management (ITAM) and Software Asset Management (SAM) from a licensing perspective. This is a really quick way of realizing benefits.
Verification and Order - Trust but verify. Make sure everything is built into the data logs so that instead of having a painful audit once a year, you can carry out spot checks. That way, a list of completed Changes can be compared to what’s been updated in the CMDB on a monthly basis and things will stay in sync.
Incentivization – Working in IT is awesome. Think about it, we get to save the world one windows update at a time and provide awesome levels of service to our customers; so who says Configuration Management has to be a zero fun activity? Is there a way to incentivize your team to encourage them to follow the process? For example, one recent trend that I really love is gamification. Merit badge or mini quests for updating the CMDB correctly or adding information about key services can make following the process much more appealing. By having a small reward at the end of the month for example an Amazon or Starbucks gift card can generate a healthy sense of competition so that your teams not only follow the process but take pride in doing it well. That’s a cool way to make it fun and get buy-in.
Myth 3: It’s too difficult and expensive for very little gain.
Short answer: Ok, I get it. Configuration Management is probably one of the most daunting ITSM projects to undertake but for all the concerns, you need to counter with the potential upsides. You must ask yourself questions like: What is the impact of all the failed Changes because we couldn’t do proper impact assessments? What about all the Incidents that breached SLA because it took too long to fix them due to lack of support information? How much has been spent on fines or extra licenses following an audit due to being woefully under licensed?
It’s funny how Configuration Management tends to be one of the most difficult processes to sell in the ITIL or ITSM world. Everyone gets the value of Incident, Problem, and Change, but Configuration Management is somehow tougher to gain buy-in. Oftentimes clients will tackle the first three but by the time they get to Configuration Management, they claim there is no time or money to implement and run it properly. It’s my job to challenge that and show the substantial benefits they are missing out on by not implementing Configuration Management.
“We don’t have the time”
Let’s look at how much time is wasted without it! How much time was consumed firefighting Incidents that could have been prevented had we known how things fit together? Could these things have been fixed more quickly if we fully understood the impact and all the underpinning services? How about all the time we spend assessing Changes? Years ago, I worked for a client in the Telco industry and because of the cabling, records, and age of some of the data, it could take up to 12 weeks to impact assess a certain type of Change accurately. What kind of madness is that? With a CMDB, it becomes a much quicker job.
“We don’t have the money”
What about all the fines or retrospective licenses? For example, let’s say you’re audited by a software vendor and you’re found to be under licensed. Suddenly you are paying the fines or making up the short fall. Or what about the growing issue of Zombie servers? The majority of organizations that I’ve spoken with have servers where they don’t know what’s on them or if they are even being used. However, IT is too scared to switch them off in case the business comes screaming. As a result, these zombie servers are left in place to continue taking up space and consuming power.
People consistently come up with these excuses for not doing Configuration Management but it’s such a key process. The benefits are huge! We’re not just talking your bread-and-butter- it’s the cornerstone of every other process and can be used to springboard Service Catalogue or Change Management. It can make it easier to fix Incidents and Problems. And it’s about money savings as well. There are significant cost savings if you know what’s in your environment and how it’s built up. If you have your configuration documented and up-to-date in a tool that reflects what’s actually being used in your real environment, you can recycle, reuse, and redeploy the hardware and software licenses.
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.
