The previous configuration management lead understood how the CMDB connected to incident, change and problem management, because those processes were part of the role. The replacement was hired mainly on cost, and mainly against the job title, without that wider understanding being part of the brief. Within months, the CMDB stopped meeting the needs of the processes around it, and it cost over $100,000 in consulting fees to put right.
Key Takeaways
- The replacement configuration management lead was hired mainly on cost and job title, and the brief didn't cover how the configuration management database connects to incident, change and problem management. Within months it stopped meeting the needs of those processes.
- Configuration management isn't a standalone role. The database feeds change impact analysis, incident routing and problem management's root cause work.
- The gap showed up outside the process first. Incidents took longer to resolve, more changes failed and the other processes complained the data had become unusable for their purposes. An audit of configuration management alone would have found a process working as designed.
- Putting it right cost the client more than $100,000 in consulting fees. Apex then took over running the process as a managed service.
- A good lead checks data against downstream use, sits in on incident and change conversations, and treats complaints from other processes as defects in configuration management's output.
- The managed service builds the cross-process check into the operating model, through a combined metrics review, monthly governance sessions with incident and change stakeholders, and quarterly re-validation against downstream requirements.
The assumption behind the original decision is worth naming directly, because it's more common than the outcome suggests. Configuration management gets treated as a standalone process, separate from what a CMDB is for and how it fits into the rest of ITSM, and the person running it isn't expected to understand the processes it feeds.
Why the role isn't standalone
Configuration management doesn't exist for its own sake. The CMDB feeds change impact analysis, incident routing and problem management's root cause work. A configuration management lead who understands only their own process, and not what incident and change teams need from the data, will keep the database technically maintained while it quietly stops serving the processes around it.
That's what happened here. The new lead ran the configuration management process competently on its own terms. Data got entered. Records got updated. What didn't happen was any judgement about whether the data was shaped the way incident management needed it, or whether change impact analysis could actually rely on it.
None of this would have shown up in a review of the configuration management process on its own terms. Data entry was timely. Fields were populated. Anyone auditing configuration management in isolation, against its own procedures, would have found a process working as designed. The defect only became visible from outside the process, in the processes it was meant to serve, the same governance gap behind why unknown CI owners drive up IT spend more broadly.
How the gap showed up
The first signals came from the processes that depend on the CMDB, not from configuration management itself. Incidents took longer to resolve, because the dependency data incident teams needed to trace impact wasn't being maintained with their use case in mind. More changes failed, for the same underlying reason: the impact analysis behind them was working from data that had drifted from what change management actually needed.
Multiple complaints followed, from the ITSM processes that depend on the CMDB, that it had become unusable for their purposes. That's a telling detail. The configuration management process wasn't failing on its own terms. It was failing the processes it was supposed to support, which is a harder gap to see from inside the role.
There was no mechanism in place that would have surfaced this earlier. Configuration management reported its own metrics, on its own schedule, to its own stakeholders. Incident management reported separately. Change management reported separately again. Nobody was reviewing the three side by side, so a configuration management dashboard that looked healthy in isolation could sit next to a rising change failure rate for months without anyone connecting the two. The gap wasn't hidden. It just wasn't anybody's job to look for it across the boundary between processes, which is precisely the boundary a configuration management lead is supposed to be watching.
What it cost to put right
The client brought in Apex to rectify the mistakes, at a cost of more than $100,000 in consulting fees. That figure is the cost of correcting data and process drift that a configuration management lead with wider ITSM understanding would most likely have caught and corrected as it happened, rather than letting it accumulate to the point of multiple process complaints.
After the initial rectification, Apex took over running the configuration management process as a managed service, rather than the client repeating the same hiring decision. That choice was a direct response to what had gone wrong. The process needs someone who understands the wider ITSM landscape on an ongoing basis, not just at the point of a one-off fix.
What good configuration management leadership actually requires
A configuration management lead who serves the wider ITSM function does a few things differently from one who runs the process in isolation:
- Checks data shape against downstream use, not just against the process's own rules. Whether a relationship, attribute or status field is correct isn't only a configuration management question. It's whether incident management can use it to trace impact and whether change management can use it for risk assessment.
- Sits in on incident and change conversations, not just configuration management ones. Understanding what's slowing incident resolution or causing failed changes means being close to those processes, not inferring their needs from a distance.
- Treats complaints from other processes as configuration management defects. If incident management says the CMDB is unusable for their purposes, that's a finding about configuration management's output, whichever team happens to raise it.
None of this requires the configuration management lead to run incident, change and problem management themselves. It requires understanding what those processes need from the data well enough to keep providing it, which is exactly what the job description missed the first time around.
What the managed service does differently
When Apex took over running configuration management for this client, the point wasn't simply to have more experienced hands on the process. It was to put a structural check in place that would have caught the original drift before it reached three months of complaints.
- A cross-process metrics review. Incident resolution time, change failure rate and configuration data quality are reviewed together, on the same cadence, by the same group, so a configuration management metric that looks fine next to a worsening change failure rate gets treated as one finding rather than two unconnected line items.
- Monthly governance sessions with incident and change stakeholders in the room. Rather than configuration management reporting outward and waiting for complaints, the people who depend on the data are in the review, so a shift in how they're using the CMDB surfaces as a discussion point rather than an escalation.
- Quarterly re-validation against downstream requirements. What incident and change management need from the data doesn't stay fixed. A field that was sufficient a year ago may not be, once a new integration or a reorganised support structure changes how it's used. The quarterly check exists specifically to catch that kind of drift before it accumulates.
None of these three mechanisms is complicated on its own. What they have in common is that they don't rely on someone in the configuration management role noticing a gap in the processes around them, unprompted. They build the cross-process check into the operating model itself, so it happens whether or not the person running configuration management would have thought to go looking for it.
What this means for your next configuration management hire
If you're hiring for the role, or reviewing whether your current setup is working, the useful question isn't whether the person can run the configuration management process. It's whether they understand incident, change and problem management well enough to know when the data they're maintaining stops serving those processes, before those processes start telling you.
How Apex helps
We run a CMDB health baseline over two weeks that scores whether your configuration data is actually meeting the needs of the processes around it, not just whether it's internally consistent. The output is a report you can take to your change advisory board, or to whoever's making the next staffing decision.
Talk it through on a CMDB diagnostic call, or book a meeting with the team directly.
Frequently asked questions
Is this an argument against hiring for cost?
Cost is a legitimate factor in any hire. The issue is treating configuration management as a role that can be filled on job title and cost alone, without checking for understanding of the wider ITSM processes it feeds. That understanding is what prevents the kind of drift described here.
How would you notice this kind of drift before it causes complaints?
Track incident resolution time and change failure rate alongside configuration management's own metrics, not separately from them. If those start moving in the wrong direction without an obvious cause elsewhere, the CMDB's fitness for those processes is worth checking directly.
Why did Apex take over as a managed service rather than just fixing the data once?
A one-off fix corrects the data at a point in time. The original problem was a person in the role without the wider ITSM understanding needed to keep it correct. Running it as a managed service addresses that ongoing need directly, rather than leaving the client to make the same hiring decision again.
Does a managed service replace the need for an internal configuration management owner?
No. It replaces the need to have internal staff carrying the full operational and cross-process understanding day to day. Governance and accountability for the CMDB still sit with the client; Apex runs the process itself.
Written by Iain Moone, Apex Configuration Group.
Book a free call to discuss how Apex can help you on your journey to a better CMDB
