Even a strong design logic will fail if the program itself is poorly set up. This chapter shows you how to define scope, governance, roles, and a realistic workplan for the org design effort. You’ll learn how to build an effective steering committee, a core design team, and working teams, and how to sequence the work so that decisions are made at the right level, in the right order, without burning out the organization.
5.1 Scope: What Is In and Out of the Redesign
Once you have clarified the strategic intent and the case for change, the next step is to shape the organizational design program itself. If you skip this step and jump straight into drawing options, the effort will tend to sprawl, burn out leaders, and produce designs that are either too narrow to matter or too broad to implement. Shaping the program starts with scope: being crystal clear on what is in and what is deliberately out.
Scope has three dimensions: organizational scope, topic scope, and time scope.
Organizational scope defines which parts of the enterprise are affected. Are you designing at the enterprise level, a business unit, a function, or a specific geography? Within that, are all sub-units in play, or only some? For example, you may decide that the global commercial organization is in scope, while manufacturing and supply chain will only be touched where interfaces are affected. Making these boundaries explicit prevents every pain point in the company from being pulled into the redesign.
Topic scope clarifies which aspects of the operating model you will address. This playbook focuses on structure and closely related elements such as roles, governance, and decision rights. However, many redesigns sit within broader transformations that include process reengineering, technology renewal, and culture change. You must decide whether the org design program will cover only structural choices or explicitly include adjacent topics. If you try to solve every process and system issue through structure, the effort will balloon and lose focus.
Time scope covers both the horizon and the implementation window. On the horizon, you should be explicit about designing for the next three to five years, not for a hypothetical distant future. On the implementation window, be realistic: how much change can the organization absorb over the next 12–24 months? If the answer is “not much,” you may need to phase the scope, starting with the most critical units or topics and leaving others for later waves.
A simple scoping template can help you lock this down on a single page:
- Level: Enterprise / business unit / function / geography.
- Units in scope: List of specific units included.
- Units explicitly out of scope: List of units excluded, with rationale.
- Topics in scope: Structure, roles, governance, decision rights; plus any adjacent areas.
- Topics out of scope: For example, detailed process redesign or core system replacement.
- Time horizon: Design for the next X years.
- Implementation window: Target for initial go-live and completion of major moves.
Work this template with the CEO or primary sponsor, the CHRO, and any other critical leaders. Expect pushback; everyone has issues they would like to include. The discipline is to ask, for each proposed addition: “Is this essential to achieving our design objectives, or is it a related but separate problem?” If it is the latter, park it in a parallel track.
A short, practical sequence for scoping looks like this: first, list all units and topics that stakeholders would like to see addressed. Second, classify each item into “must include,” “nice to include,” or “out of scope for now” based on its direct link to the design objectives. Third, check feasibility against capacity and timing. Finally, document the result and communicate it broadly so that everyone sees the same boundaries. This reduces later surprises when a favored topic is not picked up by the design teams.
5.2 Governance: Steering Committee, Design Authority, Working Teams
With scope defined, you need governance that will make decisions at the right level and pace. Poor governance is one of the most common reasons org design programs stall. Either every choice is escalated to the CEO, creating bottlenecks, or decisions are pushed down without a clear mandate, leading to rework when the top team later disagrees.
Most effective programs use a simple three-tier governance model:
- Steering committee (sponsors).
This is the top-level body that owns the outcomes of the redesign. It typically includes the CEO or business-unit head, key executives whose areas are in scope, and the CHRO. Its responsibilities are to confirm scope and objectives, approve design principles, make the big structural calls, and remove roadblocks. - Design authority (core design team).
This is a small group—often 4–8 people—responsible for day-to-day design work and for integrating inputs from across the organization. It usually includes senior HR or organization experts, strategy or transformation leads, and a few respected line leaders. The design authority prepares options, tests them against principles and data, and makes recommendations to the steering committee. - Working teams (content and engagement).
These are cross-functional teams that dive into specific areas: for example, the structure of a function, decision rights around a key value stream, or the design of shared services. They bring detailed knowledge of how work is done and how customers and employees experience the current organization.
Governance only works if each tier has clearly defined decision rights. A practical way to frame this is to specify, for each type of decision, whether the steering committee will decide, the design authority will decide, or the working teams will decide within guardrails. For example:
- Overall macro-structure, P&L allocation, and location of major functions: steering committee decision.
- Design principles, span-and-layer guidelines, and standard role archetypes: steering committee approval on recommendation from design authority.
- Detailed team structures within a function and individual role profiles: working team decision within the approved design parameters.
You do not need an exhaustive RACI for every decision, but you do need enough definition to prevent constant escalation and second-guessing. One or two pages of “who decides what” for the major decision categories is usually sufficient.
Finally, remember that governance is not only about forums and documents; it is about cadence and behavior. The steering committee must commit real time—typically monthly for major decisions and more frequently during critical design windows. The design authority must be empowered to challenge sacred cows and bring unvarnished facts. Working teams must understand that their job is to design for the enterprise, not to defend their current turf.
A common pitfall is to treat the steering committee as a “readout” forum rather than a decision body. If meetings are packed with dense slides and end with “we’ll come back next time,” the program will lose momentum. Design authority leaders should be explicit that each steering-committee session has a small number of concrete decisions to make, with pre-reads sent early enough for members to form a view. Likewise, working teams should experience real guidance from the design authority, not just requests for more analysis.
5.3 Roles and Responsibilities in the Design Effort
Even with governance defined, org design programs can stall if people do not know what is expected of them personally. You should therefore define roles and responsibilities explicitly for a handful of key positions in the program.
At the top is the sponsor, usually the CEO or business-unit head. The sponsor’s responsibilities include setting direction, making trade-offs, and role-modelling the behaviors needed for the new organization. They chair the steering committee, communicate the case for change, and are the final decision-maker on contested structural choices. A sponsor who delegates all design decisions to others risks ending up with a structure that looks tidy on paper but does not reflect their real priorities.
Next is the program lead. This may be the CHRO, a strategy or transformation leader, or a senior executive with strong cross-enterprise credibility. The program lead runs the day-to-day effort: shaping the workplan, coordinating design teams, preparing materials for decision meetings, and ensuring integration across topics and units. They are the single point of accountability for “making the redesign happen” and for surfacing issues early.
The HR or organization design lead brings method expertise. They ensure that the team applies robust design logic, uses data on spans and layers and headcount, and considers talent and change implications in each design choice. They are often the architect of templates for role charters, decision-rights matrices, and new governance forums. In smaller organizations, this role and the program lead role may be combined.
Business and functional leaders whose areas are in scope have a dual role. They are both designers and subjects of the design. They must contribute content expertise about how work is done and what customers require, while also being open to seeing their mandates reshaped. Their responsibilities include nominating strong people to working teams, providing access to data and talent, and actively engaging in option development rather than simply reacting to proposals.
Finally, you will likely need analytics and PMO support. Analytics support gathers and structures the data: organizational charts, spans and layers, headcount, cost, performance indicators, and survey results. PMO support tracks progress against the workplan, manages interdependencies, organizes workshops and steering-committee sessions, and maintains the decision log.
A simple “role charter” for each of these positions is helpful. It should specify:
- Purpose of the role in the redesign.
- Key responsibilities.
- Time commitment expected.
- Decisions the role can make independently.
- Decisions the role prepares but does not make.
Review these charters with the individuals concerned before launch. Many org design efforts underestimate the time commitment required, especially from business leaders. Being explicit upfront reduces the risk of key people dialing down their engagement partway through the project.
As a rough guide, sponsors may need to devote a few hours a month to formal meetings plus additional time for bilateral discussions; the program lead and HR design lead will spend a substantial portion of their week on the effort; working-team members may need one to two days a week during intense design periods. If you cannot realistically free up that time, narrow the scope or extend the timeline. Pretending that people can do a full org redesign “off the side of their desk” is one of the fastest routes to shallow designs and missed deadlines.
5.4 Workplan, Milestones, and Cadence of the Project
With scope, governance, and roles in place, you can build the workplan. The goal is not to create a perfect Gantt chart, but to establish a clear sequence of activities and decision points with an agreed cadence. A well-structured workplan keeps the effort moving and reduces anxiety in the organization by showing when decisions will be made and when changes will take effect.
Most org design programs follow four broad phases:
- Mobilize and frame (weeks 1–4).
Confirm scope, governance, and roles. Refine the case for change and design objectives. Develop design principles. Build the initial data pack on current structure, performance, and organizational health. - Diagnose and hypothesize (weeks 5–8).
Conduct interviews and workshops, analyze spans and layers, map value streams and decision points, and synthesize the main organizational issues. Develop initial design hypotheses—high-level options that respond to the strategy and problems uncovered. - Design and decide (weeks 9–16).
Flesh out macro-structure options, test them against the principles and objectives, and narrow to a preferred design. Then design micro-structures, roles, and decision rights. Quantify financial and performance implications. Secure steering-committee approval at key milestones. - Plan implementation (weeks 17–24 and beyond).
Translate the design into implementation waves, define transition states, plan communications, and coordinate with HR, legal, and IT for changes to roles, contracts, systems, and locations. Prepare leaders to communicate and lead the change.
Within this high-level sequence, identify critical milestones. Examples include:
- Agreement on design principles.
- Sign-off on the problem statement and design objectives.
- Selection of a preferred macro-structure option.
- Approval of spans-and-layers guidelines.
- Completion of detailed design for each major unit.
- Final decision on key leadership appointments and role profiles.
- Approval of the implementation roadmap and communication plan.
For each milestone, define what “ready” looks like: what analyses, options, and stakeholder inputs must be in place before the steering committee can decide. This avoids repeated “discussion” meetings where no decision is possible.
Cadence is equally important. A practical rhythm is:
- Steering committee: every 3–4 weeks during heavy design periods, with shorter check-ins as needed.
- Design authority: weekly working sessions to review outputs from teams, iterate options, and prepare materials.
- Working teams: weekly or biweekly, depending on scope, with clear deliverables between meetings.
You can visualize the workplan on a single page: phases along the top, milestones and key meetings plotted over time, and major deliverables aligned underneath. This becomes the backbone of your project management.
Two final cautions on workplanning:
- Build in time for iteration and socialization. Designs almost always require at least one full cycle of feedback from senior leaders and key stakeholders. If your plan assumes that each structure option will be decided in a single meeting, you will either slip or railroad decisions.
- Coordinate with other major initiatives. If a technology rollout, merger integration, or cost program is occurring in parallel, align milestones to avoid overloading the same people at the same time or making conflicting design assumptions.
A straightforward way to draft the workplan is to start from the steering-committee calendar: mark the dates when major decisions can realistically be taken, then work backward to define what each working team must deliver in advance. Check that the workload is balanced across weeks and that key individuals are not double-booked across critical activities. Share the resulting plan widely so that managers and teams understand when they will be asked for input and when they can expect clarity about future roles and structures.
A well-shaped org design program does not guarantee a perfect outcome, but it dramatically increases your chances. By being deliberate about scope, governance, roles, and workplan, you create the conditions for your leadership team to make sound structural choices and to implement them with confidence.
