Somewhere in your organisation there is a system that is not on anyone’s product roadmap, is not owned by any business function, was written or bought a long time ago, works well enough on an ordinary day, and would stop the company if it failed on a bad one.
Nobody is against it. There is no meeting where a person argues that it should stay as it is. It simply never wins an argument for funding, because it is not anyone’s product — it is infrastructure, or a tool, or “the scheduling thing.” When the operations director asks for money, they ask for aircraft, or warehouses, or people. When IT asks for money, it asks for the platform migration the board has already heard about three times.
ITIL Version 5’s most consequential change is that it stops pretending this is not a problem.
The scope change, stated plainly
ITIL now describes itself as a framework for digital product and service management. The official framing of the evolution is a four-step arc: IT infrastructure management, then IT service management, then service management, and now product and service management.
The reasoning is set out bluntly in the launch material: “the traditional separation of product and service silos has become a liability for organizations.” Products and services are presented as “two sides of the same, digitally-enabled technology solution,” and — for the first time in the framework’s history — “the digital product lifecycle has a dedicated place.”
The structural evidence backs the rhetoric. The Technical Management practice category has been abolished. Deployment Management, Infrastructure and Platform Management, and Software Development and Management have moved into the Product and Service Management group. So have Information Security Management and Service Financial Management, which were previously General Management practices. Twenty-two practices now sit in the product and service group against twelve in general management.
Read that list again and notice what it means. Building software, running infrastructure, deploying changes, securing the thing and paying for the thing are now all categorised as part of managing the product. They are not adjacent disciplines that service management interfaces with. They are the same job.
ITIL Product (Version 5) is explicitly described as role-agnostic — aimed at “product owners, team leads, managers, architects, designers, developers, engineers, and site reliability engineers.” That is a deliberate refusal to let the framework be filed under “the run function,” which is where, as Barclay Rae has pointed out, ITIL has historically been left to sit in too many organisations.
What the framework does not give you
I want to be honest about a gap, because you will find it the moment you try to act on this.
ITIL 5 tells you that products and services should be managed as one thing. It does not tell you how to fund them as one thing. I looked for guidance on product funding models, capacity-based funding, or a named product operating model, and I could not find any. Service Financial Management moving into the product group is suggestive, but suggestive is not guidance.
This matters because funding is where the product model usually dies. An organisation can rename its teams, appoint product owners and run a quarterly business review, and still allocate money in annual project tranches to named deliverables. When it does, the product owner discovers that they own the roadmap for something they cannot fund, and the whole exercise becomes vocabulary.
If you are going to adopt the product framing, the finance conversation is the one that decides whether it works. ITIL 5 will not have it for you.
Ten days in December
Winter Storm Elliott arrived over the United States on 21 December 2022. Every major American carrier cancelled flights. Every major carrier except one recovered within a few days.
Southwest Airlines cancelled more than 16,700 flights over the following ten days and stranded over two million passengers. On 25 and 26 December alone it cancelled over 5,500 flights. Delta cancelled 311.
The storm was the trigger. It was not the cause, and both the US Department of Transportation and Southwest’s own review were clear about that distinction.
The mechanism
Southwest ran two in-house systems for crew scheduling: SkySolver for crew optimisation and Crew Web Access. When cancellations exceeded a certain volume and — critically — a certain geographic dispersion, SkySolver could not converge on a solution. It effectively fell back to manual re-crewing.
Southwest flies point-to-point rather than hub-and-spoke. That is a genuine commercial strength on an ordinary day and a severe liability in a recovery, because crews and aircraft end up scattered across dozens of stations rather than concentrated at a handful of hubs. The optimisation problem the software could not solve was therefore much larger than it would have been at a hub-and-spoke competitor.
What happened next is the part that should frighten anyone who runs an operation.
With the optimiser out of the picture, thousands of crew members had to telephone Crew Scheduling to be reassigned. Hold times exceeded five hours. Crew members reported falling asleep on hold and waking to find themselves still on hold. Overwhelmed schedulers assigned crew to flights that had already been cancelled, which consumed those crews’ legally limited duty hours and prevented them operating flights that were still viable.
The airline lost positional awareness of where its own crews were.
On 26 December, Southwest executed a systemwide reset: pre-emptively cancelling roughly two-thirds of its schedule for several days, purely to re-synchronise crews and aircraft.
The cost
Southwest’s own figures, filed with the SEC: approximately $800 million pre-tax negative impact in the fourth quarter — around $410 million of lost revenue and $390 million of additional operating expense covering customer reimbursements, goodwill loyalty points, premium pay and additional employee compensation. The quarter closed with a $220 million net loss. By December 2023 the airline had paid around $600 million in refunds and reimbursements.
In December 2023 the DOT imposed a $140 million penalty — the largest consumer protection penalty in its history, and by its own description thirty times larger than any it had issued before. The order cited inadequate customer service, failed flight-status notifications and delayed refunds. Secretary Pete Buttigieg’s framing was: “Taking care of passengers is not just the right thing to do — it’s required.”
The sentence that explains everything
Southwest’s own review, validated by external consultants, described the crew optimisation software as having “a functional gap that was revealed in December.”
I have read that sentence many times. It is doing a great deal of work.
A functional gap that was revealed in December. Not created in December. The gap had been there for years. Southwest’s own people had raised concerns about crew scheduling technology repeatedly before 2022; the pilots’ union had been public about it. The software behaved exactly as it always had. December simply presented it with an input outside the envelope it could handle, and the envelope had never been widened because widening it was never anyone’s product decision.
Here is the operating model question. Who owned SkySolver?
Not the network planning function, which owned schedules. Not the crew function, which owned rosters and duty rules. Not IT, which kept the servers running and the software patched and had no mandate to decide that the optimisation engine needed rebuilding. It was a tool. Tools have custodians, not owners. Custodians keep things going. They do not commission replacements.
That is the silo ITIL 5 is aiming at. Not the silo between two IT teams — the silo between the people who decide what a capability should be able to do and the people who keep it running.
What Southwest did afterwards
The remediation is instructive because it is exactly what a product model looks like when it arrives late.
Southwest budgeted $1.3 billion of IT investment for 2023, including crew optimisation software upgrades and crew and customer phone systems with, in the company’s words, “better surge protection.” It bought de-icing trucks, expanded de-icing fluid capacity, and built a real-time weather application for holdover-time calculation.
Then it did the two structural things. It consolidated Network Planning and Network Operations Control under a single senior leader — collapsing exactly the accountability gap described above. And the board created an Operations Review Committee.
A board committee. For operations. At an airline. That is what it took.
Six questions worth asking this quarter
If you want to act on the product and service framing rather than adopt its vocabulary, these are the questions I would put to your leadership team.
Which of our critical capabilities have a custodian but no owner? Make a list of systems that are essential, that nobody would defend cutting, and that have not had a funded improvement in three years. That list is your exposure.
What is the envelope? For each of those, what is the load, volume or dispersion beyond which it stops working? If nobody knows, that is the answer — you have a system whose failure mode will be discovered by an event rather than by a test.
When the automation gives up, what happens? Southwest’s automated process degraded into a telephone queue with a five-hour wait. The degraded mode was never designed; it was simply whatever was left. Design your degraded modes deliberately and measure their throughput.
Who is accountable for the whole lifecycle of this thing — including retiring it? Not who runs it. Who decides what it should become.
Does the money follow the product or the project? If a product owner cannot fund a change without assembling a business case for a capital project, you have named a role and changed nothing else.
What have our own people already told us? Southwest’s crew had been raising crew-scheduling problems for years. In almost every failure I have investigated, somebody inside the organisation had written the warning down. The failure was not of information. It was of a route by which that information could reach a budget.
The honest summary
ITIL 5 has made a correct diagnosis. The separation between building things and running things is a liability, and the framework’s structure now reflects that — twenty-two practices in the product and service group, the technical category dissolved, security and finance brought inside.
It has not supplied the operating model or the funding model that would make the diagnosis actionable. That is your work, and it is mostly not IT work. It is a conversation between the CIO, the CFO and the business function that depends on the capability, about who owns a thing for its whole life rather than who keeps it alive this year.
Southwest had every framework available to a Fortune 500 airline. What it did not have, in December 2022, was a person whose job was the crew optimisation product. Eight hundred million dollars, a $140 million penalty and a new board committee later, it does.
The funding gap, and how it actually kills the model
I said above that ITIL 5 does not give you a funding model. It is worth being concrete about why that matters, because this is where most product transitions quietly fail.
In a project-funded organisation, money is allocated to named deliverables with defined end dates. That works well for building something new. It works badly for owning something, because ownership is continuous and projects are not. The observable symptoms are always the same:
- Improvements to existing capabilities can only be funded by inventing a project, so they are bundled into unrelated programmes to get through the approval gate.
- Anything that reduces risk but delivers no new feature — a rebuilt optimiser, a resilience upgrade, a decommissioning — has no natural sponsor.
- The team that built the thing disbands at go-live, and the team that inherits it has no budget to change it, only to run it.
- Technical debt accumulates in exactly the systems nobody would defend cutting, because they are essential and therefore boring.
That is a precise description of how a crew scheduling system reaches December 2022 with a known envelope nobody has widened.
The fix is not complicated to describe and is politically hard to do: fund a persistent team against a capability, with a standing allocation, and hold them accountable for outcomes rather than deliverables. Service Financial Management moving into ITIL 5’s product and service group at least puts the two questions in the same practice group. It does not have the conversation with your CFO.
The integration gap: acquisitions have no product owner either
One further case, because it is the same failure in a different costume.
In February 2024, attackers used compromised credentials against a Citrix remote access portal at Change Healthcare that did not have multi-factor authentication enabled. UnitedHealth’s own corporate policy required MFA on externally facing systems. Change Healthcare had been acquired in 2022 and had not been brought onto the parent’s security standards two years later.
Initial access on 12 February. Nine days of lateral movement and exfiltration. Ransomware on 21 February. Because Change Healthcare processes roughly a third of US medical claims, the outage stopped claims processing, eligibility verification, prior authorisation and pharmacy dispensing nationwide; small and rural providers ran out of operating cash within weeks. 190 million individuals were ultimately notified. UnitedHealth reported a $3,090 million total 2024 impact, and its CEO confirmed under oath that a $22 million ransom was paid.
Senator Ron Wyden’s summary was: “This hack could have been stopped with cybersecurity 101.”
An acquired platform in the two-year gap between purchase and integration is a product with no owner, in the purest form. Nobody in the parent is accountable for its operating model; nobody in the subsidiary has authority to change it. It runs, it earns, and it drifts. Every acquisition your organisation makes creates one of these unless somebody is named, in writing, with a date.
Sources
- ITIL.com, ITIL Product (Version 5) (product/service silos, role-agnostic scope) — itil.com
- ITSM.tools, ITIL (Version 5) vs ITIL 4: key changes (DPSM scope, practice recategorisation) — itsm.tools
- ITSM.tools, ITIL (Version 5) management practices (the 22/12 split) — itsm.tools
- Barclay Rae, ITIL Version 5 launch takeaways — barclayrae.com
- Southwest Airlines Co., Form 8-K and Exhibit 99.1, 26 January 2023 (Q4 2022 financial impact)
- US Department of Transportation, Consent Order: Southwest Airlines Co., 18 December 2023
- US Senate Committee on Commerce, Science and Transportation, hearing on the Southwest Airlines December 2022 disruption, February 2023