Home
The IT Operating Model Discovery – Part 4
Getting started with your IT operating model (without a 6‑month programme)
By this point in the series we've established three things:
  • ITSM without an operating model turns into theatre.
  • An IT operating model is your shared answer to "how IT actually works here" – best made visible with something like Andrew Campbell's Operating Model Canvas plus a management method like USM.
  • ITSM and cloud governance only really make sense when they sit on the same map.
The natural objection I hear from CIOs and Heads of IT is: "Fine. But we don't have time for a giant TOM project. Where do we start without derailing everything else?"

The good news: you don't need a big‑bang operating model programme. You need one service, one whiteboard, and some honesty.
Step 1 – Start embarrassingly small: one critical service, one canvas
Resist the urge to "fix the whole IT organisation". That's how you end up in a 6‑month deck factory.
Instead:
01
Pick one service or value stream that truly matters
  • Business‑critical or NIS2‑relevant, and
  • Crosses multiple teams, platforms and suppliers (so the pain is visible).
02
Get a small group in the room
Service/product owner, platform lead(s), SMO/ITSM lead, someone from cloud/security, someone who actually handles incidents/changes.
03
Use Andrew Campbell's Operating Model Canvas as the structure
Sketch "how this really works today", not how the process sheet claims it works.
Fill in the six boxes for that single service:
Work (value streams)
Incident→resolution, change→deploy, request→fulfilment, "threat detected→risk mitigated".
Organisation
Which teams and roles actually touch this work.
Locations & assets
On‑prem DC, Azure/AWS landing zones, SaaS, OT sites, key components.
Information
CMDB/CMDB‑lite, monitoring, logs, cost data, risk register, contracts.
Suppliers
Which vendors, suppliers and partners sit where in the flow.
Management system
Which boards and routines make which decisions (CAB, cloud board, risk committee, service review, NIS2 incident review).
If you keep people honest, this first sketch will already surface 70–80% of the structural issues:
  • "We sort of assume this team owns it, but…"
  • "In theory, that goes through CAB – in practice we bypass it."
  • "Nobody really checks this control end‑to‑end."

That is exactly what you want.
Step 2 – Plug in USM (and ITIL) as your activity library, not your template
Once you have the rough canvas for one service, you can start asking a very different question:
"Given this reality, which management activities do we actually need to keep this under control?"
This is where USM earns its keep. USM provides a small, principle‑based set of management processes and activities that you can apply consistently across all services, rather than inventing unique process variants for every domain.
Old approach
Start from a thick practice book and ask "where can we apply all this?"
New approach
Start from your service and ask:
  • Which activities do we need around incidents, requests, changes, continuity, capacity, contracts, improvements – and who runs them for this service?
  • Where do these activities show up on the canvas – in Work, Organisation, Management System?
  • Where are we currently doing this in a completely ad‑hoc way?
You can still absolutely use ITIL, COBIT or IT4IT for detailed guidance – but now as libraries you draw from, not as Operating Model diagrams you just copy.
USM itself suggests three deployment strategies – do‑it‑yourself, training, or supported deployment – all based on small, incremental steps and internal ownership rather than "big consultant army" projects. That mindset fits perfectly with Operating Model work:
Step 3 – Test the model in real governance before you beautify it
The worst thing you can do now is disappear for three months to turn the sketch into a perfect Visio.
Instead, stress‑test the rough model in real life:
Take it into your next CAB and cloud governance board
Use it as the backdrop: "According to this canvas, who actually owns this decision? Who provides which data? Where does this change live?"
Use it in a NIS2 or risk review
"If this service fails, which roles, controls and suppliers matter most – and do we see them clearly here?"
Use it when a high impact incident happens
"Does our canvas help us understand what just went wrong in terms of flow, ownership and information?"
Within a couple of meetings, you'll see:
  • Missing roles ("we assumed security would do that, they assumed we would").
  • Broken interfaces ("this is where cloud and ITSM use different names for the same thing").
  • Tool gaps ("we rely on a spreadsheet here because nothing else fits").

Those gaps were already there; now they're visible enough to put on a backlog. Only once the canvas has survived a few real governance situations does it make sense to tidy it, document it more formally and link it to future plans.
Step 4 – Avoid the classic traps
There are a few reliable ways to kill Operating Model work. Worth naming them up front:
Trying to model the whole of IT in one go
This leads straight back to the 6‑month PowerPoint factory and change fatigue.
Letting tools dictate the model
If your "Operating Model" magically mirrors your current ServiceNow group structure or Azure subscription layout, you've probably just automated today's complexity and mess.
Outsourcing the thinking
External help can facilitate, challenge and bring patterns – but if the model mainly lives in a consultant's slides, it will die as soon as they leave the room.
Confusing "business model slides" with operating model design
Strategy decks without a matching operating model give you elegant intent and chaotic execution.
In my view, success looks almost boring: a handful of services gradually get proper canvases, those canvases start showing up in meetings, and people begin sentences with, "If we look at this on the operating model…" instead of "In my area we do it like this…".
When it makes sense to bring in external help
You can do a lot of this internally. But there are moments where an outside perspective pays for itself quickly:
Stuck in the same politics
You've tried to clarify ownership and flow for a critical service several times and always get stuck in the same politics.
Big decision, fuzzy foundation
You're about to make a big ITSM, ServiceNow or cloud governance decision and have an uneasy feeling you're pouring concrete around a fuzzy foundation.
Regulatory stakes are rising
NIS2, GDPR or sector regulations are raising the stakes and you need to show a credible, end‑to‑end story to auditors or a CIO operational reliability check.
What you want at that point is not someone to "own" the model for you, but a neutral facilitator who:
Knows the patterns
Knows patterns that work in similar organisations.
Speaks all the languages
Can translate between ITSM, cloud, risk and business languages.
Vendor neutral
Is not trying to sell you a particular tool.
How TransparIT typically helps
This is exactly the gap TransparIT is set up to work in.
The focus is very narrow on purpose: making IT and digital operations transparent through IT Operating Models, ITSM/USM‑based service management and practical Cloud Governance – including NIS2‑driven setups.
Typical starting points are deliberately small:
1
Current‑state transparency review
A review of one or two critical services, using Andrew Campbell's Operating Model Canvas to map how services, platforms, teams and suppliers actually fit together today.
2
One‑service operating model workshop
Leadership and key practitioners co‑create the first canvas and identify the 3–5 most important structural improvements.
3
Second opinion
A second opinion on a planned ITSM tool change, ServiceNow governance model or cloud governance/NIS2 initiative – specifically checking whether the operating model is clear enough to justify the investment.
From there, the engagement can grow if it needs to – but the principle stays the same:
  • Use simple, visual operating model techniques (like Campbell's canvas).
  • Use USM as the management method and ITIL as the activity library, not as religions.
  • Connect it all to real governance, risk and compliance expectations, including Danish public‑sector cloud guidance and NIS2.
  • Build your internal capability so your people can maintain and evolve the operating model without long‑term dependency.
A small next step you can take tomorrow
If you recognise yourself in any part of this series, here's a low‑friction experiment:
Choose one important service
Book a 90‑minute session
With the right people in the room.
Put Andrew Campbell's Operating Model Canvas on a whiteboard
Draw how it really works today

If you want a neutral facilitator for that conversation – or a sanity check before your next big ITSM or cloud governance move – that's exactly the kind of work I do at TransparIT.