Unit 04 · Phase 1

The Whiteboard War

Defining what's in and what's out

Pulse Works studio, main meeting room. The whiteboard is covered in sticky notes and hastily drawn boxes. Ren stands on one side with a marker; Saki stands on the other with a printed copy of the project charter. Tetsu's face fills a laptop screen propped on the table — his first time joining from a remote site.

Ren (蓮) "Look, the charter says 'spatial mapping and gesture recognition.' That's broad enough to include freeform interaction design. I want to leave room for the team to explore."

→ Ren is arguing for flexible scope boundaries — a common instinct for creative teams, but risky without a formal document anchoring what "in scope" means.

Saki (咲希) "The charter authorizes the project. It does not define the boundaries. That's what a scope statement (a detailed description of the project's boundaries and deliverables) does. Without one, every stakeholder will interpret the charter differently — as Director Kudo already demonstrated."

→ Saki distinguishes between the project charter (which authorizes the project and names high-level objectives) and the scope statement (which precisely defines what is and isn't included). The charter is a starting point, not a specification.

Ren (蓮) "Okay, but if we lock everything down now, we lose the ability to innovate. Half our best features came from happy accidents."

Tetsu (哲) "Define 'happy accident.' Were those features planned work, or were they things someone built instead of what was assigned?"

→ Tetsu's question cuts to a key distinction: innovation within planned boundaries versus uncontrolled scope expansion disguised as creativity.

Ren (蓮) "…Fair point. But I still think a business case (the justification for undertaking the project, including expected benefits and costs) should leave room for discovery. The market could shift in six months."

Saki (咲希) "The business case justifies why we do the project. The charter authorizes that we do it. The scope statement defines what we do. These are three different documents with three different purposes. You're conflating them."

→ Saki identifies the document hierarchy: business case (justification) → charter (authorization) → scope statement (boundaries). Each builds on the one before it.

Tetsu (哲) "Can I suggest something? Draw a line on that whiteboard. Left side: what we're definitely building. Right side: what we're definitely not. Then argue about the middle."

Ren (蓮) "Fine." He draws a thick vertical line. "Saki, you take the 'not building' side. I'll take 'building.' We meet in the middle."

Saki (咲希) "Naturally, you want the creative side." A pause. "But yes. Let's do this properly."

Tetsu (哲) "For the record, I'll need the 'definitely building' list before I can estimate anything. My team can't plan around 'room for discovery.'"

→ Tetsu highlights a practical consequence of undefined scope: downstream teams (development, testing, deployment) cannot estimate or plan without clear boundaries.

Ren (蓮) "Alright, alright. Let's write it down. In scope, out of scope, and the stuff we'll decide at the next phase gate. Happy?"

Saki (咲希) "I will be when it's signed. A scope statement isn't real until the sponsor approves it."

Concept Discovery — Project Charter & Business Case

1 The Document Hierarchy. When Saki told Ren "you're conflating them," she was distinguishing three foundational PM documents. The business case answers why — it justifies the investment by comparing expected benefits to costs. The project charter answers that — it formally authorizes the project and names the project manager. The scope statement (coming in a later unit) answers what — it defines precise boundaries. Each document has a different audience and approval authority. A charter without a business case lacks justification; a charter without a scope statement lacks boundaries.
Tip Even if your organization doesn't require all three documents, ensure the three questions (why, that, what) are answered somewhere in writing before work begins.

2 Authorization vs. Specification. Ren's instinct to treat the charter as a scope document is a common mistake. The charter Hina read aloud in Unit 2 listed objectives and milestones, but its primary function was to authorize the project and assign responsibility. Tetsu's whiteboard suggestion — "draw the line, then argue about the middle" — is a practical first step toward the detailed scope definition that Saki insists on. The charter gets you started; the scope statement keeps you honest.
Phoenix Project Connection In The Phoenix Project, projects that skip formal authorization and scope definition become "zombie projects" — consuming resources without clear boundaries or success criteria.

← Scope Shock Reading the Room →