CMDB
Why 80% of CMDB projects fail (and how to avoid it)
CMDBs are one of the most failure-prone ITSM endeavours. Here are the four main causes of failure and the concrete trade-offs that make the difference.
Photo: panumas nikhomkhai on Pexels
Almost every IT department has heard of the CMDB. Many have started one. Very few have turned it into an operational tool that genuinely serves their teams.
Official numbers don't exist, but practitioners' estimates converge around 70 to 80% of projects that never reach their initial objectives. The cause is almost never technical. It's methodological, and always the same.
Too much mapping, too fast
The founding mistake is almost always here. The project kicks off with the ambition to map everything in six months: servers, applications, workstations, peripherals, contracts, licences, sometimes down to the power outlets.
Six months later, a lot of data has indeed been entered. But most of it is obsolete, poorly maintained, or never used. Nobody trusts the base, so nobody uses it. Nobody using it, nobody keeps it updated. The downward spiral has started.
The right reflex: start with a minimal scope, defined by critical business services. Which 5 to 10 services trigger a direct call from the executive committee when they go down? Map those services, their applications, their supporting infrastructure. The rest will follow, by natural extension, once the need is proven.
Confusing CMDB and inventory
Many IT leaders treat CMDB and technical inventory as the same thing. It's a conceptual confusion that costs dearly.
An inventory answers the question: "what do I have?" A CMDB answers the question: "how does it work, and what depends on what?"
The inventory is useful for finance and technical debt management. The CMDB is useful for operations, incident management, change management. The two don't serve the same uses, don't have the same model, and don't require the same level of effort.
Building a CMDB from inventory tool data produces a technical base with no operational value. It's the guaranteed disappointment at the 12-month mark.
Governance is neglected from the start
A CMDB isn't a project, it's a process.
Once the initial base is built, it still has to stay up to date.
If updates rely on manual entry, they won't hold. Operational teams have other priorities. Within a few months, the data diverges from reality, and the base loses its value.
The golden rule: updates must be automatic wherever they can be, and formalised in operational processes wherever they can't. A validated change must trigger a CMDB update by design, not by goodwill.
Concretely, this means that before placing the first CI in the base, you must have mapped the sources of truth (Active Directory, monitoring tool, inventory tool, contracts), defined the automatic feed flows, and identified the grey zones requiring human input.
No defined target uses before building
This is the most invisible error, and the most structural. A CMDB is built without precisely defining what it will be used for.
Typical uses are many: incident resolution support, change impact assessment, regulatory compliance, capacity analysis, contract management. Each of these uses requires a different model, different attributes, different relationships.
Building a universal CMDB that serves all uses is impossible. The base becomes either poor (only the common minimum is recorded) or unmanageable (it accumulates every requirement). Both fail.
The right reflex: pick 2 or 3 priority uses, build the base to genuinely serve them, and extend later. It's less ambitious on paper. It's what makes the difference between a successful project and yet another failed one.
The pattern that works
If we had to summarise what distinguishes successful CMDBs, it would come down to four points.
A narrow initial scope, defined by critical business services. A simple model, aligned with 2 or 3 concrete target uses. Automatic feeding wherever possible. Formalised governance from day one, with named accountables.
The rest is secondary. The choice of tool matters less than the rigour of the approach. A CMDB built with discipline on an average tool beats a CMDB built carelessly on the best tool on the market.
To conclude
Failed CMDBs aren't fate. They are the result of repeated methodological errors, the main one being excessive initial ambition.
If you're relaunching a CMDB project after a first failure, take the time to analyse why the first one didn't hold. If you're starting your first project, look at those who have already failed before you. The lessons are there.