These three programs had strong roadmaps. Dependencies were mapped. Milestones were defined. The critical path was identified. What they lacked was the operating infrastructure to keep execution coordinated: role definitions that created accountability, governance that enabled decisions, and cadence that maintained alignment. Each program discovered that a plan without an Operating Model degrades faster than anyone expects.
Program 1: The Technology Consolidation That Couldn’t Make Decisions
A telecommunications company launched a technology consolidation program to merge three billing platforms into one. The planning phase produced a detailed Integrated Roadmap with clear workstream definitions, dependency mapping, and a twenty-month critical path. The program did not produce an Operating Model. Governance was assumed: the program director would make cross-functional decisions, the steering committee would handle escalations. No one defined decision types, authority levels, information requirements, or turnaround expectations. In month three, the program hit its first cross-functional trade-off: the data migration approach required choosing between two strategies, each favoring a different business unit’s requirements. The workstream leads could not agree. They brought the decision to the program director. The program director needed information from both business units that had not been assembled. The information gathering took two weeks. The program director made a recommendation to the steering committee. The steering committee met biweekly; the next meeting was nine days away. The steering committee discussed the trade-off but wanted additional analysis. The analysis took another week. The decision was made five weeks after the issue was surfaced. During those five weeks, three dependent workstreams could not proceed. The five-week decision stall cost the program seven weeks of delay (the five weeks plus two weeks of rework to accommodate the decision in plans that had continued under the wrong assumption). The program experienced four similar decision stalls in the first eight months; the cumulative delay exceeded the roadmap’s total buffer. The twenty-month program completed in twenty-seven months. Governance design would have specified: this type of decision (cross-functional technical trade-off) is owned by the program director with a five-business-day turnaround. Information requirements are defined in advance. If the decision requires steering committee input, the program director can convene an ad hoc session rather than waiting for the biweekly meeting. The Decision Escalation Framework sub-artifact is where these pathways are codified. Programs that failed with good plans documents the decision-stall pattern. The decisions were not difficult. The process for making them was undefined.
Program 2: The Shared Services Build That Lost Visibility
A healthcare company launched a shared services program to consolidate finance, HR, and procurement operations across four regional offices. The program had six workstreams, each with a detailed plan and clear milestones. No outputs catalogue was designed. Each workstream reported status using its own format, on its own timeline, to its own leadership. The program director received six different status reports in six different formats on six different days of the week. By month two, the program director could not answer a basic question from the executive sponsor: is the program on track? The workstreams each reported green, but their definitions of green differed. One workstream reported green because all activities were proceeding. Another reported green because no one had raised an issue. A third reported green because their milestones were on track, even though a dependency from another workstream was three weeks late. The executive sponsor lost confidence. They began requesting ad hoc updates, which consumed workstream leads’ time. The ad hoc updates triggered additional meetings, which consumed more time. Within three months, the program was spending more time reporting on work than doing work. An outputs catalogue would have defined: one consolidated status report, produced weekly by the program management office, using a standard template that captures milestone status against the roadmap, dependency status, risk status, and resource status. Each workstream provides inputs using the same template by the same deadline. The consolidated view takes thirty minutes to assemble, not three days. The roadmap that tells you nothing describes the visibility failure: without consistent outputs, the program’s actual state is invisible to leadership. The roadmap exists but cannot be compared to reality.
Program 3: The Digital Product Launch That Ran on Heroics
A consumer products company launched a digital product platform across three markets. The program had four workstreams: product development, market operations, technology infrastructure, and regulatory compliance. The planning phase was thorough. The Integrated Roadmap was stress-tested. The Risk Landscape was comprehensive. No cadence calendar was designed. No enablers pack was created. The program relied on the program director’s personal coordination: remembering which teams needed to connect, scheduling meetings as issues arose, following up on commitments through individual conversations. The Operating Rhythm sub-artifact is designed to replace exactly this kind of heroic personal coordination with structural mechanisms. For the first three months, this worked. The program director was experienced and relentless. The teams stayed coordinated because one person held the entire picture in their head and personally ensured every handoff happened. In month four, the program director was out for two weeks due to a family emergency. No one else had the full picture. No recurring meetings existed to identify cross-workstream issues. No templates existed for status updates. No governance process existed for the three decisions that needed to be made during those two weeks. The program lost two weeks of coordination. When the program director returned, three workstreams had diverged from the plan based on assumptions that had not been validated. The recovery took an additional three weeks. The total cost was five weeks of delay, plus the organizational learning that the program was a single point of failure. The program director implemented an Operating Model after returning: a cadence calendar, an outputs catalogue, and an enablers pack. The second half of the program ran on infrastructure rather than heroics. The program completed four weeks late, all of which were attributable to the coordination gap in months four and five. Why programs fail identifies the heroics pattern: programs that run on individual coordination rather than structural coordination. The hero is effective until they are unavailable, and then the program discovers it has no operating infrastructure.
The Common Pattern
All three programs had strong plans. The technology consolidation had a detailed roadmap. The shared services build had clear milestones. The digital product launch had a comprehensive Risk Landscape. None of them had the operating infrastructure to keep execution coordinated. The Operating Model is not the exciting part of program planning. Role definitions, outputs catalogues, cadence calendars, and enablers packs do not generate the intellectual energy that architecture design or roadmap integration generates. They are the plumbing. But programs fail at the plumbing level more often than they fail at the architecture level. A strong plan with weak operating infrastructure produces the same outcome as a weak plan: disconnected execution, lost visibility, stalled decisions, and timeline overruns that accumulate until the buffer is consumed and the program is in recovery mode. The question is whether the team builds the machinery before execution starts: or whether they build it in recovery mode after the first coordination failures have already consumed the buffer.
Keep Reading
Ready to close specific gaps in your Operating Model? These articles show you how: