It may sound childlike, but a good place to start before putting any metrics in place is to ask,"Why?" Probably the first answer at the top of most adopters' minds is because I have no choice if I'm going to sell this thing. Other bad reasons to establish metrics include to justify the cost of the CMDB project and to provide an absolute yardstick of CMDB success. While both of these motivators may sound good politically, they create a false notion of how value can be directly measured around a CMDB System.

But there really are good reasons if you look more closely, and by setting expectations about how you're going to proceed correctly up front, you can save yourself from a world of pain in the end.

I strongly believe that the best reason for CMDB System metrics — internal/external, hard, soft, and in-between — is to make sure that you are making pragmatic cost choices (e.g., tools, staffing, etc.) along the way.

While your CMDB System initiative shouldn't be viewed, strictly speaking, as a "project" with a set beginning, middle, and end, you will need to begin by creating a plan that can provide a foundation for the evolving system. That means establishing general metrics and developing those into more granular metrics and requirements — along with addressing other key factors, such as projected costs; team, architectural, and technology needs; and process and communications plans.

The place to begin with setting metrics and milestones for a CMDB System is in planning its phases with reasonable objectives and scope, and well-thought-out expectations for efficiency — even if political pressures try to steer you otherwise.

It's tempting to shoot for the moon with hard dollar value for a CMDB initiative. There's likely to be plenty of political pressure to create metrics that show "value" in hard dollars and cents. However, those metrics can be more of a Pandora's Box than a panacea for any number of reasons. Defining dollar-based metrics meaningfully requires a real appreciation for the specifics in your environment and a well thought-out set of deployment-related metrics to help you go forward.

Dialog, analysis, and consulting, all reinforce the need for the following categories for CMDB or CMS Metrics:

Metrics directed at ensuring effective milestones in the evolution of the CMDB System itself: These metrics generally divide into three areas: scope or breadth of coverage, accuracy or integrity of information, and efficiency metrics documenting improvements in the maintenance and evolution of the CMDB System.

Metrics directed at ITIL or other process improvements: These really divide into two categories — those that lend themselves to ROI or hard business impact and those that are more milestone-like in supporting a more collaborative and effective way of working across IT. The use cases described in my previous blog all have their own set of metrics — spanning Change Impact Management and Change Automation, Asset Management and Financial Optimization, Service Impact Management and Capacity Optimization, and other areas such as IT Governance and Risk Management.

Some Internal Metrics

The metrics listed below are targeted at supporting the CMDB/CMS team as it manages the CMDB deployment. As such, they should be communicated horizontally to stakeholders across the organization, as well as upward to management and downward to constituents. This is only a partial list but it should help you get the idea.

Metrics for Scope

■ Have all appropriate stakeholders been identified and committed?

■ What's the percentage of Configuration Items (CIs) with identified owners?

■ What percentage of trusted sources or sources of record have you identified and confirmed for inclusion in the CMDB System in Phase One?

■ What percentage of CIs are loaded and under management based on phase-relevant objectives?

Metrics for Accuracy and Integrity

■ Number of failed requests for change from bad CMDB data

■ Number of failed changes caused by poorly documented CIs

■ Number of breached SLAs because of CMDB errors — including missing items, misleading relationships, and poor escalation because CIs are not linked to the appropriate SLA

■ Number of requests for change without corresponding CI updating

■ Percentage of "inaccurate" CIs

■ Number of incidents due to inaccurate CIs

■ Number of missing or duplicate CIs

■ Number of changes to the CMDB per month due to identified errors with the CMDB System

Metrics for Efficiency

■ Percent of CIs that are discovered or updated automatically

■ Percent of CIs that are synchronized and reconciled automatically

■ Percent reduction in the cost of maintaining CI data

■ Percent of cost reduction in extending the CMDB System to include new, critical CIs, or CI attributes (through improved technology choices, deployments, and/or team processes)

Note that even in the first stages of planning for CMDB/CMS efficiencies, automation is present. At EMA, we have seen too many initiatives get bogged down in poorly phased rollouts that continually seek to expand scope without incorporating higher-level efficiencies for administration — whether for discovery, data reconciliation and normalization, or analysis to generate reports. The good news is that all these areas are experiencing positive transformations of their own due to new technologies and other advances.

So, if there's a single message to take away from this blog, it is to create metrics that work for you rather than constrain you. Metrics that you've committed to because of political pressure are likely to be even less effective than a pork-bellied compromise in Congress. If you've done your homework in terms of your environment, its readiness, and its needs, then the metrics you know you can live withare the ones that will lead to success.

In Part Two of this blog — CMDB Metrics - Part Two — we look at some of the external metrics you might consider, as well as a few guidelines for tackling TCO and ROI.