Every few years, a business reaches a point where the way it operates stops fitting the way it wants to grow. The structure made sense at a certain size or a certain stage. The processes worked when the volume was lower. The handoffs between teams were manageable when everyone knew each other. Now they are not.
The usual response is to commission a target operating model.
A team of consultants, sometimes internal, sometimes external, goes away and designs the future state. They map the current structure, identify the gaps, and produce a document that describes how the organisation should operate. There is usually a compelling slide with boxes and arrows. Sometimes there is a phased transition plan. The leadership team agrees it looks right, the program is kicked off, and six months later the business is still more or less running the way it always did.
This is the target operating model trap. It happens more often than it should, and for more predictable reasons than most organisations realise.
Why TOM programs produce diagrams instead of change
The most common failure mode is designing the structure without redesigning the work.
An org chart describes who reports to whom. A target operating model is supposed to describe how work actually gets done: how decisions are made, how information flows between teams, how customers are served, how performance is managed. But because the structure is the easiest thing to draw and the hardest thing to argue with in a leadership meeting, most TOM work ends up being primarily structural.
The result is a reorganisation dressed up as an operating model. The boxes change. The names on the doors change. The underlying processes, the informal workarounds, the tacit knowledge that keeps things running, stay exactly where they were. A few months later, the team has largely rebuilt the old way of working inside the new structure, because that is what the work requires.
The second failure mode is designing for the idealised organisation rather than the actual one.
A good target operating model has to work with the team you have, in the market you operate in, with the systems and technology you can realistically access. TOM documents that are designed in isolation from these constraints produce something that is correct in theory and unworkable in practice. The gap between the design and the delivery is not an implementation problem. It is a design problem.
What a target operating model actually needs to cover
A TOM that produces real change needs to go beyond the org chart. There are four areas that matter.
Decision rights. Who makes which decisions, at what level, and with what information? In many organisations this is ambiguous in ways that slow everything down. People escalate decisions that should be made at the frontline. Decisions that require coordination across teams get made unilaterally or not at all. A TOM that does not address decision rights will not change this.
Information flows. How does the right information get to the right person at the right time? This is closely related to decision rights but distinct from it. An organisation can have clear decision rights and still be slow if the information needed to make decisions is not available when it needs to be. Process design, system configuration and reporting structures all play a role here.
Capability. What skills and experience does the operating model require, and where are the gaps relative to where the organisation is today? A TOM that requires capabilities the organisation does not have needs a realistic plan for building or acquiring them. Skipping this step produces a model that cannot be staffed.
Governance. How is performance managed, how are problems surfaced, and how does the organisation course-correct when something is not working? Governance is the part of the operating model that keeps everything else honest. Without it, even a well-designed model drifts back towards the informal patterns of the past.
How to redesign the work without stopping the business
The other common failure mode is treating the transition as an event rather than a process.
A TOM cutover, where the old model is switched off and the new one is switched on at a fixed point in time, is almost always the wrong approach for a business that is still serving customers and generating revenue. The disruption is too high and the margin for error is too low.
The alternative is to sequence the transition deliberately, moving parts of the operating model in stages while keeping the rest running. This requires a more detailed transition plan than most TOM programs produce, and it requires discipline about sequencing. Some parts of the model need to change before others can. Getting that order wrong creates more disruption than the change itself.
A few things help here. Running the old and new models in parallel for a defined period, with clear criteria for when the new model takes over, reduces the risk of a failed cutover. Piloting the new model in one part of the business before rolling it out more broadly surfaces the problems that the design did not anticipate. Building feedback loops into the transition, so that the people doing the work can flag what is not working early, means problems get caught before they become crises.
The question worth asking before you start
Before any TOM program gets underway, one question is worth sitting with: what specifically needs to change, and why?
TOM programs that are triggered by a clear operational problem, growth is outpacing the current structure, a strategic shift requires different capabilities, customer experience is deteriorating in ways the current model cannot fix, tend to produce better outcomes than programs triggered by a general sense that things could be better organised.
The answer to that question also shapes the scope. Not every organisation needs a whole-of-business operating model redesign. Sometimes the problem is in one function, one process, or one set of handoffs. A narrower scope, executed well, is almost always preferable to a comprehensive redesign that never fully lands.
The trap is not the target operating model itself. It is mistaking the diagram for the destination. The design is the starting point. The work is everything that comes after it.