It’s happened before, hasn’t it?
You’ve had sign-off to implement a CMDB, agreed the budget, assigned the project team… and then somewhere along the line it’s all gone wrong. Ultimately, you had to call the whole thing off.
It’s a familiar story, and one shared by organisations all over the world.
But what makes the process so hard? After all, a CMDB is supposed to be at the core of the ITIL framework, so surely it should be an achievable goal?
Well, if you can surmount these four major implementation headaches, you’ll be a long way along the road to success.
1) Choosing a Path
It’s true that, if you’re running a very small IT operation, it is possible to operate a configuration management process without a CMDB. If you’re hoping to build a configuration management system (CMS) based on industry best practice, though, this simply isn’t an option.
And in order to proceed, you’re going to need to choose your path. Here are some common options:
A Utilise existing service desk CMDB functionality (or purchase a CMDB add-on from your vendor) B Design and build your own CMDB C Buy a vendor-built CMDB product off the shelf D Pay a vendor to design and build you a bespoke CMDB
Now I’ll be honest, this choice alone kills many CMDB implementation projects. Between budget constraints, limited timescales and varying levels of in-house expertise, it can be exceptionally difficult to determine which route is most suitable for your organisation.
The Solution:
In our opinion, the single biggest factor here is the potential for service desk integration. If successful, your CMDB will become a fundamental part of your overall ITSM approach, so its ability to interface with existing service desk technologies is vital to long-term success.
With that in mind, we believe that for most organisations it’s best to make use of CMDB functionality built into your existing service desk solution. As you’d expect these products vary dramatically in quality, and in some cases will need to be purchased as an optional extra, but they have the significant advantage of being fully integrated with your existing IT systems and processes.
In some cases, of course, this option won’t be viable. If the CMDB functionality built into your service desk solution is unfit for purpose (or non-existent), our next favourite option is the DIY approach. We’re not saying it won’t be hard, but it’s certainly preferable to the budgetary, functionality, and integration issues posed by options C and D.
Pro Tip:
If a service desk upgrade is on the cards, now is the perfect time to think about implementing a CMDB. Since you’ll be implementing an ITSM solution anyway, make sure you choose one with a strong CMDB module.
2) The People Problem
There is simply no getting away from the huge failure rate of CMDB implementations. Whether you choose to self-build or plump for a vendor-bought solution, populating and implementing a CMDB is a massive (and expensive) task.
But before you even get to the point of selecting your path, you’ll need to make an arguably even more important decision: Who will take charge of the project?
Appointing your project team is usually one of the first decisions you’ll make, and it isn’t one to be taken lightly. Prior experience of (successful) CMDB implementations would be a huge advantage, but either way you’ll need people with a keen understanding of your existing ITSM systems and processes.
Selecting an inexperienced or ineffective project team is a sure-fire way to guarantee your CMDB implementation fails, so take your time and get it right.
The Solution:
We might be biased here, but seeking professional help is an excellent option.
The value of having people with experience of multiple successful CMDB implementations is tremendous, and a good consultant will encourage a sense of enthusiasm among the staff involved with your project.
3) Doing Too Much
Another decision you’ll need to make early on is about the scope of your CMDB project. More specifically, which configuration items (CIs) should be included, which CI attributes should be included, and how will the relationships and dependencies between CIs be tracked?
First off, it’s important to realise that more isn’t necessarily better. Adding unnecessary detail will not only slow down your implementation, it will also dramatically increase the cost and time required to maintain your CMDB down the line.
Put simply, the more you try to include, the more likely you are to fail.
But of course, a certain level of detail is required if your CMDB is going to be fit for purpose. There’s really no point investing resources in a CMDB project unless the outcome will be truly valuable to your organisation.
So where should you draw the line?
The Solution:
The way forward here is to target the MED, or minimum effective dose. Spend some time identifying the CIs, attributes and relationships that are truly essential for your CMDB to be functional, and stick with that for your initial implementation.
A good rule of thumb is to start with just the items, attributes and relationships that are critical to your service provision, and work from there. In the end, it’s better to implement a bare bones CMDB successfully than to waste time and resources on a more elaborate version that will never see the light of day.
After all, you can always add more detail post-implementation.
4) It’s Not a Cure-All
Perhaps the most insidious of all CMDB-related problems lies in the underlying belief that, once implemented, it will solve all of your problems.
I hate to break it to you, but it won’t.
A CMDB is a tremendously valuable tool to have, not least for change and incident management. If well designed and maintained, your CMDB will help you make better business decisions, improve the functionality of your service desk, and provide a wide range of valuable automated reports.
What it won’t do, however, is make up for badly trained personnel or poorly conceived processes.
Consider, for example, the role of a
CMDB in change management. Are you really going to say on the strength of an automated report that a proposed change will not impact any business-critical systems, and so no further investigation is needed?
Of course not.
The report is extremely useful to have, particularly if it successfully identifies potential problems, but you’re not going to rely on it 100%. In order to truly get the most out of your CMDB, you’re going to need to widen your gaze.
The Solution:
As we’ve already alluded to, people and processes are ultimately the most important element of any ITSM approach. Sure, a well designed and maintained CMDB that’s fully integrated with service desk functions is extremely helpful, but it’s nothing compared to infrastructure that surrounds it.
With that in mind, our suggestion is simple: Build your ITSM approach around industry best practice.
ITIL and ISO20000 provide detailed guidance on how to on how to setup your infrastructure for maximum effect, and ideally you’ll want to get your ITSM house fully in order before you think about implementing a CMDB.
Give Your CMDB Implementation the Respect it Deserves
There are many ways for a CMDB implementation to fail. Ultimately, though, most first-time (…and second, third, and fourth-time) implementations fail for the same reason:
It’s much more complicated than people expect.
But that’s not to say that you can’t implement a functional CMDB that enhances your service desk and adds value to your organisation.
If you’re serious about your CMDB implementation, we’ve put together a resource that we think you’ll find useful. The Enduring Myth of CMDB focuses on how you can implement and populate your CMDB and, crucially, how to make it work within a CMS. To download your copy, just click here.
