Target Operating Model

A target operating model is the mechanism that connects what your organisation exists to do with how it creates value. It is not an org chart. It is not a process map. It is not a strategy document pinned to the office wall. It is the whole cascade - from purpose through the people you serve, the services you deliver, and the work that makes delivery happen - that turns strategic intent into outcomes.

If you have ever looked at a well-crafted strategy and wondered why the organisation cannot seem to deliver it, the gap between intention and execution is usually an operating model problem. The strategy says where you are going. The operating model is the mechanism that gets you there. And the target operating model is the deliberate design of what that mechanism should look like - not how things work today, but how they need to work to create the value your strategy promises.

What is a Target Operating Model?

A target operating model describes how an organisation will operate to deliver on its strategy. The word "target" is doing important work: it distinguishes the future-state design from the current-state reality. Your current operating model is how things work now - the processes, structures, technology, and culture that exist today. The target operating model is a deliberate choice about how they should work to create the value you have committed to.

The concept has been used in organisational design and management consulting for decades, with no single canonical version. Deloitte, McKinsey, KPMG and others all have their own frameworks. What they share is a basic premise: strategy alone does not produce results. You need a mechanism that translates strategic choices into the structure, capabilities, processes, and culture that deliver them.

Where most frameworks differ is in what they include. Some focus narrowly on structure and process. Others expand to cover people, technology, governance, and culture. The version set out here takes a specific position: a target operating model is the operating value stream - the cascade from purpose to the work that gets done - held together by operating infrastructure and shaped by operating climate.

Three things help clarify what a TOM is by naming what it is not:

It is not a business model. A business model describes how you capture value - pricing, revenue, market positioning. An operating model describes how you create and deliver value. They are related, but they are different design problems. A target operating model does not tell you what to charge or which markets to enter.

It is not an org chart. Structure is one component of the operating model, not the whole thing. Organisations that treat a restructure as an operating model redesign tend to find themselves restructuring again within two years - because they changed the boxes on a chart without changing the flow of work, the infrastructure, or the culture that shapes how people behave within those boxes.

It is not a one-off deliverable. A target operating model that gets designed, documented, and archived will drift out of alignment with strategy within 18-24 months. Strategy shifts. Markets shift. The people inside the organisation change. A TOM needs a governance rhythm - regular check-ins that test whether the design still supports the direction.

How a Target Operating Model works

A target operating model holds three ideas at once. The spine is the value-creation cascade - the flow from purpose to delivered value. The operating infrastructure is the standing framework that enables the flow. And the operating climate is the ground everything operates in.

Most TOM diagrams are either pyramids or component grids. Both describe what the model contains, but neither tells the story of what it does. The cascade tells the story: purpose enters on the left, decomposes through four stages of increasing operational specificity, and reconverges into value on the right. Purpose in, value out. The TOM is the mechanism between those two poles.

Each stage of the cascade has a natural partner in the operating infrastructure - the standing framework that holds the flow up. Governance sits closest to purpose, because that is where direction is set. Structure sits closest to the people you serve, because structure should follow need. Technology and data sit closest to what you deliver, because what you can offer is increasingly shaped by what your platforms and information make possible. Performance and controls sit closest to how the work flows, because that is where you measure whether the cascade is producing what the purpose promised. Each element wraps around the whole model - governance does not stop at the Why stage - but each has a primary home, a stage where its influence is strongest.

The cascade: from purpose to value

1. Why - purpose and strategic intent

What value will we create, and why?

Infrastructure partner: Governance - board and decision rights

This is the starting point. Everything that follows traces back to it. Purpose is not a slogan on the website - it is the anchor that every subsequent design choice in the operating model should connect to. If you cannot articulate what value your organisation exists to create, and for whom, the rest of the model has nothing to optimise for.

This stage holds your vision - the ambition and direction the organisation brings to its place in the world. It holds your mission - the action-oriented objectives that turn that ambition into something you can work toward. And it holds what you might call the value agenda: the logic by which the organisation decides where to put its weight. Not everything an organisation could do is worth doing. The value agenda is the set of choices about where resources, attention, and energy should flow.

What do we mean by value? Value is whatever the organisation exists to create - and it must be named specifically enough that you could recognise whether you are creating it. For a consumer products company, value might be a product people choose again and again because it reliably solves a problem. For a hospital, it is patient outcomes, safety, and the experience of receiving care. For a humanitarian organisation, it is lives protected, communities rebuilt, or systemic conditions changed. For a professional services firm, it is expertise that shifts how a client thinks and operates.

Value is not the same as profit. Profit may be a condition for sustaining value creation, but it is not the value itself. A toothpaste company that generates healthy margins but produces a product nobody trusts is profitable without being valuable. A nonprofit that transforms outcomes for the communities it serves is creating enormous value without generating a penny of profit. Defining value precisely is the foundation of the whole model - because purpose tells you why you exist, and value tells you what it looks like when you are doing it well. The two together give you the poles the cascade connects.

Governance sits here because this is where direction is set. Board oversight, strategic decision-making, the authority to allocate resources in service of purpose - these are governance functions that shape the Why before anything else cascades from it. Governance reaches across the whole model (there are governance questions at every stage), but its centre of gravity is purpose: ensuring the organisation stays true to its reason for being and allocates its weight accordingly.

Purpose is singular. One organisation, one reason for being. The cascade starts here because everything else is a decomposition of this.

2. Who - the people and groups you serve

Who do we deliver value to, and who do we create value with?

Infrastructure partner: Structure - units, roles, and accountabilities

The first fan-out. Purpose decomposes into the people and groups the organisation exists to serve and collaborate with. This includes the people you serve directly - customers, users, communities, citizens, members, patients, however you name them. It includes the people you create value with - partners, funders, ecosystem participants, regulators. And it includes your own colleagues - the people inside the organisation whose experience of working there is itself a form of value the model either creates or erodes.

The useful move here is thinking not just about who these groups are, but about the stages of their relationship with you. A customer's needs during onboarding are different from their needs during ongoing service, which are different again during renewal, escalation, or exit. Mapping these lifecycle stages - what people need at each point in their interaction with you - adds a time dimension that a flat list of segments cannot. It turns "who do we serve" into "what do they need, and when."

Each lifecycle stage generates journeys - the sequences of interactions through which people's needs are met. A journey is the experience of engaging with you from the outside in: applying, receiving, renewing, leaving. The cascade fans out here because each group of people, at each stage of their lifecycle, generates distinct journeys the organisation must be able to support.

Structure sits here because organisational design should follow need, not the other way around. The most common operating model mistake is starting with structure - drawing boxes on a chart, naming departments, assigning heads - and then asking how that structure will serve people. The cascade reverses this: first understand who you serve and what they need across their lifecycle, then design the structure to deliver it. Units, roles, accountabilities, and reporting lines are answers to the question "how do we organise ourselves around the people we exist for?" When structure follows need, the organisation is shaped by its ecosystem rather than by its own internal logic.

Structure reaches across the whole model - there are structural questions at every stage - but its centre of gravity is here: the people and needs that the structure exists to serve.

3. What - services and capabilities

What do we deliver to meet those needs?

Infrastructure partner: Technology and data - platforms and information

The second fan-out. Journeys decompose into the services, features, and capabilities the organisation needs in order to deliver them. This is where the outside-in perspective of Who meets the inside-out perspective of How - what the organisation must be able to offer and be capable of doing.

Each journey requires a set of features and functionality - the specific things the service does. Setting up a standing order. Processing an application. Delivering a report. Scheduling a follow-up. These are the visible, tangible outputs that the people you serve interact with.

Behind each feature sits a capability - the thing the organisation must be able to do in order to deliver it. Payments processing. Case management. Data analysis. Client relationship management. Capabilities sit at the hinge between What and How. They define what you must be able to do, without yet specifying how you do it. That distinction matters, because the same capability (say, processing a payment) could be delivered through very different processes, technologies, and team configurations. The capability is the requirement; the process is the solution.

This is also where value streams become visible - the end-to-end flows through which the organisation creates and delivers value. A value stream cuts across teams, departments, and functions to trace the whole path from a need being identified to that need being met. Mapping value streams at the What stage prevents the common trap of designing processes in functional silos that optimise locally but create hand-off problems at the seams.

Technology and data sit here because what you can deliver is increasingly shaped - and sometimes defined - by what your platforms and information make possible. A decade ago, technology enabled services. Today, for many organisations, technology is the service. The platforms you build on, the data you hold, and the analytical capability you can bring to bear do not just support the What - they expand or constrain it. An organisation that designs its services without understanding what its technology and data make possible will either underdeliver or overcommit. And an organisation that lets its technology estate drift without reference to its service design will accumulate platforms that serve no one.

Technology and data also appear in the How stage, where technology does the work (automation, AI in the flow of delivery). But their strategic home is here, at the What stage, where they inform and shape what the organisation is able to offer.

4. How - processes and activities

How does the work flow?

Infrastructure partner: Performance and controls - measures, funding, and risk

The widest fan-out. Capabilities decompose into the specific processes, activities, tasks, and steps that turn design intent into delivered value. This is where most of the operational complexity lives, and where most of the people in the organisation spend most of their time.

Each capability breaks into activities - the groups of day-to-day actions required to support it. Each activity breaks into tasks - the value-adding work undertaken by individuals as part of a wider process. Each task breaks into steps - the fundamental building blocks, the specific actions within a process.

One purpose becomes many activities. That multiplication is real, and the cascade makes it visible: the fan-out from one strategic intent to hundreds of operational tasks is the decomposition that every organisation lives inside, whether it has mapped it or not. Making it visible is what lets you test it.

This is also where ways of working live - the operating rhythms, cadences, and methodologies that shape how work gets done. Agile sprints. Case management workflows. Lean processes. Hand-off protocols between teams. Automation and technology in the flow of work. The How stage is where the model meets Tuesday morning.

Performance and controls sit here because this is where you measure whether the cascade is delivering what the purpose promised. KPIs, operational metrics, process efficiency measures, risk controls, funding allocation, and compliance requirements - these are the mechanisms that tell you whether the work is producing value or producing activity for its own sake. Performance and controls reach across the whole model (there are strategic performance questions at the Why level and service-quality questions at the What level), but their centre of gravity is in the flow: is the work being done well, efficiently, safely, and in service of something that connects back to purpose?

Value - the destination

All of that operational detail converges back into a single destination: value. This is the outcome the whole cascade exists to produce - whatever value means for this specific organisation, its strategy, and the people it serves. The definition of value from the Why stage and the measured reality of value from the How stage should meet here and match. When they do, the operating model is working. When they do not, the gap is visible and diagnosable.

The reconvergence matters. The cascade does not just fan out and stop. Every task, every process, every activity exists to deliver the value that the Why stage defined. If you cannot trace a clear line from a specific activity back through capabilities, services, and the people you serve to purpose - that activity is either misaligned or unnecessary. The cascade gives you a built-in alignment test: pick any activity and trace it backwards. If the chain breaks, you have found a problem.

Purpose in, value out. The two poles mirror each other - and the gap between what your purpose promises and the value you create is the measure of how well your operating model is working.

Operating infrastructure: a note on the standing framework

The four infrastructure elements described above - governance, structure, technology and data, performance and controls - are paired with individual stages, but they are not confined to them. Each element wraps around the whole cascade: governance questions arise at every stage, structure shapes every part of the organisation, technology enables every process, and performance is measured everywhere.

The stage pairing identifies where each element's influence is strongest - its centre of gravity. This matters for design: when you are working on the Why stage, governance is your primary infrastructure concern. When you are working on the Who stage, structural design is your primary concern. The pairing prevents the common mistake of treating infrastructure as a flat, undifferentiated list of things to sort out after the cascade is designed. Infrastructure is not an afterthought - it is woven into the cascade, stage by stage.

The key distinction: infrastructure is standing. It does not flow. Governance is a framework, not a process step. Structure is a design choice, not a task. Technology is an estate, not an activity. The infrastructure supports the cascade from the outside, enabling the flow without entering it.

Operating climate

Beneath and around everything - cascade and infrastructure alike - sits the operating climate. This is the medium the organisation operates in: the culture, behaviours, trust, informal networks, and felt experience that shape how every other element performs.

Operating climate is not a component you design and install. It is the ground. Two organisations with identical cascades and identical infrastructure can produce completely different results. The difference is climate. A climate of trust and psychological safety enables the candour that surfaces problems early. A climate of fear drives compliance but kills the discretionary effort and creativity that distinguish good delivery from adequate delivery. The operating model works through its climate, not alongside it.

The diagram names four aspects of operating climate, each describing a layer of the real culture that sits beneath the visible organisation:

• Unwritten rules - how things really get done. Every organisation has its formal processes and its real processes. The unwritten rules are the informal norms that determine what people do when the policy does not cover the situation - or when following the policy would produce a bad outcome. They are not visible in the org chart or the process map, but they are visible to anyone who has worked there for more than a few weeks.
• Reinforced behaviours - what the organisation rewards. Not what the values poster says. Not what the leadership team says in town halls. What gets people promoted, recognised, protected, or punished. The gap between stated values and reinforced behaviours is one of the most reliable indicators of operating climate health - and one of the most common reasons operating model redesigns fail to land. A new process designed for collaboration will not work in a climate that rewards individual billing.
• Deep patterns - the structures beneath practice. The recurring patterns of behaviour that persist even when individuals change. Why does this organisation always end up in the same kind of crisis? Why does that team always deliver late regardless of who leads it? Deep patterns are systemic, not personal - they are the grooves worn into the organisation's operating surface by years of reinforcement.
• Operating beliefs - the assumptions no one questions. The beliefs that people carry into every meeting, decision, and interaction without examining them. "We are too big to be agile." "Our clients expect formality." "That kind of change would never work here." Operating beliefs constrain the design space before the design work even begins. Making them visible is often the most valuable diagnostic step in a TOM project - because until you can see what the organisation assumes about itself, you cannot design past those assumptions.

Climate is influenced but not controlled. You can shape it through infrastructure choices - rewards shape behaviour, governance shapes accountability, structure shapes interaction patterns. You can shape it through leadership - the tone leaders set, the shadow they cast, the gap between what they say and what they do. But you cannot draw a climate on a whiteboard and implement it the way you can implement a process or a governance framework. It is the slowest-moving element of the operating model, and the one most likely to be underestimated.

How to design a Target Operating Model

The cascade runs left to right for a reason. Design follows the same direction: start with purpose, not structure.

Start with both poles. Define your purpose (why you exist) and the value you intend to create (the outcome) before touching anything else. These are the two ends of the cascade - everything in between is the mechanism that connects them. If either pole is vague, the model has nothing to calibrate against.

This sounds obvious, but it is where most TOM projects either get it right or get it wrong. "We exist to provide excellent customer service" is a purpose. "Our customers describe their experience as seamless and personal, and return to us by choice" is a value outcome. The cascade between those two poles is a specific, testable design. "We exist to be a leading provider" is neither - and an operating model built to deliver a vague aspiration will produce vague results.

Map the current state. Before designing the target, map how the organisation operates now. The same cascade applies: what is the current purpose (stated and actual - they are often different), who are the current groups you serve and what are their current needs, what do you currently deliver, and how does the work currently flow? The gap between current state and target state is where the transformation work lives. Without the current-state map, the target is a wish list rather than a design.

Work through the cascade stage by stage. Once the poles are defined:

1. Map the people and groups you serve and their lifecycle stages. Who do you serve? Who do you create value with? What do they need at each stage of their relationship with you?
2. Identify the services, capabilities, and value streams that meet those needs. What must you deliver? What must you be able to do?
3. Trace the processes, activities, and tasks that deliver those capabilities. How does the work flow? Where are the hand-offs? Where does technology do the work?
4. At each stage, define the operating infrastructure. What governance, structure, technology, and performance framework does this stage need?
5. Name the operating climate you need. What behaviours, norms, and cultural conditions would allow this model to perform at its best? What are the current unwritten rules, reinforced behaviours, deep patterns, and operating beliefs that would support or block it?

Test for alignment. The cascade gives you a built-in alignment test at any point. Pick any operational activity and trace it backwards: does it serve a capability? Does that capability deliver a service? Does that service meet a need for someone you serve? Does that need connect to purpose? If the chain breaks at any point, you have found a misalignment - an activity that does not connect to purpose, a capability that does not serve a need, or a service that exists for historical reasons rather than strategic ones.

Example

A mid-sized professional services firm has grown through acquisition. Its strategy calls for integrated client service across three practice areas, but each acquisition brought its own processes, systems, and culture. Clients experience the firm as three separate businesses that happen to share a name.

Why: The purpose is clear - helping clients navigate complex change. The value outcome is integrated expertise, not siloed advice. But a diagnostic reveals that the actual value agenda (where the firm puts its weight) still follows the old acquisition lines: each practice optimises for its own revenue, not for integrated delivery.

Who: Three sets of client lifecycle stages overlap. A client onboarding in one practice area may already be in active service in another. Mapping the lifecycles reveals that the hand-off between practices - currently non-existent - is where the most value is being lost. Clients are not asking for three separate relationships; they are asking to be known once.

What: The firm needs a cross-practice capability it does not have: integrated account management. The individual services exist; the capability to weave them together for a single client does not. Value stream mapping shows that the current "value streams" are three parallel lines that never meet.

How: New processes are needed for cross-practice intake, shared client planning, and joint delivery. Tasks include a shared client review rhythm, a single CRM view across practices, and cross-practice case allocation. The fan-out from one new capability (integrated account management) reveals dozens of new activities and tasks that did not exist before.

Operating infrastructure: The current structure - three autonomous practice heads reporting to a CEO - does not support integrated delivery. The target structure needs a client relationship layer across practices: not replacing the practice structure, but adding a cross-cutting accountability. Technology needs a shared platform; governance needs a cross-practice performance view that measures client outcomes alongside practice revenue.

Operating climate: The current unwritten rules say "protect your practice." The reinforced behaviours reward individual practice billing. The deep pattern is that every previous attempt at cross-practice working has been quietly undermined. The operating belief is "our clients buy from individual experts, not from a firm." Until these are surfaced and addressed, the new cascade will not land. The firm can redesign its processes and restructure its teams, but if the climate still rewards siloed behaviour, people will find ways to work around the new design.

The gap between current and target is the transformation programme. The cascade makes the scope visible: this is not a technology project, not a restructure, not a culture initiative. It is all three - a redesign of the value flow, the infrastructure, and the climate, connected by a shared purpose.

Limitations

A TOM does not tell you what to be. It translates a strategy into an operating design, but it does not generate the strategy itself. If your strategic direction is wrong, a well-designed operating model will deliver the wrong thing efficiently.

Climate is hard to design. The model names operating climate as the ground everything sits in, but culture does not respond to the same design logic as processes or structure. You can design infrastructure that nudges climate in a direction (rewards, governance, leadership development), but you cannot draw a climate on a whiteboard and install it.

The cascade can feel over-rational. Real organisations are messier than a clean decomposition suggests. People work across stages. Activities serve multiple capabilities simultaneously. Emergent needs disrupt planned value streams. The model is a design tool, not a description of reality - a way to think about the operating model, not a photograph of it.

It does not replace deeper tools. The TOM operates at the level of the whole system. For detailed work on culture, use Edgar Schein's Culture Model. For process design, use Process Mapping or Service Blueprints. For structural design, use the Galbraith Star Model or the POLISM Canvas. For understanding how a change in the operating model ripples through the whole organisation, the Burke-Litwin Change Model maps those dynamics. The TOM shows you the whole board; other tools give you the detail within each stage.

Getting started

Start with the two poles, not the middle. Before mapping lifecycles, designing processes, or debating structure, get your leadership team in a room and answer two questions:

1. Why does this organisation exist - and for whom?
2. What does "value" look like when we are creating it well?

If those answers come easily and the room agrees, you have your poles. Work through the cascade from there - who you serve, what you deliver, how the work flows. Test for alignment at every stage. Define the infrastructure. Name the climate.

If those answers are contested, vague, or different depending on who you ask, that is your first finding. The operating model cannot align what the purpose has not defined. And that is worth knowing before you spend six months redesigning processes that serve a purpose no one can articulate.