Table of Contents
- Target Operating Model Design: Why a Value Stream-First Approach Outperforms Traditional Frameworks
- What Is a Target Operating Model?
- Core Elements of Any Target Operating Model
- How the McKinsey Target Operating Model Framework Approaches Design
- What the McKinsey Operating Model PDF Gets Right, and Where It Stops
- Why Traditional Target Operating Model Templates Fail Modern Enterprises
- What Is a Value Stream-First Target Operating Model?
- The Core Components of a Value Stream Target Operating Model
- How to Design a Target Operating Model Around Value Streams
- Step 1: Identify and Map Your Enterprise Value Streams
- Step 2: Define Ownership and Leadership Accountability
- Step 3: Redesign Governance and Decision-Making
- Step 4: Align Funding and Investment to Value Streams
- Step 5: Establish Flow Metrics and a Measurement Framework
- Step 6: Embed Continuous Improvement into the Operating Model
- Target Operating Model Design vs. McKinsey Operating Model Framework: Key Differences
- Common Pitfalls When Implementing a Target Operating Model
- How to Prove Your Target Operating Model Expertise: Professional Certification
- Turn operating model knowledge into a recognised credential
- Start Designing Your Target Operating Model with a Value Stream-First Approach
- FAQs
Target Operating Model Design: Why a Value Stream-First Approach Outperforms Traditional Frameworks
Every enterprise transformation eventually arrives at the same question: how should we actually organise ourselves to deliver our strategy? The answer most organisations reach for is a target operating model. Yet the majority of operating model redesigns fail to deliver lasting change, and the reason is rarely a lack of effort or investment. It is that the model itself was designed around the wrong organising principle. This article explains what a target operating model is, examines the best-known consulting approach to designing one, and makes the case for a fundamentally different starting point: the value stream.
What Is a Target Operating Model?
A target operating model, often shortened to TOM, is a blueprint for how an organisation will operate in the future in order to deliver its strategy. Where a business strategy answers the question "where will we play and how will we win?", the target operating model answers the harder question that follows: "how must we be organised, governed, funded, and equipped to make that strategy real?"
A well-designed target operating model connects three things that are usually managed separately. First, it links strategic intent to organisational structure, so that the shape of the enterprise reflects what it is trying to achieve. Second, it links structure to delivery, defining how work actually flows from idea to customer outcome. Third, it links delivery back to strategy through measurement and governance, so leaders can see whether the organisation is producing the results the strategy demands.
The word "target" matters. An operating model describes how an organisation works today; a target operating model describes how it needs to work in the future, and the gap between the two defines the transformation agenda. Done well, a TOM is not a static organisation chart with commentary. It is a living design for the enterprise as a system of value delivery.
Core Elements of Any Target Operating Model
Whatever methodology you use, every credible target operating model addresses the same universal building blocks.
People and organisation. How teams are structured, what roles and capabilities exist, how careers and skills develop, and how culture and behaviours support the intended ways of working.
Process. The core activities through which the organisation creates and delivers value, and how those activities connect end to end rather than existing as isolated procedures.
Governance. Who makes which decisions, at what level, through which forums, and with what escalation paths. Governance determines the speed and quality of decision-making across the enterprise.
Technology and data. The platforms, systems, and information architecture that enable work, and how technology investment aligns with business priorities.
Value delivery. How the organisation defines, measures, and improves the flow of value to customers, including funding mechanisms, performance metrics, and improvement routines.
Most frameworks agree on these ingredients. Where they differ profoundly is in the organising principle that binds them together. That difference, as we will see, determines whether an operating model accelerates value delivery or quietly obstructs it.
How the McKinsey Target Operating Model Framework Approaches Design
McKinsey's approach to operating model design is probably the most widely referenced in the corporate world, and for good reason. It brings a rigorous strategic lens to a topic that can easily dissolve into organisational box-shifting.
The McKinsey framework typically begins with strategy: what differentiating capabilities does the organisation need, and what operating model choices will build them? From there it works through a set of design dimensions that usually include structure, processes, governance, people and talent, technology, and increasingly agility and ways of working. McKinsey's more recent thinking has embraced concepts from agile at scale, advocating flatter structures, empowered cross-functional teams, and faster decision cycles.
The framework is most commonly deployed in large-scale transformation contexts: post-merger integration, cost restructuring, digital transformation programmes, and enterprise agility initiatives. It is usually delivered as a consulting engagement, moving through diagnostic, design, and implementation phases over a series of months, often accompanied by published articles and PDF frameworks that summarise the approach.
What the McKinsey Operating Model PDF Gets Right, and Where It Stops
Credit where it is due. The McKinsey material gets several important things right. It insists that operating model design must start from strategy rather than from the current organisation chart. It recognises that structure, governance, talent, and technology must be designed together rather than in isolation. And its recent work acknowledges that speed, adaptability, and empowered teams are now competitive necessities rather than cultural nice-to-haves.
But the framework stops short in three places that matter enormously in practice.
First, it treats value flow as an outcome of good design rather than the organising principle of design. The McKinsey dimensions describe the components of an operating model, but they do not start by asking the most fundamental question: through what end-to-end streams does value actually reach our customers, and how should everything else be arranged around them?
Second, it is strongest at the enterprise and business-unit level and weakest at the team level. The framework describes what good looks like from the top, but offers less guidance on how team topology, team interaction patterns, and day-to-day ways of working should be designed to optimise flow.
Third, it is engagement-shaped rather than capability-shaped. A consulting framework is designed to be applied by consultants during an engagement. When the engagement ends, the framework leaves with the consultants, and the organisation is left with the artefacts of the design but not the durable internal capability to evolve it.
Why Traditional Target Operating Model Templates Fail Modern Enterprises
The deeper problem is not unique to any one firm. It is baked into the traditional operating model template itself. Conventional TOM templates are static documents that describe a future-state organisation as a set of functions, layers, and reporting lines. They are designed once, approved once, and implemented as a programme. In an environment where customer expectations, technology, and competitive conditions shift continuously, a model that is fixed at a point in time begins decaying the day it is signed off.
The Problem with Function-First Organisational Design
Traditional templates organise the enterprise around functions: marketing, sales, operations, IT, finance, risk. Functions are excellent at building deep specialist expertise, but they are terrible at delivering value, because no customer outcome is ever produced by a single function. Every meaningful piece of value crosses several functional boundaries on its way to the customer, and every boundary crossing introduces a handoff. Handoffs create queues, queues create delay, and delay destroys both responsiveness and morale.
Function-first design also misaligns incentives. Each function optimises for its own targets: utilisation, cost per transaction, defect rates within its own remit. Individually these look like good management. Collectively they produce an enterprise where every department can hit its targets while the customer still waits months for an outcome that should take days. The system optimises for the performance of its parts at the expense of the performance of the whole.
Siloed Departments and the Cost of Misalignment
The cost of silos is easy to underestimate because it rarely appears as a line item. It shows up as elapsed time: work that takes two weeks of effort but six months of calendar time because it spent most of its life waiting in functional queues. It shows up as duplicated effort, when three departments independently build overlapping capabilities because none can rely on the others' roadmaps. It shows up in decision latency, when a simple trade-off requires a steering committee because no single leader owns the end-to-end outcome. And it shows up in the growing distance between the people doing the work and the customers the work is supposed to serve. In a siloed enterprise, most employees cannot articulate how their daily work connects to customer value, because the connection has been severed by organisational design.
The Missing Link: No Shared Operating Model Across the Enterprise
Perhaps the most damaging failure is the absence of any shared model at all. Strategy lives with the executive team. Delivery lives with agile teams, programme offices, and functional departments, each running its own methods. Customer insight lives with product and marketing. Nothing connects them. Agile teams sprint efficiently inside a system that was never designed for flow, delivering outputs into a governance and funding structure that still thinks in annual projects and functional budgets. The result is a familiar paradox: highly agile teams inside a profoundly non-agile enterprise. Without a shared operating model that runs from strategy through value streams to teams, local agility can never become enterprise agility.
What Is a Value Stream-First Target Operating Model?
A value stream-first target operating model inverts the traditional design sequence. Instead of starting with functions and then trying to coordinate value delivery across them, it starts by identifying the end-to-end streams through which the enterprise delivers value to customers, and then designs structure, governance, funding, metrics, and ways of working around those streams.
This is a genuine change of organising principle, not a re-labelling exercise. In a value stream-first model, the primary units of organisation, investment, and accountability are value streams. Functions do not disappear; they become sources of specialist capability and standards that support the streams, rather than the primary containers of work. The question every design decision must answer changes from "which department should own this?" to "how does this improve the flow of value to the customer?"
Function-first vs value stream-first: two organising principles for a target operating model
Join Strategic Value Streams
Become a free member of the professional community for value stream operating models. Join the member community and receive practical resources, new articles, and webinar invitations.
Defining Value Streams in an Enterprise Context
An enterprise value stream is the end-to-end sequence of activities an organisation performs to deliver a defined outcome of value to a customer or stakeholder, from the initial trigger to the realisation of value. "Customer requests a mortgage" to "customer moves into their home" is a value stream. "Employer needs a capable hire" to "new colleague is productive" is a value stream.
A value stream is not the same thing as a process flow. A process describes a repeatable procedure, often within one department. A value stream is larger: it spans functions, systems, and teams, and it is defined by the value it delivers rather than the activities it contains. Critically, in organisational design terms, a value stream is a durable structure. Processes change frequently; the fundamental streams through which an enterprise delivers value change rarely, which is precisely what makes them a stable foundation for an operating model.
How Value Stream Design Differs from Value Stream Mapping
The two terms are often confused, and the confusion matters. Value stream mapping is a lean analysis tool: a workshop technique for visualising the current flow of work and information through a process, identifying waste and delay, and designing an improved future state. It is diagnostic, periodic, and typically local in scope.
Value stream design is a structural discipline. It uses the value stream as the primary unit of organisational design: defining stream boundaries, assigning ownership, aligning teams, restructuring governance and funding, and establishing flow-based measurement. Mapping tells you where the water is blocked; design decides where the riverbed should run. A mature enterprise needs both, but only design changes the operating model.
End-to-End Value Streams vs. Agile Delivery Teams
It is tempting to believe that adopting agile teams solves the problem that value streams address. It does not, because the two operate at different levels of the system. An agile delivery team optimises flow within its own backlog: typically a slice of an application, product, or service. An enterprise value stream optimises flow across the whole journey from customer trigger to customer outcome, which usually involves many teams, several systems, and multiple functions.
Both are necessary. Teams provide the delivery engine; value streams provide the alignment structure that points every engine in the same direction. An enterprise with agile teams but no value stream layer has fast components inside a slow system. An enterprise with defined value streams but no empowered teams has a well-designed system with no engine. The value stream-first operating model deliberately designs both levels and the connection between them.
The Core Components of a Value Stream Target Operating Model
Reorienting an operating model around value streams requires deliberate design across five interlocking components. Each one replaces a functional-era mechanism with a flow-era equivalent, and they only work as a set. The sections below examine each in turn.
Value Stream Ownership and Accountability Structures
Every value stream needs a single accountable owner: a leader whose remit is the end-to-end performance of the stream, from trigger to outcome, regardless of which functions the work passes through. This role changes the physics of the organisation. Decisions that previously required negotiation between three department heads now sit with one accountable leader whose incentives are aligned to the customer outcome, not to any single function's targets.
Ownership must come with genuine authority: influence over priorities, people, and investment within the stream. A value stream owner who can convene meetings but cannot move money or change priorities is a coordinator, not an owner, and coordination is precisely the failure mode the model exists to eliminate. Supporting roles matter too, including stream-level product management, architecture, and coaching capability, but the non-negotiable is clear, single-point accountability for value delivered.
Governance Aligned to Value Flow, Not Function
Traditional governance mirrors the functional hierarchy: departmental reviews, stage gates, and committees that examine work each time it crosses a boundary. Each checkpoint was created for a rational reason, and collectively they are the largest source of delay in most enterprises.
Value stream-aligned governance restructures decision rights around the flow of value. Decisions are pushed to the lowest level at which they can be made competently, most of them inside the stream itself. Stream-level forums review flow, outcomes, and impediments on a fast cadence. Enterprise governance narrows its focus to what genuinely requires enterprise oversight: strategy, cross-stream investment trade-offs, risk appetite, and shared standards. The governance question changes from "has this work satisfied each function's checkpoint?" to "is value flowing, and what is blocking it?"
Funding Models That Support Continuous Value Delivery
Project-based funding is one of the strongest forces holding old operating models in place. Projects assemble temporary teams, disband them at the point they have finally learned to work together, and lock investment decisions into an annual cycle that cannot respond to what the organisation learns during the year.
A value stream funding model funds the stream itself: a durable capacity of teams and capability, reviewed on a regular cadence rather than rebuilt annually from zero. Leaders adjust the level of investment in each stream based on strategic priority and demonstrated value delivery, in the way an investor manages a portfolio. This enables continuous delivery in the truest sense: stable teams working on a continuous flow of priorities, with funding decisions that respond to evidence quarterly rather than to forecasts annually. It also dramatically reduces the cost and theatre of the annual planning cycle.
Flow Metrics and Measuring Value Stream Performance
What gets measured in a value stream operating model changes as fundamentally as the structure. Functional metrics measure the busyness and efficiency of the parts. Flow metrics measure the performance of the whole. The core set includes flow time, the elapsed time from trigger to value delivered; throughput, the number of value items completed per period; flow efficiency, the proportion of elapsed time in which work is actively progressed rather than waiting; flow load, the amount of work in progress in the stream; and flow distribution, the balance of work across new features, defects, risk, and technical debt.
Alongside flow, the model measures outcomes: customer satisfaction, value realised, and quality. Together these give leaders something functional dashboards never could: a true picture of how fast and how reliably the enterprise converts demand into value, and where the constraints sit.
Ways of Working and Team Topology Within Value Streams
Inside each value stream, team structure and collaboration norms need deliberate design rather than inheritance from the old organisation. Long-lived, cross-functional teams aligned to the stream do the core delivery work. Platform teams provide shared services and self-service capabilities that reduce the cognitive load on stream-aligned teams. Specialist enabling teams coach and support rather than gatekeep. Interaction patterns between teams are designed explicitly, so collaboration happens where it adds value and clean service interfaces exist where it does not.
Ways of working, including cadences, visualisation of work, limits on work in progress, and improvement routines, are standardised where consistency helps flow across the stream and left to team discretion where it does not. The aim is not uniform methodology; it is coherent flow.
How to Design a Target Operating Model Around Value Streams
Designing a value stream-first operating model is a structured, enterprise-wide undertaking, but it does not require a multi-year programme before delivering value. The six steps below describe the core sequence. In practice they overlap and iterate, and the final step ensures the model keeps evolving after the initial design.
Step 1: Identify and Map Your Enterprise Value Streams
Begin by identifying the streams through which your enterprise actually delivers value. Start from the outside in: who are our customers and stakeholders, what outcomes do they seek from us, and what end-to-end journeys produce those outcomes? Most enterprises discover they have a relatively small number of primary value streams, typically somewhere between five and fifteen, supported by internal streams that serve them.
For each stream, define the trigger, the value outcome, the major stages, and the functions and systems the work passes through today. Resist the urge to design the future state at this stage. The purpose is a shared, honest picture of how value flows now, including the queues, handoffs, and delays that current structures create. This picture becomes both the foundation of the design and the burning platform for change.
Step 2: Define Ownership and Leadership Accountability
Next, assign ownership. Each primary value stream needs a named owner with end-to-end accountability for its performance, and the seniority and authority to carry that accountability. This step is where operating model design becomes a leadership conversation rather than a diagramming exercise, because value stream ownership redraws the map of executive power. Be explicit about what stream owners control, what functions retain, and how the two relate. Align leadership incentives to stream outcomes, and ensure the executive team collectively owns the health of the whole portfolio of streams rather than defending functional territories.
Step 3: Redesign Governance and Decision-Making
With ownership in place, restructure governance to serve flow. Inventory the existing forums, gates, and approval steps that touch each stream, and ask of each one: what decision does this exist to make, who is best placed to make it, and at what cadence? Push decisions into the stream wherever competence and risk allow. Replace functional stage gates with stream-level reviews of flow and outcomes. Reserve enterprise-level governance for cross-stream trade-offs, strategic alignment, and genuine enterprise risk. Document the new decision rights explicitly; ambiguity about who decides is how old governance quietly reasserts itself.
Step 4: Align Funding and Investment to Value Streams
Transition investment from projects to streams. Establish a baseline capacity funding for each value stream, sized to its strategic importance and demand. Move to a regular investment review cadence, quarterly is common, at which leaders adjust allocations based on delivered outcomes and changing priorities. Build the bridge with your finance function early: CFO partnership is essential, and finance leaders are often enthusiastic once they see that stream-based funding gives them better visibility of value for money than project accounting ever did. Expect this step to take longer than the others, and start it sooner than feels comfortable.
Step 5: Establish Flow Metrics and a Measurement Framework
Implement a measurement framework that makes value stream performance visible. Instrument each stream to capture flow time, throughput, flow efficiency, work in progress, and flow distribution, alongside outcome measures such as customer satisfaction and value realised. Make the metrics visible to everyone in the stream, not just to leadership, and review them on a regular cadence at both team and stream level. Use them to drive improvement conversations, not performance rankings; the fastest way to corrupt flow metrics is to weaponise them. Over time, these measures become the shared language in which the enterprise discusses its own performance.
Step 6: Embed Continuous Improvement into the Operating Model
Finally, build evolution into the model itself. Establish improvement cadences at every level: teams reflecting on their own flow, streams reviewing their end-to-end performance, and the enterprise periodically re-examining stream boundaries, governance, and funding in light of strategic change. Treat the operating model as a product with a backlog, an owner, and a release rhythm. This step is what separates a value stream-first operating model from every static template that preceded it: the design is never finished, because the environment it serves never stops changing.
Target Operating Model Design vs. McKinsey Operating Model Framework: Key Differences
Set side by side, the two approaches differ across every major design dimension. The organising principle differs: strategy-to-capability cascades through functions and structures in the consulting framework, versus end-to-end value flow as the primary design axis in a value stream-first model. The unit of design differs: business units and functions versus value streams and the teams within them. Governance differs: refined hierarchical decision-making versus decision rights restructured around flow. Funding is largely out of scope in most consulting frameworks but is a first-class design component in a value stream model. Measurement differs: strategic KPIs and functional performance versus flow metrics tied to customer outcomes. And the delivery mechanism differs most of all: a time-boxed engagement producing a designed future state, versus a durable internal capability, built on an open body of knowledge, that continuously evolves the model.
None of this makes the consulting lens worthless. Strategic framing, capability analysis, and executive alignment are real strengths. The question is what foundation the operating model rests on once the engagement ends.
When to Use a Consulting-Led Framework vs. a Dedicated Professional Standard
A consulting-led approach makes sense when the organisation faces a discrete, high-stakes structural event: a merger integration, a major divestiture, a turnaround, where speed, external benchmarking, and senior-level facilitation justify the investment, and where the design question is as much about corporate structure as about value delivery.
A professional standard makes sense when the goal is durable organisational capability: when you want your own leaders and practitioners to understand, apply, and evolve the operating model over years rather than receive it as a deliverable. Standards are consistent across the organisation, independent of any individual advisor, and accessible at a fraction of the cost of engagement-based expertise. The two are not mutually exclusive; the strongest transformations often use targeted external support to accelerate the adoption of an internal standard. But ownership of the model must end up inside the enterprise.
Why a Value Stream Body of Knowledge Provides a More Durable Foundation
A body of knowledge outlasts any engagement because it is designed to be learned, shared, and applied by the organisation's own people. It creates a common language: when everyone from the executive team to delivery teams means the same thing by "value stream", "flow efficiency", and "stream ownership", alignment stops depending on translation. It is community-backed, evolving through the contributions and field experience of a professional community rather than the intellectual property cycle of a single firm. And it is verifiable: practitioners can be certified against it, so organisations can build and evidence internal capability rather than renting it. An enterprise that develops fifty certified practitioners has an asset that compounds. An enterprise that commissions a second operating model engagement has an invoice that repeats.
Common Pitfalls When Implementing a Target Operating Model
Even with a sound design approach, implementations fail in predictable ways. Three pitfalls account for most of the damage.
Treating the Target Operating Model as a One-Time Design Exercise
The most common failure is finishing. An operating model that is designed, approved, implemented, and then filed is a photograph of the organisation's best thinking at a single moment, ageing from the day it is taken. Strategy shifts, technology changes, and customer expectations move, while the model stays still. Treat the operating model as a living system: give it an owner, a review cadence, and a mechanism for change, exactly as you would any other critical product. If your operating model documentation has a version number and a roadmap, you are doing it right. If it has a publication date and a lamination, you are not.
Failing to Align Leadership Around Value Stream Ownership
Value stream ownership redistributes authority, and authority is never redistributed painlessly. If the executive team nods at the design while privately defending functional territory, the model dies in the middle of the organisation, where newly appointed stream owners discover they have accountability without power. The symptoms are recognisable: decisions escalating to the same old forums, funding quietly reverting to departmental budgets, and stream owners spending their time negotiating rather than leading. The remedy is explicit, contracted clarity at the top: which decisions move to stream owners, which remain functional, and what the executive team will do when the two collide. Without that agreement, everything downstream is decoration.
Ignoring Funding and Governance in Favour of Team-Level Agility
The third pitfall is transforming the bottom of the organisation while leaving the top untouched. Enterprises invest heavily in agile teams, coaching, and tooling, then wonder why delivery has not accelerated. The answer is almost always above the teams: work still enters through an annual project funnel, decisions still queue at functional gates, and funding still arrives in project-shaped parcels. Team-level agility inside unchanged enterprise structures produces frustration, not flow. The operating model disciplines that feel least glamorous, funding models and governance design, are precisely the ones that determine whether team agility ever becomes enterprise performance.
How to Prove Your Target Operating Model Expertise: Professional Certification
As value stream-centric operating models move into the mainstream, organisations increasingly need people who can demonstrably design and run them, and practitioners need a credible way to evidence that capability. Self-declared expertise is difficult for employers to assess; certification against a recognised professional standard is not. For practitioners, certification signals verified knowledge of value stream operating model design. For organisations, it provides a reliable benchmark when building internal capability or hiring for transformation roles.
The Strategic Value Streams Body of Knowledge and Certification Pathway
The Strategic Value Streams (SVS) Body of Knowledge is the professional standard for value stream-centric operating model design. It codifies the concepts covered throughout this article, including value stream identification and design, ownership and accountability structures, flow-aligned governance, value stream funding, flow metrics, and team topology, into a structured, coherent body of knowledge that practitioners can learn and organisations can adopt as a shared standard. Built on it is a tiered certification pathway that allows professionals to validate their expertise progressively, from foundational understanding through to recognised mastery.
Foundation, Practitioner, and Fellow: Building Credibility at Every Level
The pathway has three tiers. Foundation certifies fluency in the core concepts: what value streams are, how a value stream operating model differs from traditional designs, and the vocabulary of flow. It suits anyone working in or around a transformation, from analysts to senior leaders who need shared literacy. Practitioner certifies applied capability: designing value streams, structuring ownership and governance, implementing flow metrics, and leading the design steps described above. It suits consultants, transformation leads, operating model designers, and senior delivery professionals. Fellow recognises sustained mastery and contribution: leaders who have designed and run value stream operating models at scale and who contribute to advancing the discipline itself. Together the tiers create a visible professional ladder, so credibility can be built and evidenced at every career stage.
Digital Badges and Verifiable Credentials for Value Stream Professionals
Each SVS certification is issued with a verifiable digital badge that practitioners can display on professional profiles, CVs, and email signatures. Because the badges are cryptographically verifiable, employers and clients can confirm a credential in seconds rather than taking it on trust. For professionals, that means portable, durable proof of expertise that travels across employers and markets. For hiring organisations, it means a talent signal that actually signals.
Turn operating model knowledge into a recognised credential
The Strategic Value Streams Foundation Bundle includes the Body of Knowledge, Foundation Exam, digital badge, and professional community access.
Start Designing Your Target Operating Model with a Value Stream-First Approach
The evidence of two decades of transformation is clear: enterprises do not become faster, more customer-centric, or more adaptive by refining functional structures, and no static template, however prestigious its source, survives contact with a changing market. Operating models built around end-to-end value streams, with real ownership, flow-aligned governance, continuous funding, and honest measurement, do.
If you are ready to move from framework-shopping to capability-building, start with the Strategic Value Streams Body of Knowledge. Explore the BoK to ground yourself and your leadership team in a shared standard, begin the certification pathway at Foundation level to build verified expertise, and join the SVS professional community to learn from practitioners designing value stream operating models in the field. Your strategy already knows where you need to go. A value stream-first target operating model is how your organisation gets there.
How the value stream certifications compare.
FAQs
What is a target operating model in simple terms?
A target operating model is a blueprint for how an organisation needs to work in the future to deliver its strategy. It defines how the enterprise will be structured, governed, funded, and measured, and the gap between the current operating model and the target operating model sets the transformation agenda.
What is the difference between an operating model and a target operating model?
An operating model describes how an organisation works today. A target operating model describes the future state the organisation is deliberately designing towards. The first is descriptive; the second is a design artefact that guides change.
How is a value stream-first target operating model different from the McKinsey framework?
The operating model framework McKinsey uses starts from strategy and cascades through functions, structures, and capabilities. A value stream-first target operating model starts from the end-to-end streams that deliver customer value, then designs ownership, governance, funding, and metrics around those streams. It also treats the model as a living system rather than a one-time engagement deliverable.
How long does it take to design a target operating model?
The initial design of a target operating model, covering value stream identification, ownership, governance, funding, and metrics, typically takes a few months in a large enterprise. Implementation is iterative and continues from there; a well-designed model is never finished, because it evolves with the strategy it serves.
Do I need a certification to design a target operating model?
No certification is legally required, but certification against a recognised standard such as the Strategic Value Streams Body of Knowledge gives practitioners verifiable credibility and gives organisations confidence that their target operating model is being designed by someone with tested knowledge of value stream design, flow-aligned governance, and stream-based funding.