Top 6 Pitfalls to Avoid When Implementing a CMDB

IT shops implementing configuration management databases (CMDBs) should take precautions to ensure project success, prevent unnecessary project delays, and speed time-to-value. This article focuses on six of the most common pitfalls to avoid when implementing a CMDB.

Pitfall 1: Failing to identify the goals and benefits of a CMDB.

A CMDB manages configuration items (CI) and relationships in your environment that are critical to your business services. These items can be services, software, hardware, systems, operating systems, applications, databases, functional roles, process documents, security documents, network components and more.

The importance of given items and relationships varies from one organization to the next, but the CMDB cannot, and should not, manage every asset, document, or process throughout your entire enterprise. In this broad landscape, do not lose sight of the specific goals and benefits that apply to your own organization.

If you know how a CMDB can be used, such as understanding the impact of change, you can conduct a cost-benefit analysis that measures project objectives against the cost of CMDB purchase and implementation. Having clearly defined short-term goals and long-term plans is critical to the initial stages of a CMDB project. If you fail to properly define the goals and quantify ROI, you may have difficulty gaining management approval.

Pitfall 2: Turning your CMDB into a metadata dumping ground.

There is a difference between what can be managed in a CMDB and what should be managed in a CMDB in order to derive maximum business value. Organizations sometimes initiate their CMDB implementations by indiscriminately dumping all the data from all of their CI repositories into their CMDB, without adequately documenting relationships or managing change for the CIs.

Your CMDB should contain only those CIs that you plan to actively manage. If you dump data into the CMDB without a plan, you will quickly find yourself with a repository that is hard to manage and provides little value. When CIs are actively managed, you can perform impact analysis to understand the risks associated with current outages and pending changes in the environment. This is a crucial step in realizing value from your CMDB initiative.

Pitfall 3: Ignoring the need for effective change management.

Without an effective change management process, a CMDB will soon be out of sync with reality. Thus, the CMDB and configuration management processes must be tightly aligned to the change management process. Only authorized changes should be incorporated into the CMDB, and only CIs that are part of a request for change (RFC) should be updated. Avoiding this requirement will place the CMDB implementation on a downward spiral to failure.

Pitfall 4: Proceeding without buy-in from key stakeholders.

By their nature, CMDB implementations have a wide range of touch points within an organization. Financial, capacity and availability attributes of CIs all require input from separate departments. If key stakeholders are not involved from the beginning and if they don’t buy in to the true value that a CMDB can deliver to the organization, it will be very difficult to get them to assist in the building of a CMDB that contains all necessary attributes and relationships.