Home
The IT Operating Model Discovery – Part 1
ITSM without an Operating Model: Why it feels like theatre
You've invested in ITSM. ServiceNow is humming. ITIL processes are documented. SLAs are tracked. Dashboards look impressive. Cloud spend is monitored.
And yet, leadership still asks the same questions: "Who owns this service? Why are we firefighting the same issues? Why do three reports disagree?"
If that sounds familiar, welcome to ITSM theatre – where you have the costumes, the stage, and plenty of activity, but no shared script for how IT actually works.
ITSM without an Operating Model
Most organisations today "have ITSM". You’ve invested years—and significant budget in building your capability. You’ve sat through countless process workshops that felt like they would never end, hired expensive consultants to map out "best practices," and spent a fortune on platform licences for the likes of ServiceNow, HALO, or Jira. You have a shiny service portal, a fully integrated service desk, and a request catalogue that has been refined, tweaked, and polished to perfection.
And yet, despite all that investment, the same leadership team keeps asking the same uncomfortable, recurring questions:
  • Who actually owns this service? Everyone points at their neighbour when an outage hits, leaving the business to wonder why nobody is holding the steering wheel.
  • Why are we still firefighting the same issues? We track incidents with military precision, yet the root cause remains permanently elusive, hidden behind a backlog of "high priority" noise.
  • Why do three different reports show three different truths? Finance, IT, and the business all look at the same data and see a different reality.
  • Why does cloud seem to live in a different universe? Our modern cloud infrastructure operates with agility while the rest of IT is still tethered to legacy processes that haven't evolved in a decade.
  • Who decides which work gets done first? We have a queue, but does it reflect what the business actually needs, or just the loudest voice in the room?
If this sounds like your reality, stop blaming "poor process" or "the wrong tool." Those are just the easy scapegoats. You can buy the best platform on the market and hire the most certified ITIL practitioners in the country, but if you don't have an explicit IT Operating Model, you are simply automating chaos. You aren't suffering from a lack of technology; you are suffering from a lack of design.

You have the costumes and the stage – but no script everyone agrees on.
What are the characteristics of an Operating Model?
An operating model is not a buzzword. It's the answer to a simple question: "How does IT actually work here, on a Tuesday afternoon, when something breaks?"
If you can't sketch that on one page, you don't really have an Operating Model. You have folklore 😉.
In more formal terms, an IT Operating Model is the blueprint that connects your IT strategy to day‑to‑day work. It makes explicit:
  • How services are structured and delivered
  • How work and decisions flow across teams and suppliers
  • Which information and tools people rely on
  • Which governance routines keep everything aligned with risk and business priorities
When that blueprint only exists as a fuzzy idea in a few leaders' heads, your ITSM implementation is forced to carry far more weight than it was ever designed to. Tools make work visible; they don't, by themselves, decide who should do it, in what order, and under what constraints. That's the job of the Operating Model.
In my experience as a consultant, this is exactly where IT leadership feels the most exhausted: they're asked to sort out operational questions the system should already know how to handle. When every escalation lands on the CIO's desk, it's not a people problem, it's a design problem in the Operating Model.
The symptoms of your missing IT Operating Model
Symptom 1: Accountability fog and endless escalation
On paper, the modern IT organisation has reached a state of role-based nirvana. We have more titles than ever: process owners, service owners, product owners, platform leads, vendor managers, SMO leads, and an alphabet soup of governance roles to match. There is a perverse irony here: the more we clarify roles in our HR systems, the more opaque accountability becomes in the real world.
In practice, when the clock starts ticking on a P1 incident or a high-risk change, that clarity evaporates instantly. You end up with a "bridge call" filled with ten expensive specialists the Service Owner, the Platform Lead, the Vendor Manager, the Cloud Architect, all staring at the same alert, yet nobody feels empowered to actually make a decision. They aren't collaborating; they are protecting their team’s boundary, waiting for someone else to step into the blast zone.
The reason tickets bounce endlessly between groups isn't a lack of effort; it's a structural failure. Our team boundaries are drawn around technology towers, not business services. Our supplier contracts are scoped so narrowly that "inter-operability" is treated as an optional extra. Those beautiful RACI matrices we spent three months building in workshops? They were never tested under the white-hot pressure of a production outage. Without an explicit Operating Model, the only path across teams and suppliers is the one we improvise in the moment.
The cost of this is far higher than mere frustration. It’s a systemic drag on speed and a constant increase in operational risk. When ownership is ambiguous, the CIO inevitably becomes the de facto Operating Model, forced to manually resolve every conflict and stitch together processes that should have been joined by design. Ultimately, this symptom isn't about "getting better at collaboration", it's a signal that your organisation is trying to run a service-oriented business using a component-based survival strategy.
Symptom 2: Reporting that nobody really trusts
We are currently living through a paradox of data abundance and insight poverty. Organisations have spent millions on advanced BI tools, real-time platform dashboards, and slick reporting modules, yet the monthly leadership steering pack remains a battlefield. Every session starts with a 20-minute, soul-crushing argument about whose numbers are actually "right" before the team can even begin to discuss what to do about the underlying issues.
The problem isn't that you lack data; it's that you lack a shared language for what that data means. If your Operating Model is a vacuum, every team and tool is forced to invent its own reality, slicing the world through a lens that serves its immediate survival rather than the business goal:
  • The application team reports by application features.
  • The infrastructure team reports by server/platform uptime.
  • The Service Desk reports by incident volume and category.
  • The cloud team reports by consumption units (subscription/account/landing zone).
  • Vendors report by their contractual "tower" and ticket counts.
This isn't laziness or malicious intent—it’s a rational response to the absence of a shared service taxonomy. Each team is simply optimising its reporting to match its own accountability boundary, which was never designed to align with anyone else's. Over time, this erodes organisational trust. You inevitably get a two-tier governance culture: the people who "own the numbers" and the people who challenge them. This dynamic poisons the quality of decision-making, as every interaction becomes "data plus anecdotes." Governance quietly turns into performance theatre, where the goal is to survive the meeting rather than solve the service issue.
Let's be clear: this isn't a reporting problem you can fix with a new PowerBI license. It is a fundamental lack of a shared design. Until you have a common model of what IT delivers and to whom, you aren't reporting on business value; you are merely collecting disparate evidence of your own confusion.
Symptom 3: Parallel worlds in cloud and on‑prem
Most mid‑ to large‑size organisations have become hybrid almost by accident. It wasn't a master-planned strategic migration so much as an accumulation of pragmatic, individual choices: a lift-and-shift migration here, a new SaaS product there, and a cloud-native development team that grew faster than the central IT strategy ever anticipated. Most organisations didn't choose to be hybrid; they woke up one day and discovered they already were.
To cope, many create a "cloud operating model" alongside a traditional ITSM setup. In reality, this creates two parallel universes. You have the cloud/CCoE world, which speaks the language of pipelines, sprints, and guardrails; and the ITSM world, which speaks in tickets, SLAs, and change windows. Both are fundamentally "right" within their own frame of reference, but they are essentially speaking different languages about the exact same business services.
Consider the collision: a business-critical application running partially on-prem (governed by ITSM) and partially in the cloud (managed via a CCoE pipeline). When an outage strikes, the incident process, the escalation path, the tooling, and even the definition of "resolved" shift completely depending on which side of the boundary the fault sits. The business just sees an outage; IT sees a jurisdictional dispute between two cultures that don't recognize each other's existence.
A single business service appears as a "product" in one view, a bundle of platforms in another, a set of tickets and SLAs in a third, and a disparate line item in cloud spend or vendor invoices. This isn't just a reporting inconvenience—it means nobody can answer basic questions like "what is the total cost to run this service end-to-end?" or "what is the true risk exposure if this service degrades?" The data lives in incompatible models that were never designed to talk to each other.
In the absence of a shared Operating Model, the debate between cloud and on-prem often devolves into something quasi-religious. The real problem is that nobody has designed the seam between these two worlds. Without a single, coherent model to accommodate both, every hybrid organisation is quietly running two IT departments that happen to share a budget.
Symptom 4: more governance, not more clarity
When leadership senses that things are slipping, the knee-jerk reaction is almost always to tighten the screws. We assume that if we are losing control, we simply need more of it. It’s a very human, very well-intentioned instinct: adding structure feels like active leadership. We begin by forming a CAB, then realizing it’s overwhelmed, we spin up a "sub-CAB" for minor changes. A steering committee grows into a hierarchy of sub-committees, and an assurance review eventually bloats into a full-blown quarterly audit program. Every single one of these additions feels justified in isolation, designed to "close a gap" or "reduce a risk."
The cumulative result, however, is a masterpiece of bureaucratic friction. Consider the common scenario where a simple, low-risk change now requires sign-off from five distinct bodies, each created to solve a specific historic grievance. The result is a three-week lead time for a ten-minute deployment, proving that you have successfully strangled your own agility while ironically still failing to prevent the very outages the governance was designed to stop.
The fundamental mistake is assuming that governance can substitute for design. Governance is, by definition, an enforcement mechanism; it is designed to hold people to account for agreed-upon decisions and escalate exceptions to the rule. But if the underlying Operating Model is fuzzy, you haven't actually agreed on the rules. You’ve just created a forum where the same ownership questions are rereated every single month in a more formal, suit-and-tie setting.
This is what I call "governance theatre." It is motion without progress. This is often masqueraded as "ITSM maturity." We assess ourselves against global standards and celebrate our high scores because we have a well-documented Change Management process—but we forget that maturity frameworks measure the sophistication of your processes, not the clarity of your intent. You can score a 5/5 on a maturity assessment and still have a fundamentally broken Operating Model that leaks value at every handoff.
This is not a tooling problem – it's a design problem
Let me be clear: this isn't an anti-ITIL, anti-ServiceNow, or anti-framework argument. These platforms and the methodologies they embody represent decades of collective wisdom and genuine engineering excellence. When used well, they are transformative. The problem isn't the tools; it's the sequence in which we reach for them.
We have a bad habit of starting a "transformation" by discussing the technology stack or the framework certification, while the Operating Model question—how should IT actually be structured, governed, and measured?—is deferred or, worse, assumed to be answered by the tool itself. This is dangerously seductive: platforms come with pre-built process templates, role definitions, and workflow libraries that masquerade as an Operating Model. They aren't. They are a generic, one-size-fits-all starting point.
When you configure tools before you've agreed on the model, you are pouring concrete before you’ve agreed on the shape of the foundations. Every workflow you build encodes an assumption about accountability. Every data field reflects an implicit taxonomy. Every SLA assumes a service structure. These feel like small, technical decisions in the moment, but they accumulate into a rigid architecture. The tool becomes your de facto operating model—not because anyone intentionally designed it that way, but because nobody designed anything else.
I once saw an organisation spend 18 months implementing a platform, only to discover their assignment groups, categories, and escalation paths were locked into a team structure that a subsequent reorganisation made obsolete. Rebuilding the tool configuration to match the new structure cost almost as much as the original implementation. This is the trap: when the tool is the Operating Model, evolving the business requires a tool-change project, complete with business cases and change freezes. You lose the ability to evolve at the speed of the business.
The right sequence is simple: design first, configure second. An Operating Model should be legible on a whiteboard before it is ever expressed in a platform. If you cannot explain how your IT organisation works without opening a tool, the tool is doing too much of the thinking for you.

In my experience, the most expensive ITSM projects are the ones that try to compensate for a missing Operating Model with configuration. If you find yourself adding fields, forms and workflows to solve basic ownership questions, that's a red flag: you're using the tool to paper over a structural gap.
Why this matters for CIOs and Heads of IT
For senior IT leaders, this is not an abstract architecture debate. It shows up directly in:
Strategy execution
Your ability to translate "cloud‑first", "platform‑based", or "NIS2‑compliant" into how IT actually runs day to day.
Risk and compliance
Your ability to show auditors and regulators a clear line from critical services, through roles and controls, to specific teams and suppliers.
Cost and value
Your ability to connect spend (on‑prem, cloud, SaaS, vendors) to the services and outcomes the business recognises.
If you cannot quickly and confidently answer basic questions like "Who owns this service?", "How does this incident or change flow through our organisation and suppliers?", or "Why are we spending this much here?", then you do not have a reporting problem. You have an Operating Model problem.
And that's good news, because operating models are designable. They are not mystical. In the next parts of this series, we'll get very concrete about what an IT Operating model actually is, why your ITSM and cloud governance need the same map, and how you can start – without launching a 6‑month "TOM programme".