We ran a round-table recently on a question that keeps coming back: what is a certification actually for? ITIL v5 has landed, the training pipeline around it has changed shape, and several people in the room had moved from v4 to v5 without feeling much difference in what they could do afterwards. So we pulled the thread. What follows is my attempt to summarise where the conversation went.
I'll flag up front that these are observations rather than conclusions - the room didn't agree on everything, and I'm not sure it should have.
The frameworks are getting bigger
The first impression of ITIL v5, for most of the people who'd looked at it, was that there's more of it than v4. More concepts, more structure to hold in your head. Whether that makes it clearer to use in practice was the open question, and opinion in the room was split.
The certification path has changed alongside it. PeopleCert now supplies official course material to Accredited Training Organisations, where providers previously built their own. There are reasonable arguments both ways: consistency across the market counts for something, and so did the ability of a good trainer to shape material to the room in front of them. Several people also observed that Foundation now covers less of the practice and process detail that used to make it useful as a working reference, which shifts what you can reasonably expect a Foundation-certified person to know on day one.
The upgrade path drew the most comment. Moving from v4 Managing Professional to v5 is being actively promoted, and nobody in the room could readily describe the capability uplift on the other side of it. That may say more about how recently v5 arrived than about the qualification itself.
Underneath all of it sits a tension: depth of certification versus practical applicability at our scale. New Zealand doesn't have many 1,000-seat service desks or follow-the-sun teams spanning three continents. The cost of standing up and maintaining a fully certified capability sits differently here than it does in the markets these frameworks are largely designed around. That's a question about fit rather than a criticism of the frameworks.
Frameworks that stop at their own water's edge
The conversation kept circling back to something broader than certification: the frameworks don't say much about each other.
ITIL, PRINCE2, TOGAF, SAFe. Each is comprehensive up to its own boundary and then largely goes quiet. Very little in any of them addresses how to integrate with the others. So the handoffs between the PMO running PRINCE2, the architects running TOGAF, and operations running ITIL end up being designed locally, organisation by organisation. Those handoffs are where a lot of value is won or lost, and no framework really owns them.
There wasn't much sign of that changing. Each body of knowledge appears to be growing within its own scope rather than toward interoperability. Whether that reflects commercial incentives, the practical difficulty of writing guidance that spans domains, or simply that each is authored by a different community, the room didn't settle, but the effect on practitioners is the same either way.
Change management came up as the clearest example. A rigid change process and an agile or DevOps delivery cadence tend to grind against each other. v4 made a deliberate move toward agile ways of working; v5 is reaching further toward DevOps. The open question is one of timing: does the guidance arrive fast enough to be useful? Teams tend to solve the problem locally while they wait, and once they have, the guidance is competing with something that already works for them.
AI adds another dimension. Several people made the point that the value sits less in knowing the whole of a framework and more in knowing when to reach for it and which bits apply. That sort of judgement is difficult to assess in an exam, whatever the framework.
Application versus qualification
The thread that ran through most of the discussion was a distinction: knowing how to apply a framework and holding a qualification in it are related, but they aren't the same thing.
Someone offered a boat-building analogy that stuck. Hydrostatics matters enormously if you build boats. If you sail on the weekend, what you need is confidence the boat floats and the skill to handle it, not the mathematics that keeps it upright. A lot of service management work is closer to sailing than to naval architecture, learned the way an apprentice learns: enough breadth to know where to find the detail when it matters.
The group also spent time separating "right to play" from operational value. ITIL, ISO 27001 and similar credentials appear in RFPs as hygiene requirements, boxes procurement needs ticked before a conversation can start. That's a real commercial pressure, and reason enough to hold the certifications on its own terms. It's simply a different axis from whether the work gets delivered well, and the two are easy to conflate.
A related pattern is frameworks being adopted as labels. An analyst house names a thing, and organisations take it on wholesale, sometimes because it fits and sometimes because it's now the defensible choice. "Agile with a capital A" came up as the familiar example: a set of practices hardening into an identity.
What several people found consistently effective was leading with operational reality rather than framework vocabulary. Two examples from the room:
A distribution operator engaged with a process once he understood the consequence: get the sequence wrong and the wrong pallets go on the truck. Framed as impact, it worked. Framed as "the process", it didn't.
When a warehouse shipping cluster failed, what mobilised people was describing it in operational terms, orders not going out the door, rather than in ITSM language. Which practice it mapped to wasn't the thing anyone needed in the moment.
Explaining impact tends to prompt action; explaining the framework tends to prompt polite agreement. The judgement involved, reading the situation and reaching for the right tool, is difficult to certify. That may be the honest limit of what any qualification can tell you.
Where the conversation landed
Nobody in the room was anti-framework or anti-certification, and neither am I. A framework is a shortcut to a great deal of hard-won thinking, and a certification can be a legitimate right to play. The questions that stayed open were narrower ones: how to tell a label apart from a capability, and how to size the investment sensibly for the scale we actually operate at.
If there was a rough consensus, it was that breadth plus judgement travels further here than depth of collection: knowing enough to know where to look, then describing the world in consequences rather than process names. Reasonable people disagreed on how far to take that, which is part of why I've written it down.
I'd like to hear where your experience differs from this. That's the more interesting conversation.