We have reviewed dozens of target operating models over the years, and the majority share a common flaw: they are beautifully drawn and functionally useless. Boxes represent departments, arrows represent relationships, and everyone nods in the workshop because nobody can quite disagree with a diagram. Then the programme launches, a real decision needs to be made about who owns a process that spans two of those boxes, and the diagram has nothing to say about it.
A target operating model is not a picture of the organisation you would like to have. It is a decision document. It should tell people, in enough detail to be useful on a difficult Tuesday, who has the authority to decide something, who is accountable when it goes wrong, and who is funding the capability required to do it well. If it cannot do that, it is not operational, and calling it a target operating model is generous.
The diagram is not the model
The seduction of the diagram is that it looks like progress. A well-produced operating model diagram, with clean boxes for functions like data, technology, customer operations and clear lines connecting them, photographs well in a steering pack and reassures a sponsor that structure has been considered. What it rarely does is force anyone to resolve the genuinely hard questions: when data quality and customer operations disagree about a process, whose call is it, and what happens if they cannot agree.
A target operating model earns its name when it survives contact with a disagreement. If the document cannot be used to resolve a real dispute between two functions about who owns an outcome, it was never a model of how the organisation operates. It was an aspiration dressed up as a governance artefact.
A target operating model earns its name when it can resolve a real argument between two functions. Until then, it is a diagram with good intentions.
Decision rights are the actual content
The part of a target operating model that does the real work is the decision rights framework: a clear statement, for every significant class of decision, of who proposes it, who is consulted, who approves it and who is accountable for the outcome. This sounds bureaucratic written down, but its absence is what causes the paralysis we see in programmes where every meaningful decision gets escalated because nobody is confident it is theirs to make.
Getting this right requires naming actual roles and actual thresholds, not vague statements like 'the business will be consulted'. A functioning model says a named role can approve spend up to a stated threshold without further sign-off, that a specific committee owns cross-functional prioritisation disputes, and that a specific individual is accountable when a shared process fails, regardless of which function happened to touch it last.
- 路Name the role that owns each significant decision, not the department
- 路State the threshold at which a decision escalates, in concrete terms
- 路Assign accountability for shared processes to one owner, not a committee
- 路Attach funding to the capability the model describes, not just to the diagram
Funding is where good intentions go to die
The second thing most operating models omit is funding. A target operating model that describes a centralised data capability but leaves its budget scattered across five business units has not actually created a centralised capability, it has created a diagram that will be quietly ignored the first time a business unit needs to protect its own budget. Structure without funding is theatre.
This is uncomfortable because funding decisions are political in a way that org charts are not. Someone's budget shrinks so that a shared capability can be funded properly, and that conversation does not happen in a workshop about boxes and arrows. It happens in a finance committee, and it is usually the true test of whether an organisation intends its target operating model to change anything at all.
Accountability that survives a bad quarter
The final test of a target operating model is what happens when something goes wrong. If a customer-facing failure traces back to a process spanning three functions and the model cannot immediately identify who is accountable, the model has failed at the one job it exists to do. A good model anticipates the argument before it happens and settles it in writing, calmly, months before anyone is under pressure to find someone to blame.
None of this is glamorous work. It involves naming names, setting thresholds and having uncomfortable conversations about budget before a crisis forces them. But it is the difference between an operating model that changes how an organisation behaves and one that simply describes how it wishes it behaved.
If your organisation's operating model cannot answer who decides, who pays and who is accountable, it is worth asking what work the document is actually doing. In most cases the honest answer is that it is doing the work of looking finished, which is a different thing entirely from being useful.