The program was a store systems modernization for a mid-market retailer: fourteen stakeholders across five functions (Technology, Store Operations, Merchandising, Finance, and the Transformation Office), seven workstreams, and an eighteen-month execution timeline.
Intake reveals hidden contradictions
The consulting team asked for everything that existed. What came back were three separate roadmaps, each built by a different function, each telling a different story about the same program. Technology had the integration platform going live in Q2. Store Operations had built their pilot plan around a Q3 platform launch. The Transformation Office had a timeline that referenced neither date. The intake baseline compiled all three into a single view, and the contradictions became visible. The program had been running for two months without a shared understanding of when its central dependency would be ready. Each function had planned responsibly within its own context; the failure was that nobody had compiled the plans into an integrated view.
Stakeholder conversations surface what plans cannot
Fourteen one-on-ones surfaced what the plans could not. The VP of Store Operations predicted that regions would resist the pilot store selection because regional directors had not been consulted. The Technology lead disclosed that the integration vendor had missed delivery dates on two previous projects and that the Q2 target was optimistic. The Merchandising representative revealed an unmapped dependency: the new system required a product data migration that Merchandising owned but had not staffed. The stakeholder map captured alignment and concerns, plus three critical dependencies that existed only in individual knowledge.
Program architecture makes the system visible
The architecture session put the dependency diagram on the wall: seven workstreams with their owners and the connections between them. Technology’s platform delivery fed four other workstreams. Store Operations’ pilot sequencing depended on both Technology and Merchandising. Change Management’s training plan depended on outputs from three workstreams that had not committed delivery dates. This was a system, and the weakest connection determined the pace of the whole.
Pre-mortem surfaces risks before they become crises
The pre-mortem asked the team to assume the program had failed eighteen months from now and name the most likely reasons. Silent writing ensured each participant documented failure modes individually before anyone spoke. The highest-priority failure mode was a timing conflict: the March inventory count across the pilot store group collided with the integration testing window. Neither team had seen the other’s calendar; the pre-mortem surfaced it five months before it would have become a crisis. The constraints calendar compiled all windows when the organization could not execute:
- The November code freeze
- The holiday peak
- The March inventory counts
- The May annual planning cycle
The available execution windows were smaller than anyone had assumed.
Roadmap sessions build what no single function could
The roadmap sessions ran over three days. The team built the integrated plan on top of the architecture, dependency map, risk register, and constraints calendar, using a 70/30 co-creation approach. The original timeline did not fit the constraints calendar. The March testing window had to move, the pilot sequence had to be restructured, and two workstreams needed to compress their timelines to accommodate the inventory count window. By the third day, the integrated roadmap was on the wall: seven workstreams sequenced against constraints, with dependencies mapped and milestones aligned. The team had built something none of them could have built alone, because no single function had visibility into the full picture.
Governance connects directly to identified risks
The operating model session designed the governance structure. After three days of creative roadmapping, designing meeting cadences and escalation paths can feel bureaucratic. We connected each element to a specific pre-mortem risk. The biweekly integration review existed because the dependency map showed four critical handoffs that would drift without structured oversight; the escalation path existed because the pre-mortem identified two cross-functional conflicts the workstream leads could not resolve alone. The new operating model replaced eleven organic recurring meetings per week with five, each with a named decision type. Meeting load dropped by roughly 40 percent.
Change management and rollout earn each wave
Change management designed the communication and training plan for store partners. The pre-mortem had identified the training dependency gap: the curriculum needed system configurations that would not be finalized until after training was scheduled to begin. The team designed a phased approach with foundational content delivered first and system-specific training in a compressed window after go-live configuration was locked. Rollout planning sequenced pilot stores into two waves with go/no-go criteria. The first wave was three stores representing different formats and regions. The gate required confirmation that:
- Integration was stable and training had been completed
- Store teams could operate the new system without hypercare support
The team owns the plan
The program lead presented the architecture to the executive sponsor. Workstream leads presented their scopes and dependencies. The risk register, now evolved into a decision log, showed thirty-seven decisions the team had resolved during the engagement. We were in the room but were not presenting. The program lead fielded the executive sponsor’s questions; the workstream leads explained the tradeoffs they had made. The readout demonstrated that the team owned the plan and could execute it independently. The emotional arc of the engagement followed the W-curve from vulnerability through discomfort through ownership, and designing that arc on purpose is what made it productive rather than accidental.
