Unexamined risk does not disappear; it waits. Programs that skip the pre-mortem, operate with a shallow risk register, or ignore the operational calendar do not eliminate the risks those tools would have surfaced. They encounter them during execution, when the cost of response is highest and the options for mitigation are most constrained. These three cases illustrate different categories of unexamined risk. Each program had competent teams and reasonable plans. Each carried risks into execution that were knowable during planning. Each paid a price that planning-stage risk identification would have reduced or prevented.
Case 1: The Unnamed Risk
A technology company launched a platform migration affecting its core product. The planning team conducted a standard risk assessment: technical risks were cataloged, resource risks were scored, and timeline risks were flagged. The risk register had forty-seven items. The risk that was not on the register: the customer success team’s quarterly business reviews with enterprise clients were scheduled during the same period as the migration’s production cutover. The customer success team would need to demonstrate platform stability to clients during the exact period when the platform would be most unstable. This risk was knowable. The customer success calendar was available to anyone who asked. The program team did not ask because the risk identification process focused on technical and resource risks. Operational risks from adjacent functions were not in scope. The collision identified two weeks before cutover when the customer success VP raised an escalation. The program faced a choice: delay the cutover by three weeks (disrupting the technical team’s resource commitments for the next quarter) or proceed and manage client-facing instability during business reviews. The program chose to delay, at a cost of approximately four hundred thousand dollars in extended consulting engagement fees and deferred benefits realization. A pre-mortem would have surfaced this risk. The question “if this program fails, what are the most likely reasons?” asked in a room that included customer success leadership, would have produced the answer: “We failed because we migrated the platform during our most important client interaction period.” The risk nobody put on the register describes this pattern: risks that exist outside the program’s functional boundary but directly affect the program’s success.
Case 2: The Timing Collision
A retail company launched a supply chain optimization program with a targeted go-live in October. The program team built the timeline based on technical milestones and resource availability. The timeline was feasible from a technical perspective. The timing collision: October through December was the organization’s peak operational period. Warehouse capacity was at maximum utilization. Supply chain staff were operating at peak workload. The technology team that supported supply chain operations was in change-freeze mode, prohibiting any system modifications that could disrupt holiday fulfillment. The program’s go-live required system changes that violated the change freeze. It required warehouse staff participation in user acceptance testing during their busiest period. It required supply chain leadership attention during the quarter when their primary focus was operational execution. The program discovered these collisions in August, two months before go-live. The delay to January cost the organization a full quarter of anticipated benefits. The delay also required renegotiating consultant contracts and re-baselining the business case. A calendar overlay would have identified the collision during planning. Mapping the program timeline against the operational calendar would have shown that an October go-live was incompatible with the organization’s operating rhythm. The planning team could have designed for a January go-live from the start, avoiding the wasted effort and renegotiation costs. Why pre-mortems change the conversation explains why timing collisions are consistently underestimated: planning teams focus on what the program needs to do and underweight what the organization is already doing.
Case 3: The Compromised Guardrail
A healthcare organization launched a clinical system implementation with a clearly stated principle: no go-live without full clinical workflow validation by nursing staff. The principle was documented in the project charter and endorsed by the executive sponsor. The program fell behind schedule. Integration testing took longer than planned. The timeline compressed, and the program team faced a choice: delay go-live by four weeks to complete clinical workflow validation, or proceed with partial validation and manage the remaining validation during the first week of live operation. The program had no principles and guardrails document that specified what “full clinical workflow validation” meant, who could waive the requirement, or what the escalation process was for changing a stated principle. The principle existed as a sentence in the project charter, not as an operational guardrail with enforcement mechanisms. The program manager and the clinical lead made a pragmatic decision: proceed with partial validation. The nursing staff had validated the twenty highest-volume workflows. The remaining twelve were lower volume and could be validated during the first week. During the first week of live operation, one of the twelve unvalidated workflows contained a medication dosing calculation error. The error was caught by an experienced nurse before it reached a patient, but the incident triggered a patient safety review that suspended the system for three days while all workflows were re-validated. The three-day suspension cost more in operational disruption and organizational credibility than the four-week delay would have. A principles and guardrails one-pager would not have prevented the schedule pressure. It would have defined: what “full clinical workflow validation” specifically means (all workflows, not a sample); who has authority to waive the requirement (the Chief Medical Officer, not the program manager); and what the escalation process looks like when the guardrail is under pressure. The guardrail would have routed the decision to the appropriate authority rather than allowing it to be made pragmatically by the team under pressure. Programs that failed with good plans documents similar cases where execution pressure led to compromises that planning-stage guardrails would have prevented.
The Pattern Across All Three Cases
Each case follows the same structure. A risk existed during planning. The planning process did not include the mechanism to identify it or the framework to manage it. The risk materialized during execution, where the cost of response was higher, the options were more constrained, and the organizational consequences were more visible. The Risk Landscape does not eliminate risk. It identifies it, structures it, and creates the decision framework for managing it. The programs in these cases did not fail because they had risk. They failed because they carried risk they had not examined. Fourteen stakeholders and zero visibility connects to a broader pattern. The question is whether your program will examine its risks during planning: or whether your team will carry them unexamined into execution, where they become the surprises that derail otherwise sound plans.
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
Ready to close specific gaps in your Risk Landscape? These articles show you how: