The Phoenix Project – Scenario Summaries and Lessons (Part II)

Scenario 8 – Improving Bottleneck Utilization

Roles: Brent – senior operations engineer; Bill – IT Operations Vice President.

Event: 60% of changes miss deadlines because required resources are unavailable, with Brent being a critical bottleneck.

Action: Identify changes that need Brent, route them through a tier‑3 resource pool, prioritize those requiring Brent, and hand them to him accordingly.

Scenario 9 – Phoenix Deployment Failure

Roles: Brent – senior operations engineer; Bill – IT Operations Vice President.

Event: During deployment the team faces multiple problems: inability to deploy to QA, constantly changing code versions, unclear configuration parameters, slow database migration causing POS outage, over‑charged or lost orders, board considering outsourcing IT, and a change board that makes all changes invisible, resulting in 100% change failure.

Learning:

Four types of work exist: business projects, IT operations projects, changes, and unplanned work (fire‑fighting).

Identify constraints, exploit them, and use them to control flow and set the work rhythm.

Action: Assign Brent to development meetings to resolve technical debt in stability, security, scalability, maintainability, operability, and continuity.

Scenario 10 – Escalating Conflict

Roles: Patty – change‑process lead; Bill – IT Operations Vice President; Steve – CEO.

Event: The invoicing system fails for three days, preventing invoice issuance and payment collection, causing an estimated $50 million loss.

Action:

Patty presents a 72‑hour change timeline.

The problem scope is narrowed methodically.

The CEO orders all‑hands involvement; Bill resigns; the CEO’s directive creates additional failures.

The CEO apologizes, freezes all deployments except the Phoenix project for two weeks.

Project progress accelerates noticeably.

Scenario 11 – First Work Method

Roles: Eric – future board member and major investor; Bill – IT Operations Vice President.

Event: After the project freeze, how should the team thaw it without chaos? Eric tours the MRP‑8 shop with Bill.

Learning:

Operations resemble a factory with work centers containing machines (tools), people, methods (standard processes), and metrics.

Too many centers depend on Brent, who can only be in one place at a time.

Standardize Brent’s work into documentation so others can execute it, reducing dependency.

Release projects that do not need Brent first.

Prepare a resource list (demand types, required work centers, processes) plus work orders to understand capacity and decide on new work acceptance.

Manage hand‑offs: waiting time = resource usage time / idle time.

Implement continuous “plan‑do‑check‑act” cycles.

Action:

Document the most common service requests, define steps, assign responsible personnel, and estimate execution time.

Create a Kanban board for standard service requests with columns: To‑Do, In‑Progress, Done.

Color‑code changes (purple for top‑5 business projects, yellow for other business changes, green for internal IT improvements, pink for blocked changes).

Classify projects and flag those that do not require Brent.

Scenario 12 – First Work Method (continued)

Roles: Brent – senior operations engineer; Bill – IT Operations Vice President; Collston – PMO.

Event: Collston reports Brent’s QA environment preparation is delayed.

Reason: QA setup is a mini‑project with over twenty steps involving at least six busy teams, causing the delay.

Learning: Over‑busy personnel increase waiting time, raise WIP, and generate waste.

Action: Gather the 20 most common tasks, standardize them, build a Kanban, and assign a new hybrid role (project manager + auditor) to ensure rapid hand‑offs across work centers.

Scenario 13 – Systems Thinking

Roles: Bill – IT Operations Vice President; Dick – CFO; Maggie – Senior Retail Project Director; Ron – Sales Vice President.

Event: Discussions with CFO and sales leaders reveal unclear company goals, poor sales forecasting, opaque inventory, difficult CRM, frequent MRP and phone system failures, and a need for faster product time‑to‑market.

Learning:

Improve inventory visibility and understand customer demand to boost forecast accuracy and sales.

The Phoenix Project cannot solve these issues alone.

Integrate IT improvements into business performance metrics.

Action:

Broaden discussions with business‑process owners to define IT‑induced business risks and embed them in performance indicators.

Launch the “Unicorn” project to deliver urgently needed features.

Scenario 14 – The God Returns

Roles: Eric – future board member and major investor; Bill – IT Operations Vice President.

Event: Eric demands the operations team support development by delivering ten deployments per day, ensuring each development stage has releasable code and a deployable environment.

Learning:

Establish a cadence that matches user‑demand cycles by building a deployment pipeline that automates the entire value stream—from code check‑in to production—including environment creation.

Automate Brent’s knowledge so he no longer remains a single point of bottleneck.

Action:

Document end‑to‑end steps from development to operations, identifying errors at each stage.

Define QA flow: automated tests → matching QA environment → code deployment → test execution → QA simulation → load testing → hand‑off to operations.

Define operations flow: retrieve code package → provision new server → OS install/config → database & apps → firewall → load balancer → testing.

Estimate time for each step, identify waiting points (WIP), and visualize the value stream.

Build a generic build process that can generate development, QA, and production environments automatically.

Include infrastructure‑as‑code in version control so each sprint delivers both deployable code and reproducible environments.

Scenario 15 – Finale

Roles: Bill – IT Operations Vice President.

Event: The Unicorn project fully satisfies business needs; the business runs a highly successful market promotion, scaling on cloud computing during peak traffic and using feature flags to safely disable the promotion while preserving existing transactions.

Learning: IT must be embedded in the business; every competent COO emerges from an IT background, and a COO lacking IT fluency is merely a superficial figurehead.

Action: (Implicit) Continue integrating IT capabilities with business strategy and maintain cloud‑enabled, feature‑flag‑driven delivery pipelines.