This guide uses operating model consulting as the starting point for the practical advice below. Operating model consulting is rarely about drawing a new org chart. It is about making the way a company works fit the way it says it wants to compete. That sounds obvious until you look at how many leadership teams still rely on inherited structures, unclear decision rights, and handoffs that were never designed for the business they have today.
When the operating model is off, strategy gets trapped in slides. Teams work hard, but not in the same direction. Leaders ask for speed and accountability, yet the system rewards escalation and delay. A strong consulting engagement helps surface those mismatches, then turn them into a practical design that people can actually use.
If you want a broader view of how we think about this work, see our corporate consulting approach.
operating model consulting: Operating model consulting starts with the work, not the org chart
The most common mistake in transformation work is starting with boxes and reporting lines. That approach feels tidy, but it often misses the real problem. If customer onboarding is slow, the issue may not be the structure at all. It may be that sales, legal, finance, and operations each own a different part of the process, with no shared logic for who decides what, when, and on what evidence.
Good operating model consulting begins with how value is created. What work actually drives revenue, margin, service quality, or customer retention? Where does work move from one team to another? Which decisions happen at the edge, and which need coordination at the center? Once you answer those questions, the structure starts to look different. Some layers disappear. Some roles become clearer. Some responsibilities need to sit closer to the customer.
I like to think about the operating model as the system that converts intent into motion. Strategy says where the company wants to go. The operating model says how people will move, who will decide, what tools they will use, and how progress will be tracked. Without that layer, even smart plans stall because the organization has no shared operating logic.
That is why the best consultants spend time on the real work first. They map the actual flow of requests, approvals, exceptions, and handoffs. They sit with teams long enough to see where work slows down. They compare the formal process to the informal one. Often the real business process is not in the manual. It lives in inboxes, side chats, spreadsheets, and tribal knowledge.
Once you see that, the design conversation becomes more concrete. You are no longer asking, What should the chart look like? You are asking, What should happen to this task, this decision, and this customer issue? That shift changes everything.
Why strategy fails when the operating model is weak
Most leaders know that strategy and execution are connected. What is less obvious is how fragile that connection can be. A strong strategy can still fail if the operating model cannot support it. If the business wants to move faster but every decision requires three approvals, speed will not come from enthusiasm. If the company wants more cross-functional innovation but rewards local optimization, collaboration will stay shallow.
Weak operating models create a long list of predictable failures. Teams duplicate work because ownership is unclear. Leaders get flooded with decisions that should have been resolved lower down. Functional managers protect their own priorities, which slows enterprise goals. Customer issues bounce from team to team because no one owns the end-to-end journey. The result is friction that feels invisible at first and then suddenly expensive.
There is also a cultural cost. People learn what the system really values by watching where decisions go, how exceptions are handled, and what gets measured. If the company says it wants accountability but centralizes every meaningful decision, people stop taking initiative. If it says it wants agility but changes priorities every month without a clear governance rhythm, teams learn to wait rather than act.
That is why operating model consulting is not a cosmetic exercise. It shapes behavior. It gives leaders a way to align incentives, roles, processes, and data around the same business logic. A better model does not just reduce confusion. It makes the company more legible to itself. People understand who does what, how work moves, and what good looks like.
One useful test is simple. Ask a manager to describe how a customer request moves from intake to resolution. If the answer is a mix of formal process, local workarounds, and exceptions that “depend on the situation,” the operating model is probably doing too much work in the background. A well-designed model does not remove judgment, but it makes judgment easier to apply.
The irony is that many leadership teams blame performance gaps on people when the real issue is system design. Sometimes the right person in the wrong model will still struggle. Consulting helps separate capability problems from design problems, which is usually the first step toward a better outcome.
The five parts of an operating model that matter most
Every business is different, but most operating models can be understood through five connected parts. When consultants work well, they do not treat these parts as separate workstreams. They look at the relationships between them.
1. Roles and accountabilities
Who owns the outcome? Who makes the call? Who supports it? Too many organizations confuse activity with ownership. A role can be busy and still be unclear. A proper operating model defines accountability in a way that the people doing the work can understand without a decoder ring.
2. Decision rights
Decisions should sit as close as possible to the work, but not so close that they fragment the business. The point is not to decentralize everything or centralize everything. The point is to place each decision where the best information lives. High-risk, cross-functional, or capital-heavy decisions may need more governance. Routine decisions should move faster.
3. Processes and workflows
Processes are not just compliance documents. They are the routes by which work travels. A strong process is simple enough to follow and clear enough to audit. It defines what starts the work, what evidence is needed, where it pauses, and what ends it. The best workflows reduce back-and-forth without forcing people into rigid behavior that breaks under real conditions.
4. Governance and cadence
Governance is the rhythm that keeps the model alive. That includes weekly operational reviews, monthly performance forums, quarterly planning, and escalation paths for exceptions. Without cadence, the organization drifts. With too much cadence, it becomes bureaucratic. The goal is a clean operating rhythm that matches the pace of the business.
5. Metrics and management information
What gets measured gets managed, but only if the measures are useful. A good operating model tells leaders which signals matter at each level. Frontline teams need immediate operational indicators. Managers need trend data and exception flags. Executives need a small set of measures that show whether the system is creating value. If the scorecard is crowded, people stop using it.
These five parts work together. If decision rights are clear but processes are messy, the business still slows down. If metrics are strong but accountabilities are fuzzy, people optimize the wrong things. Consulting work becomes valuable when it shows how each part supports the others rather than treating them as a checklist.
How consultants diagnose the current state
Diagnosis is where a consulting team earns trust. Many leaders already know something is broken, but they do not always know where the real leverage is. A useful diagnosis is not a pile of observations. It is a structured view of how work currently gets done, where the design is inconsistent, and which changes will matter most.
The first step is usually mapping the current journey of work. That can mean customer journeys, internal service journeys, product development flows, or approval paths. The question is simple: what happens in practice, not just in policy? Consultants often combine interviews, workshops, process mapping, data review, and shadowing to capture the difference between intended process and lived process.
Then comes the friction analysis. Where do people wait? Where do they duplicate effort? Where do decisions pile up at the top? Which handoffs create rework? Which teams are carrying risks that should belong somewhere else? A good diagnostic does not stop at symptoms. It traces the root cause back to role design, governance, capability gaps, or technology constraints.
One practical method is to separate the issues into three buckets. The first bucket is structural, such as too many layers or misaligned functions. The second is behavioral, such as managers who override decisions that should stay local. The third is system-based, such as weak tools or poor data visibility. That distinction matters because each bucket needs a different fix.
It also helps to look for overload points. When one team becomes the catch-all for exceptions, the model is usually compensating for design gaps elsewhere. For example, an operations team may end up resolving sales promises, product defects, and client escalations because no one else has the authority or information to act. That is not resilience. It is hidden complexity.
Good consultants do not just ask what is broken. They ask what the organization is currently optimized for. Sometimes the answer is not speed or quality, but risk avoidance. That insight can be uncomfortable, yet it is useful. It explains why people behave the way they do, and it gives leaders a more honest starting point for change.
The best diagnoses also pay attention to capability. A business may design a more local decision model, but if local managers lack the skill or confidence to use it, the change will not stick. That is why diagnosis should include both process and people. The operating model only works when the organization can operate it.
Designing a target model people can actually use
A target operating model is not a poster. It is a working blueprint. If people cannot explain it in plain language, it is too abstract. If they cannot use it to make decisions, it is too theoretical. Good design turns strategy into everyday behavior.
The best design work starts by clarifying the business outcomes first. Is the company trying to improve speed, consistency, margin, customer experience, innovation, or some combination of these? Different outcomes push the model in different directions. A high-growth start-up may need fewer layers and more autonomy. A regulated enterprise may need tighter governance and stronger controls. A premium service business may need more local discretion to protect the customer experience.
From there, consultants and leaders need to define the design principles. These are the rules that guide tradeoffs. For example, “decisions should be made at the lowest level with the right data” is a useful principle. So is “shared services handle repeatable work, while customer-facing teams focus on exceptions and high-value interactions.” Principles help the team stay consistent when the design gets complicated.
Then comes the detail work. Which activities belong in the center? Which belong in the business units? Which belong in shared services? Which decisions require escalation, and which do not? A strong design should answer those questions without creating new ambiguity. It should also reflect the real constraints of the organization. If a company does not have the data or digital tooling to support a highly distributed model, the design should not pretend otherwise.
One mistake I see often is overdesign. Leaders want the perfect model, so they create dozens of rules and exceptions. That usually makes adoption worse. People need enough clarity to act, not so much complexity that they stop reading the playbook. A clean model is easier to scale, easier to teach, and easier to revisit later.
Another mistake is ignoring interfaces. Most operating model problems happen between teams, not inside them. The design should make the boundaries visible. Who hands off what? What information must be included? What is the service level? What happens when the request is not standard? If those interfaces are not clear, the model will look elegant on paper and messy in practice.
When done well, the target model gives the organization a simple story. It explains how the business works now, how it will work next, and why the new way is better. That story matters because people do not adopt designs alone. They adopt narratives they can believe.
Tradeoffs that determine whether the model holds up
Every operating model involves tradeoffs. There is no universal best answer. The right design depends on strategy, risk, scale, and culture. Good consulting helps leaders make those tradeoffs consciously instead of drifting into them by habit.
One of the biggest tradeoffs is centralize versus decentralize. Centralization can improve consistency, control, and efficiency. Decentralization can improve speed, responsiveness, and ownership. The right answer is often mixed. Standardize the parts of the business that benefit from scale or risk control. Push decisions closer to customers where local knowledge matters most.
Another tradeoff is standardize versus customize. Standardization reduces variation and makes performance easier to measure. Customization can create better customer fit or local relevance. But if every team invents its own version of the process, the company pays for it later in training, support, and reporting. The trick is to standardize the core and allow variation only where it creates clear value.
There is also a tension between speed and control. Many leadership teams say they want both, which is fair, but they do not always define the thresholds. Which decisions can move quickly with limited review? Which ones require broader scrutiny? A strong model makes those thresholds visible. It does not eliminate risk. It makes the cost of delay and the cost of error easier to compare.
Finally, there is the question of specialization versus end-to-end ownership. Specialists can be excellent at their part of the work, but if no one owns the journey from start to finish, the customer feels the seams. End-to-end ownership improves accountability, but it can create silos inside a broader team if the supporting functions are not aligned. Good design balances depth and ownership.
One useful way to think about tradeoffs is to ask what kind of failure the business can live with more easily. Can it tolerate a little more variation? Can it tolerate slower approvals? Can it tolerate more local autonomy? Can it tolerate a little less standardization? That conversation is more useful than pretending every goal can be maximized at once.
Consultants add value here because they can hold the tradeoff conversation without being trapped by internal politics. They can point out where a choice improves one outcome but weakens another. They can also help leadership teams decide what the business is really optimizing for, which is often the heart of the matter.
Implementation is where the real work begins
A strong design can still fail during rollout. That is why implementation deserves as much attention as the model itself. People do not experience the operating model in a deck. They experience it in meetings, approvals, dashboards, and daily work. If the transition is messy, the design quickly loses credibility.
The first step is to translate the model into action. That means role descriptions, decision-right guides, process maps, governance calendars, and clear communication. People need to know what changes, what stays the same, and what support they will get. Ambiguity during rollout creates fear, and fear makes people cling to the old way.
It also helps to sequence the change. Not everything needs to happen at once. Some changes are foundational, such as clarifying accountabilities or setting the governance rhythm. Others can follow, such as redesigning specific processes or moving services into a shared model. Sequencing helps the organization absorb the change without overload.
Training is another part that too many teams underinvest in. If managers are expected to make more decisions locally, they need more than a memo. They need examples, boundary cases, and practice. They need to know how to escalate when the issue is not standard. They need to see what “good” looks like in their own context.
Implementation also needs visible sponsorship. If senior leaders say the new model matters but keep bypassing it in meetings, people will copy the behavior they see. Leaders should model the new decision logic, use the new governance forums, and resist the temptation to solve every issue personally. That discipline matters more than any launch event.
One practical way to improve adoption is to identify early wins. Choose a few workflows or decisions where the new model can remove pain quickly. Show the time saved, the rework reduced, or the customer experience improved. Early wins build confidence and help people believe the change is real.
By the time rollout begins, the consulting team should already know which parts of the system are most fragile. They should plan for exceptions, questions, and pushback. That is not a sign that the design is weak. It is a sign that the team has thought about how humans actually behave inside organizations.
Metrics that show whether the new model is working
If a company cannot tell whether the new operating model is working, it has not finished the job. Metrics are not the whole story, but they are the feedback loop. They tell leaders whether the new system is reducing friction, improving accountability, and supporting business goals.
The first category of metrics is outcome-based. These are the business results the model should influence, such as revenue growth, cycle time, cost-to-serve, customer satisfaction, retention, or quality. Outcome metrics matter because they keep the design tied to business value rather than internal neatness.
The second category is process metrics. These show whether work is moving more smoothly. Examples include approval time, number of handoffs, rework rates, exception volumes, and the percentage of decisions made at the intended level. These indicators are especially useful early in the rollout, when leaders need to see whether the new design is actually changing behavior.
The third category is adoption metrics. These tell you whether teams are using the model as designed. Are the governance forums happening on schedule? Are role definitions understood? Are managers escalating the right issues? Are people using the common process rather than local workarounds? Adoption matters because a beautiful design that no one uses is just paperwork.
It also helps to keep the scorecard small enough to be useful. Too many metrics create noise. Too few create blind spots. A good scorecard usually includes a small number of enterprise measures, a handful of functional measures, and a few local indicators that teams can act on quickly. The point is not to monitor everything. It is to monitor the signals that show whether the system is behaving as intended.
Metrics should be reviewed on a cadence that fits the business. Weekly for operational issues. Monthly for trend review. Quarterly for more strategic resets. That rhythm gives leaders a way to spot drift before it becomes a larger problem.
I also recommend including qualitative feedback. Numbers matter, but so do the lived experiences of the people using the model. If managers say the new process is faster on paper but harder in practice, that deserves attention. Consulting work becomes much stronger when it combines quantitative evidence with real operating feedback.
How to keep the model current as the business changes
An operating model is never truly finished. Markets shift, products change, acquisitions happen, technology evolves, and customer expectations move. What worked two years ago may no longer fit. The best organizations treat operating model design as a living discipline, not a one-time event.
Maintenance starts with ownership. Someone has to watch the model over time. That might be a transformation office, an operations leader, or a cross-functional governance group. Their job is not to rewrite the model every month. Their job is to notice when the design starts to drift away from the business.
Regular reviews help. Once a quarter, ask a simple set of questions. Are decisions still sitting at the right level? Have new products or channels created new handoffs? Are there workarounds that have become normal? Has the governance rhythm become too heavy or too loose? Are the metrics still showing the right signals? These questions help leaders catch design drift before it turns into structural friction.
It is also worth reviewing the model after major events. A merger, a product launch, a technology migration, or a shift in customer demand can all expose weaknesses in the existing setup. Rather than waiting for pain to accumulate, use those events as checkpoints. They are often the moments when the organization is most open to change.
Another good practice is to keep the design principles visible. If the business has agreed that decisions should stay close to the customer, or that shared work should live in one place, those principles should guide future changes. Otherwise, every new initiative starts to bend the model in a different direction.
Finally, remember that maintenance is partly about language. As teams change, the original logic can fade. New managers may not know why the model was designed a certain way. A short, clear narrative about the operating model helps preserve intent. It makes the system easier to explain, easier to defend, and easier to improve.
A good operating model should feel stable enough to trust and flexible enough to evolve. That is the real standard. It should help the business move with less confusion today, while still leaving room to adapt tomorrow.
That is why operating model consulting matters. Done well, it helps leaders turn ambition into a system that can actually carry the work.