CMM in Problem Management ITIL V4

The Gap Between a Process and a Service

An organisation can run Problem Management to the letter of ITIL v3 and still watch the same incidents return. The process can be documented, audited, and passed, while the underlying service fails to improve. That distance between a process that conforms and a service that gets better is the gap operational maturity work exists to close.

The gap becomes visible in any major incident review that goes beyond the immediate fix. The room has run through what broke, who fixed it, and how long it took. The harder questions sit outside the incident timeline. Has this happened before, in a different form, on a different system, under a different name? Is there a Known Error that should have caught it earlier? Is the team’s ability to detect recurring risk improving, or does it only feel that way because the last quarter’s report looked tidy? A conformant process does not answer these questions, and answering them is the work of operational maturity.

What ITIL v3 Defined

ITIL v3’s Problem Management process rested on a sound understanding. It recognised that some problems arrive because incidents force them into view, while others have to be sought out before they cause any incident at all, and it gave that understanding a formal shape in the split between Reactive and Proactive Problem Management. It defined a lifecycle: detection, logging, categorisation, investigation and diagnosis, workaround, the raising of a Known Error, resolution, and closure. Organisations that ran it properly got real value from it.

A defined process, run to specification, confirms that the activities happened. It says nothing about whether the organisation’s capability to detect problems before they became incidents was improving over time, or whether the same team was performing the same reactive investigation, competently, quarter after quarter. That distinction between conformance and capability is the gap. It is also the distinction the v3 process, on its own, could not make visible.

Measuring Maturity with CMM

The Capability Maturity Model, borrowed into ITIL practice from software engineering, describes maturity as a climb: from ad hoc and reactive, through defined and managed, up to a level where improvement itself becomes proactive and measured. Applied to Problem Management, it asks whether the organisation’s detection of recurring risk is getting measurably better, on purpose, over time.

CMM turns the gap into something that can be assessed. A team can be placed on the climb, its current level described, and the distance to the next level made explicit. A Problem Management gap analysis rests on that assessment. It locates where a service sits between reactive firefighting and proactive maturity, and it sets out what moving up requires.

In Practice at Computacenter’s Operational Command Center

Inside operationally serious environments, that assessment was already being made and acted on well before ITIL 4 existed to sanction it. At Computacenter’s Operational Command Center in Hatfield, Problem Management maturity work went well beyond running the v3 lifecycle to specification. Proactive trend analysis, dashboarded Known Error visibility, and structured Root Cause Analysis standards were built and continuously refined. It ran as an ongoing discipline, applied consistently and treated as a capability the operation kept advancing. This was CMM thinking in daily practice: a deliberate move from reactive firefighting toward proactive maturity, tracked and pushed forward as an operational capability.

The work was built because the operational stakes were real. Service reliability under ISO/IEC 20000 scrutiny made “we ran the process” an insufficient answer to “is this actually getting better.” The operation was meeting the demands that serious operational maturity imposes, and the standard eventually caught up to describe what had been built.

What ITIL 4 Formalised

v4’s restructuring of Problem Management reflects the maturity that practice had already built. The reactive and proactive split survived. It was folded into a broader activity called Problem Identification, which also draws on supplier data and risk assessment, and it now sits within a three-part structure of Identification, Problem Control, and Error Control. The practice guidance states plainly what mature operations already knew: most teams handle the reactive side reasonably well, under-invest in the proactive side, and find that closing that gap is where the real maturity work lives.

v4 also changed how Problem Management relates to its neighbours. The v3 model treated it as a self-contained process with formal handoffs. v4 describes it as one practice among many, expected to collaborate continuously with Incident Management, Change Enablement, and Knowledge Management. In setting this out, the standard documented how the practice already operated. Any Problem Manager running proactive trend analysis across a multi-vendor environment was already inside that collaboration, chairing CAB discussions, feeding Known Errors into Change, and briefing the Service Desk on emerging patterns, because the discipline never worked in isolation, whatever the process diagram implied.

A Gap Analysis Approach for New Clients

ITIL 4 gives a new client a vocabulary and a structure for proactive maturity, and a gap analysis turns that structure into an assessment of their specific operation. Our consultants begin by establishing where the client’s Problem Management currently sits: how reactive and proactive work are balanced, whether recurring risk is being detected before it becomes an incident, and whether the capability to do so is improving or holding still.

From that baseline, the work is straightforward to describe. We identify the distance between the client’s current maturity and the level their service commitments require, then set out the specific changes that close it: trend analysis that surfaces recurring patterns, Known Error visibility that reaches the people who need it, Root Cause Analysis standards that hold across vendors, and the measurement that shows whether any of it is working.

Newer or less mature teams gain the most from this. The maturity that larger operations built over years, through whoever was willing to push past what the v3 process technically required, can instead be approached deliberately, with the gaps named in advance and the improvements sequenced against the commitments the service has to meet.

Working with Typeface

Typeface helps IT organisations raise the maturity of their ITIL practices, from Problem Management through the wider service lifecycle. If your processes run to specification but recurring incidents keep returning, a maturity gap analysis will show you where your practice sits today and what it takes to close the distance. Our consultants have done this work inside large, demanding operations, and we would be glad to do it with you. Get in touch to start a conversation.