Authority
Who can actually approve this?
Being in the meeting and having the expertise isn't the same as having the authority.
IT operating model
Make sure ownership survives after the project ends.
Get clear on who decides, who delivers, who runs it day to day, who coordinates vendors, and who notices when the model stops working.
The problem
Responsibility is usually spread across several people. Accountability can't be assumed.
Leadership, internal staff, your managed-service provider, application vendors, project partners, and business owners may all be involved. An operating model spells out the handoffs and who decides what - it won't remove every exception, but it removes the guesswork.
| Decision area | Leadership owns | Delivery has to show | Operations keeps |
|---|---|---|---|
| Investment | Outcome, budget, accepted trade-off | Scope, dependencies, evidence | Running cost and a named owner |
| Risk | Consequence, appetite, authority | Control options and their limits | Exceptions, review trigger, escalation |
| Vendor | Commercial direction and fit | Responsibility boundary and sign-off | Service owner, renewal date, exit path |
| Change | Priority and acceptable disruption | Readiness, checkpoints, handoff evidence | Adoption, support path, maintenance |
Five questions
A working operating model answers these in plain language.
Evidence
Who owns the evidence?
Someone has to keep the facts and assumptions up to date.
Handoff
Where does delivery responsibility transfer?
A project wrapping up doesn't automatically mean operations has picked it up.
Coordination
Who's coordinating the vendors?
Several capable vendors don't add up to one coherent picture on their own.
Escalation
What triggers escalation or a redesign?
Exceptions, growth, risk, business change, and repeated failure all need an agreed path.
What you get
An ownership map tied to real, active work.
The useful output isn't a giant theoretical chart. It connects the decisions that actually matter, named roles, vendor boundaries, escalation, and review points to the work already underway.
A
Decision-rights map
Who recommends, who decides, who contributes, and who communicates, for each major decision type.
B
Responsibility boundary
What's internal, what's the provider's, what's the application vendor's, and what's the project partner's - written down without overlap.
C
Handoff standard
Sign-off evidence, who operates it, support path, known exceptions, and the first review point.
D
Escalation path
What condition goes to which role, with what evidence and what decision request.
This assumes the roles already exist - see the structure decision behind them
Identity and access approval is one of the sharpest tests of this map
Next
Start with whichever ownership gap causes the most repeat friction.
One focused decision can show whether the issue is local or part of a bigger operating-model problem.