Top 10 reasons a CMDB implementation fails

Posted on 18 January 2011

Business Service Management Commentary on IT Service Management, Service Level Management & Performance Management

Below are some of the common reasons that CMDB implementations fail.   They are in no particular order.

Lack of Management Buy-in

Face it, one group is going to be the buyer and installer of the CMDB, there are many other groups/departments that will be needed to help maintain the data as well as use the data.  If there is no edict to leverage ITIL processes, there is a good chance that the CMDB project will fail or more accurately… not get used.

Owner of CI’s do not have easy access

I’ve seen several times that the change management team/group are the buyer/install/owner of the CMDB.   There is nothing wrong with that, the problem comes in that they do not have buy in from the CI owners to help maintain (or validate) the CI’s, or the CMDB solution is cumbersome and it is implemented in a manner that makes it hard for the CI’s to be maintained.  The Change Management team doesn’t want to own the CI’s (and can’t/shouldn’t), but the owners are not able to easily access the CMDB.

Garbage in, garbage out (and/or stale data)

There are lots of sources of data to populate and maintain the CMDB, exporting XML from one system and importing into another system is only part of the process of ensuring data accuracy.  XML exports are not the only ways to integrate with other sources also.   Make sure the vendor has ways to filter out noise (who cares about an SSH session from an admin workstation to the server, it’s not a dependency).  If the there is to much data, it may be hard to find anything, if there is inaccurate data, no one will trust the CMDB.  Find the middle ground.

Lack of third party Integration

There are many reasons to connect to the products to pull in additional details.  You can think of some of these applications like mini silo CMDB’s.  The HelpDesk system knows anything and everything about customers, the asset system knows tons-o-things about servers.  Integrating with different sources is a great way to get started as well as ongoing maintenance of a CMDB.

100% or NOTHING

Do not fall into the trap of holding back releasing the CMDB to the company until it is completely done.   I understand that there needs to be a certain level of data witin the system before there is value, I understand that there needs to be processes in place to maintain the data and then there is the accuracy challenges.  The point is, pick a few slices of the entire pie, define what it is, set the expectations, roll it out, get some internal wins (and learn from it), then go after a few more slices of the pie.

Hard to search/find things

The interface must be intuitive, the end users shouldn’t have to understand a database schema in order to search for CI’s.   Many of the users will only log into the CMDB a few times a year.  A user should be able to hit some internal website, get forwarded to the CMDB interface, issue a search, press print and run off to their DR planning meeting (or Solaris migration project, etc).

Over designed/engineered Schema

For those doing a roll-your-own CMDB, good for you, it is nice that you are spending time to design the database schema and planning for the future… don’t get stuck planning for 2020, your plans for the CMDB and schema WILL NOT BE ACCURATE, accept it.

One Stop Shopping

We are looking for a CMDB, this is a good time to purchase a new Change Management System, Problem, Help, etc, etc, etc…. and you have just delayed purchasing and rolling out anything for the next 18  – 24 months between the pilots and lengthy executive signoffs due to costs and implementation time frame.   Again, good idea, they need to work together in harmony, you need a plan, you need interoperability, but you also need to solve some business problems sooner.

Bottom Up = WRONG approach

If you’ve ever talked to the builders or owners of a CMDB, many times it quickly gets down into the weeds of attributes, relationships, types of CI’s.  This is all interesting information and details but… who cares.   In the end, who is the target audience, what is it that they will need to get out of the CMDB.  Take a top down approach to the implementation.  If you have a clear vision (or atleast a goal of a vision), in turn it can clearly define the types of CI’s you will initially need, potentially the specific attributes and dependency information.   It probably help you determine what types of integrations the CMBD might need with other system in order to populate and maintain the CI’s.  If you take a bottom up approach for the implementation of the CMDB, you will get stuck in the weeds and you may not have a clear answer if the design/approach/solution/product/etc will meet the end users vision/goals.

Okay, for those of you not counting, I only listed 9, in the comments below… give me your 10th one.  Don’t be shy, share a 10th one or a funny story about one.

Tobin

Website Pin Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google StumbleUpon Premium Responsive

This post was written by:

- who has written 16 posts on Business Service Management Hub.


Contact the author

  • Time and resources would be one of my guesses. So many times someone gets excited about a project, but then they fail to take into account that one or more resources will need to be DEDICATED to getting the job done. The daily grind always steps in, and before long, the CMDB beast never gets off the ground.

    • Tobin

      I think you brought up a good point around resources, when you have long running projects, there is always the risk that if the project does not show an ROI that some of the people assigned to the project can start to get assigned to other duties. Potentially the project can be understaffed to begin with due to the project being oversold or lack of resources in general.

  • Pingback: NOVELL: Novell News » Blog Archive » Top 10 Reasons a CMDB Implementation Fails()

  • Anonymous

    I’d like to add one more please….

    How often do we hear of the first CMDB implementation being ‘pushed out’ by some specific requirement (such as Asset management or Change management), with all stakeholders aware that the requirements analysis is incomplete?

    Normally, we hear comments like ‘We’ll address that later’.

    It’s at times like this I feel inclined to obliquely quote Albert Einstein – “you can’t fix a problem by applying the type of thinking that created the problem in the first place”

    Configuration Management is hardly new – for myself, I’ve been working in this space for all of my 30 years in IT.

    To me, there is only one key thought to constantly visit and re-visit during a cmdb design exercise… that is this.

    By taking on this requirement, do we support the evolution of our CMDB, from the top down, to provide a richer set of trustworthy data in the future?

    • Anonymous

      Yes, that is a very good point.  Many times one project gets stuck due to another, or they combine everything and make it near impossible to be successful.

      A top down approach from CMDB is (in my opinion) the best approach.   To many times the approach is bottom up and pulling any/everything in and in the end, a very small amount of the data is needed.  Top down defines what types of CI’s are needed, the attributes and relationships.

      Thanks for chiming in and providing useful details.

  • Pingback: Anonymous()

  • Anonymous

    Let the a CMDB died in peace please, never want to hear that word ever again