delivery-risk-review

Overview

Based on "The Phoenix Project" (Kim, Behr & Spafford) and "The Art of Project Management" (Scott Berkun). The core insight from Phoenix Project: most delivery failures are not surprise events - they are predictable patterns (unplanned work, single points of failure, technical debt accumulation) that were visible before the crisis but ignored. A risk review forces you to name these patterns before they explode. Berkun adds: the highest-risk part of any project is not the work - it is the assumptions baked into the plan.

Workflow

Step 1: Gather program context

Ask the user for:

• Program/release name and target date
• Team size and structure (how many teams, any new team members?)
• Key dependencies (external vendors, other teams, regulatory approvals)
• Known hotspots (legacy systems, areas of high technical debt, frequently changed code)

Step 2: Run the risk identification sweep

Work through five risk categories (drawn from Phoenix Project patterns and Berkun's scoping risk model):