The first thing I would like to do is acknowledge the work of PeopleCert and all its collaborators (both internal and external) for the effort and investment required to keep this globally referenced and much‑loved body of good practices alive and relevant. In this world, fortunately, we can agree on some things and disagree on others; however, as we often say, “Give Caesar what is Caesar’s”. Thank you, and let’s keep moving forward.
So here we go:
When I started working with ITIL at the beginning of the century, in the middle of Version 2, the conversation revolved around processes, manuals, and accreditations. Over the years, and after participating in both large and small transformations, I learned that services are sustained less by documents and more by the ability to orchestrate people, technology, workflows, and relationships. That’s why, every time an evolution of ITIL appears, I hold back the enthusiasm and ask myself calmly: What truly changes for those of us working on the ground? What practical value does it bring to someone who must create, operate, and improve services today?
The latest iteration, presented as ITIL (version 5), does not break with the logic of ITIL 4; instead, it refines it, makes it more explicit, and updates it to an increasingly digital environment. Essentially, ITIL reaffirms itself as a value system that helps turn demand and opportunities into outcomes for stakeholders, integrating guiding principles, governance, a value chain, management practices, and a continual improvement approach. This structure, the ITIL Value System, is not a slogan; it is, in fact, the component that has best withstood the test of time because it forces us to think about services as a coordinated system and not as a menu of isolated processes.
At the same time, it maintains (and reinforces) the idea of viewing services from four dimensions: organizations and people, information and technology, partners and suppliers, value streams and processes. It’s difficult to overstate how useful this framework is when diagnosing why a service doesn’t “flow,” as it is rarely a purely technical issue; it is often a tension between culture, third‑party agreements, and workflow design. This holistic perspective is not new, but it is necessary, and the new version brings it clearly to the forefront.
The most tangible part of the update is the formalization of the product and service lifecycle. In real‑world practice, we all knew that a digital product and the service that surrounds it develop and evolve in parallel; now ITIL turns this into an explicit model with eight activities that can be combined iteratively and non‑sequentially: discover, design, acquire, build, transition, operate, deliver, support. The value of naming and organizing these activities does not lie in “forcing” the organization into a diagram, but rather in honestly mapping how work actually happens and where the flow gets stuck. In a bank with distributed development and business teams, for example, discovery and design coexist with frequent releases, while support and operations incorporate automation and observability; the model helps make that reality visible to manage it better.
I also find it appropriate that the conversation around value goes beyond the traditional SLA. ITIL does not abandon the concepts of “utility and warranty” (what the service enables and how it meets its commitments), but strongly adds two aspects that are indisputable today: user experience and sustainability. A multichannel support service may technically “meet” the SLA, but if the experience is erratic, or the operating model is environmentally and socially unsustainable, the perceived value drops. Centering these factors is not cosmetic; it forces us to design and operate with a more complete compass.
Anyone who has lived through serious incidents knows that the conversation between provider and consumer is rarely simple. ITIL maintains a rigorous definition of service relationships, distinguishing roles (sponsor, customer, user), outcomes, costs, and shared risks. This granularity is key when negotiating realistic commitments, especially in ecosystems involving hyperscalers, local providers, and internal teams. The result is a common language to discuss outcomes (what the business truly obtains), outputs (what we produce), and risks that we remove or introduce into the relationship.
At the same time, the update makes sensible adjustments to the conversation about practices. ITIL still lists 34 practices but emphasizes that a practice is an adaptable organizational capability, not a rigid process (something we already knew, of course). This distinction prevents the framework from becoming a factory of artefacts. In my experience, when a team adopts “incident management” as a capability (trained people, appropriate tools, useful data, agreements with third parties, collaborative habits) the improvement is sustained; when it is adopted as a “procedure,” the improvement is fleeting.
Another necessary update is the explicit incorporation of artificial intelligence, including GenAI and agentic approaches. The documentation makes no magical promises; it refers to automated testing, smart ticket routing, predictive monitoring, or self‑healing, but highlights an idea I fully subscribe to first optimize, then automate. Automating a bad workflow only scales the disorder. Value appears when AI and automation rest on reliable data, simplified designs, and clear governance on risk and ethics.
That said, it’s important to avoid idealization. No framework is free from commercial dynamics. ITIL evolves and renews itself because the training, accreditation, and knowledge industry requires it. I don’t see this as a problem in itself, because the key question is whether the evolution provides more clarity and practicality to those who operate services. My view is that it does: the value system provides coherence, the four dimensions force systemic thinking, the lifecycle moves us beyond linear views, and practices are understood as capabilities. All of this enables better conversations between technology, business, and partners, which is ultimately where services are won or lost.
Even so, ITIL is not a total solution, nor does it intend to be. It is one piece of a broader management system. In sectors with changing market demands, diverse organizational cultures, and multiple frameworks coexisting (Agile, Lean, DevOps), the sensible approach is not to “implement ITIL” as if it were a packaged product, but to use its architecture as the shared backbone and complement it with practices for discovery, human‑centered design, cultural change management, and portfolio governance. Otherwise, we risk falling back into the trap of process‑for‑process‑sake, where indicators move but value does not appear.
At this point, it’s worth pausing to address the most common reality. Today, many organizations continue using ITIL almost exclusively for the basics (the classic, the usual. Incidents, requests, changes, and, with some luck, a service catalog, an asset management practice, or some minimal configuration management) and they will continue to do so. The goal is not to criticize this, but to understand why it happens and how it fits within this evolution. In practice, these organizations find in ITIL a way to organize operations, reduce chaos, improve response times, and bring a certain level of predictability to services that previously depended too much on goodwill or daily improvisation. And, realistically, that alone is a lot.
The contribution of the latest version of ITIL is that it allows (if the organization chooses to take advantage of it) that classic approach to coexist with a broader vision centered on digital products, value, experience, and sustainability. It does not require abandoning what works; it expands it. It offers an evolutionary, not disruptive, path. For those who want to keep ITIL on the defensive perimeter (support, operations, and resolution) the update remains useful. For those seeking to move toward more transversal, business‑connected, lifecycle‑oriented management, ITIL now offers a clearer map. In both cases, the organization benefits.
I think, for example, of a retail company launching a new international e‑commerce platform. The product team works in two‑week sprints; operations run on multiple clouds; suppliers vary by country; and customer care is partially outsourced. Does ITIL help? Yes, if it’s used to align principles (“focus on value,” “collaborate and promote visibility,” “think and work holistically”) and to organize the flow between discovery, design, transition, operation, delivery, and support, measuring outcomes that matter to the business. Does it not help? No, if it’s interpreted as a list of processes to follow without context or judgment. In that case, ITIL becomes another dead weight, far from its original intention of being an adaptable value system.
In the financial world, another frequent example is the modernization of a payments platform. Here, ITIL helps make dependencies explicit, such as regulated changes, transition windows, continuity requirements, reliability and experience metrics. The availability practice connects with capacity and performance; incidents and problems feed off observability; service level management is redesigned with metrics customers actually perceive. Without this structured conversation, areas fall into metric wars; with it, there is at least a shared framework for negotiating commitments and prioritizing.
Another strength of the update is its reminder that continual improvement is not a ceremony but an organizational habit. The seven‑step model is so simple that it is often underestimated, but in delivery‑pressured cultures, it is the only antidote to turning daily work into an endless loop of urgencies: vision, honest assessment of the current state, clear targets, realistic planning, disciplined action, data‑based verification, and (most importantly) anchoring the learning so it’s not lost. Without anchoring, any improvement is short‑lived.
So where does this latest evolution of ITIL leave me? In a serene place. As an ITIL Ambassador, I appreciate that the framework has matured toward a more realistic product‑service vision, reinforcing systemic thinking, addressing experience and sustainability properly, and treating AI with both ambition and prudence (which I especially welcome, considering the recent exaggerations and hype surrounding “the possibilities of AI”). I also recognize that it does not resolve on its own the dilemmas of culture, leadership, purpose, or change narrative that determine whether a service is adopted, embraced, or abandoned. Daily practice reminds us that no framework replaces good judgment.
I genuinely hope this article has been useful and helps clarify a few points. I like the evolutionary approach, but I like even more being able to speak clearly and not from mere commercial excitement. I have seen, lived, and worked (suffering and enjoying) through practically every version that has existed, and I can share all this (and more) from an honest, straightforward point of view. That matters far more to me than anything else.
Oh! I want to close with a personal note. In the coming weeks, I will create and share the practical exercise “How to implement ITIL using the #ARTEMethod”, with cases and design decisions that translate the framework into real work. My aim will not be to reproduce manuals but to show the path (with its shortcuts and its limits) so that ITIL becomes real value and not just good intentions… because after so many years in the trenches, it has to count for something, and in some way, I need to honor all that I’ve built in my life around this (and many other approaches).
I truly appreciate you making it all the way to the end; it genuinely means a lot to me to be able to share my perspective and some reflections with you.
I hope you have a great week (always)! ✌🏻😊