This article walks through a completed Risk Landscape from a multi-year platform transformation at a Fortune 500 financial services company. The initiative involved replacing a twenty-year-old core banking platform across retail, commercial, and wealth management divisions. The Risk Landscape was built over a two-week period following the Architecture Blueprint, using both a group pre-mortem and confidential one-on-one risk conversations. The walkthrough follows the artifact component by component, showing what the consultants surfaced, how they structured it, and where specific risk decisions directly shaped the Integrated Roadmap that followed.
The Engagement Context
The organization had attempted a platform replacement five years earlier. That effort was cancelled after eighteen months when cost overruns and integration failures made the business case untenable. The cancellation cost the organization approximately forty million dollars in sunk costs and set back the technology modernization agenda by three years. The second attempt began with the executive committee’s explicit mandate: identify what killed the first attempt and design the second attempt to prevent those failure modes. The Risk Landscape was the primary mechanism for fulfilling that mandate.
Component 1: The Pre-Mortem
The consultants ran three pre-mortem exercises: a group pre-mortem with the program leadership team, a cross-functional cascade with separate sessions for Technology, Operations, and Business stakeholders, and confidential one-on-ones with twelve senior leaders. The group pre-mortem generated twelve failure modes. The most frequently cited: “We failed because the data migration was more complex than estimated, and we didn’t discover the complexity until we were in the middle of it.” This was expected. It was also the primary failure mode from the first attempt. The cross-functional cascade identified three compound risks invisible to individual functions. The most consequential: Technology’s assumption about the vendor’s implementation support capacity contradicted the vendor’s actual commitment (known to Procurement but not shared with Technology), while Operations assumed a parallel-run period that Technology’s timeline did not accommodate. The compound risk: the program would reach deployment without adequate vendor support during a parallel-run period that was shorter than Operations required. The confidential conversations identified two political risks. First, the wealth management division’s CTO had privately expressed doubt that the new platform could handle the complexity of wealth management products, but had not raised this concern publicly because the executive committee had already committed to a single-platform approach. Second, the program’s executive sponsor was expected to rotate to a new role within twelve months, and two likely successors had different views on the program’s priority. The pre-mortem’s narrative takeaway: “The program’s highest-risk failure mode is a repeat of the first attempt: data migration complexity exceeding estimates, compounded by insufficient vendor support capacity and a parallel-run period that does not meet Operations’ requirements. The political risks (wealth management complexity concerns and sponsor succession) create conditions where these technical risks may not receive the organizational attention they require if they materialize.” Why pre-mortems change the conversation describes the facilitation techniques used. The confidential conversations were the mechanism that surfaced the political risks.
Component 2: The Risk Register
The register compiled thirty-four risks from all pre-mortem exercises, stakeholder mapping, architecture sessions, and the calendar overlay. The consultants categorized them into three priority tiers. Tier 1: Active mitigation (7 risks). The seven risks with the highest likelihood-impact combination, each with a named owner, a specific mitigation plan, and a timeline for mitigation actions. The top three: data migration complexity, vendor support capacity, and parallel-run duration. Tier 2: Monitored (15 risks). Risks with sufficient likelihood or impact to warrant tracking but not requiring active mitigation. Each had a named owner responsible for monitoring and trigger conditions that would escalate the risk to Tier 1. Tier 3: Accepted (12 risks). Risks the program acknowledged but chose not to mitigate because the likelihood was low, the impact was manageable, or the cost of mitigation exceeded the expected cost of the risk materializing. Each accepted risk was documented with the rationale for acceptance. The discipline of documenting accepted risks mattered. Two of the twelve accepted risks were later escalated to Tier 1 when circumstances changed. Because the acceptance rationale was documented, the escalation conversation was productive: “The conditions have changed. The original acceptance rationale no longer applies.” Without documentation, the escalation would have required re-litigating whether the risk was real. The risk nobody put on the register documents the failure pattern when risks are surfaced but not structured. This register’s value was in the structure, not just the identification.
Component 3: The Calendar Overlay
The overlay mapped the program’s thirty-month timeline against four operational calendars: the bank’s regulatory filing schedule, the technology change-management calendar, the business divisions’ annual planning cycle, and the vendor’s implementation resource availability. The overlay produced specific timeline adjustments. First, the planned data migration start date fell during the bank’s annual regulatory examination period, when Technology resources would be diverted to examination support. The start date was moved by six weeks to avoid the conflict. Second, the planned parallel-run for commercial banking coincided with the division’s year-end close process, when operational staff would be unavailable for parallel-run monitoring. The parallel-run was moved to Q1 of the following year. Third, the vendor’s implementation team had a contractual commitment to another client during months eight through eleven of the program. The vendor had committed resources to the program during that period, but the overlay revealed that those resources would be split between two clients. The program renegotiated the vendor agreement to secure dedicated resources during the critical integration phase. The three adjustments added approximately four months to the original thirty-month timeline. The program leadership initially resisted the extensions. The calendar overlay provided the evidence: proceeding with the original timeline would require resources that were not available, operational attention that was committed elsewhere, and vendor support that was contractually split. The risk nobody put on the register describes why timing collisions are consistently among the highest-impact risks that planning teams fail to identify. This overlay prevented three collisions that would have been discovered during execution.
Component 4: The Principles and Guardrails
The principles document contained five principles and corresponding guardrails. Three of the five were direct responses to failure modes from the first attempt. Principle 1: No deployment without complete data reconciliation. The first attempt had deployed with unreconciled data, producing customer-facing errors that damaged the bank’s reputation. The guardrail: data reconciliation must achieve 99.97% accuracy before deployment approval. The override authority was the Chief Risk Officer, not the program director. Principle 2: Parallel-run duration is non-negotiable. The first attempt had compressed the parallel-run period under timeline pressure. The guardrail: minimum twelve-week parallel run for each division, with go/no-go gates at weeks four and eight. The override authority was the executive committee, requiring a formal vote. Principle 3: Vendor escalation at the first missed milestone. The first attempt had allowed vendor delays to accumulate before escalating. The guardrail: any vendor milestone missed by more than five business days triggers automatic escalation to the vendor’s executive sponsor and the program’s executive sponsor simultaneously. The principles document was endorsed by the executive committee in a recorded session. The endorsement was not a formality. It was a commitment that the committee referenced three times during execution when guardrails came under pressure. Programs that failed with good plans documents the first attempt’s failure in detail. The second attempt’s principles were designed as direct countermeasures to the specific failure modes that cancelled the first.
What the Roadmap Team Received
The roadmap team entered roadmap sessions with a Risk Landscape that specified: eight pre-mortem failure modes requiring mitigation through roadmap design, seven Tier 1 risks with active mitigation plans that the roadmap needed to accommodate, three calendar-driven timeline adjustments already incorporated, and five guardrails that the roadmap could not violate. The roadmap was built with these constraints visible from the start. Buffer periods were built around the highest-risk milestones. The parallel-run periods were sized to meet the guardrails. The vendor’s resource availability was reflected in the sequencing. The question is whether your Risk Landscape gives the roadmap team the constraints, risks, and guardrails they need to build a realistic plan: or whether those realities surface during execution when the cost of adjustment is highest.
Go Deeper: The Risk Landscape
This article covers one dimension of the Risk Landscape, the fourth of nine artifacts in the Planning & Roadmapping method. The Risk Landscape answers the board question: “What could break this?” Explore the full Risk Landscape →
Keep Reading
Explore the foundations and common gaps: