Approval of a chart does not establish that the organization can work under it. A credible schedule makes the decisions and operating dependencies visible.
An approved organization chart can arrive before the company knows who will authorize spending under the new structure. Calling that date “implementation complete” hides unfinished work inside a finished document. The operating teams inherit the uncertainty when the project team leaves.
An organizational design timeline should distinguish approval of the design from the point at which people can work under it. A credible estimate depends on the decisions still open, the dependencies that constrain their order and the evidence required to close the transition. It cannot be inferred from the number of boxes on a chart.
The distinction matters when interpreting published research. McKinsey’s June 25, 2025 analysis of a global survey of 2,000 executives across 16 sectors reported that 79% of redesigns were completed and implemented, while 63% met most objectives and improved performance. These are different reported outcomes, not interchangeable definitions of success or a forecast for an individual company (McKinsey’s redesign research).
What should an organizational design timeline actually cover?
The first question is what the sponsor intends to have working at the end. Redrawing reporting relationships is a narrower assignment than changing how businesses allocate resources or resolve conflicting customer commitments. The estimate should name the boundary rather than leave it to be discovered after approval.
Start with the business decision that requires a different organization. A company may need local teams to respond to customers without waiting for headquarters, while retaining central authority over commitments that affect other markets. That requires explicit boundaries. It does not necessarily require changing every reporting relationship.
Our organizational design practice connects roles and decision authority to the work the organization must carry. For scheduling purposes, the sponsor should identify which of those arrangements will change and which remain fixed. A plan that includes everything offers no useful basis for prioritizing.
Distinguish the design decision, the transfer of operating authority and the subsequent review of whether the new arrangement works. These are separate commitments with different evidence. They may overlap, but combining them into a single completion label makes slippage difficult to locate and responsibility easy to dispute.
What needs to be known before an adviser can estimate duration?
A useful estimate begins with access to the people and information needed to resolve the design. If the sponsor cannot convene the executives who own competing mandates, more analytical work will not settle the disagreement. The schedule should reserve decision time, not merely workshop time.
The starting evidence also matters. Formal role descriptions may differ from the work people actually perform. Before promising a date, the team should establish how it will trace consequential decisions through the organization and check those observations with the people involved. An outdated chart is not a reliable inventory of current authority.
Ask the adviser to separate committed dates from assumptions. A target may depend on approval by a particular committee, the availability of a system change or a hiring decision outside the project’s control. Naming the dependency does not remove it. It makes the estimate testable and tells the sponsor where intervention could matter.
This is why an organizational design timeline should be presented with a basis of estimate. That basis can state the included businesses, the decision owners, the evidence still needed and the conditions that would trigger revision. A date without those conditions is a promise whose meaning can change after it is made.
Which work can proceed together, and what must wait?
Not all uncertainty requires the entire project to stop. Teams can examine current workflows while the sponsor clarifies strategic priorities. They can also investigate technology constraints before the final structure is selected. Those activities inform decisions without pretending that the decisions have already been made.
Other work has a real sequence. A role cannot receive final authority over spending before the company has settled the relevant delegation limits. Communications about a manager’s responsibilities should not precede agreement on who resolves exceptions. Running these tasks together may create rework rather than save time.
McKinsey’s August 7, 2025 practice article identifies misalignment between organizational changes and technology, budgeting and resourcing workflows as recurring transformation pitfalls. Its guidance is to account for those changes within the overall roadmap, rather than treat the organizational announcement as sufficient (McKinsey’s implementation guidance).
A practical application is to map each material dependency to an owner and an observable condition. “Finance engaged” is not a condition. “The receiving manager can authorize the agreed expenditure within the new limit” is something the implementation team can verify. The schedule should show when that verification will happen.
How can a pilot shorten uncertainty without hiding risk?
A pilot is useful when it answers a specific question about the proposed arrangement. It should expose a consequential handoff under controlled conditions, not simply collect favorable reactions to the new chart. Its boundaries must protect operations and make clear which authority remains unchanged.
Consider a hypothetical industrial group testing a new division of authority between a plant and a shared purchasing team. A limited trial could examine who decides when an urgent replacement conflicts with a group purchasing agreement. The observation should cover the exception and its resolution, not only a routine order that everyone already knows how to process.
The sponsor should agree in advance what would justify expansion, what would require redesign and what would stop the trial. Otherwise, a pilot can become a ceremonial step whose conclusion was fixed before it began. Learning only has scheduling value if the result is allowed to change the next decision.
The organizational design timeline should therefore include time to interpret the pilot, not just time to run it. A documented exception may reveal an unresolved boundary, a missing skill or an information problem. Each calls for a different response. Extending the trial without identifying the cause merely postpones the same uncertainty.
When should the board accept that implementation is complete?
Completion needs a definition the receiving organization can demonstrate. Attendance at a briefing shows that communication occurred. It does not show that a manager can exercise the new authority, that a disputed handoff has an owner or that the old approval route has ceased to operate.
Before the transfer, identify the person accountable for accepting the new arrangement into ordinary operations. That person should be able to explain what has changed, what remains temporary and where unresolved issues go. The project sponsor should not sign off on behalf of people who have not had the opportunity to test the work.
For a board overseeing the change, the closing paper should distinguish delivery evidence from business results that take longer to observe. New authorities may be functioning while the expected commercial outcome remains unproven. Reporting that distinction preserves accountability without manufacturing either premature success or premature failure.
Our earlier article on what organizational design consulting installs addresses the substance of the engagement. The timing question adds a different discipline: the organizational design timeline should make the transfer into ordinary work visible, including who owns any remaining conditions after the adviser leaves.
Frequently asked questions
How long should an organizational design project take?
There is no defensible universal duration without an agreed scope and starting evidence. A change limited to a few decision boundaries differs from an enterprise operating-model change. Ask for an estimate tied to named dependencies, decision availability and acceptance conditions, with a clear distinction between design approval and implementation.
Can implementation begin before the whole design is approved?
Yes, where the work is bounded and does not prejudge unresolved decisions. A pilot can test a proposed handoff while other areas remain unchanged. Its authority, safeguards and stopping conditions should be explicit, and its findings must be able to alter the wider design rather than merely endorse it.
What should happen when the promised completion date slips?
Revisit the organizational design timeline against the assumptions that supported it. Identify whether the constraint is an unresolved decision, missing evidence or an operating dependency. Then agree the consequence for scope and timing. Moving the date without identifying what must change leaves the sponsor with the same uncertainty.
Before accepting the next completion date, ask who will demonstrate that the new arrangement can handle a difficult exception without returning to the old chain of approval. Bring that implementation question to Anker Bioss so the schedule is built around the work that must become possible.