Drawing the Line

Kurosawa Digital, meeting room B. 7:40 PM. The office is nearly empty. Ren has printed his draft scope statement; Saki has already covered it in red pen. Director Kudo's assistant has just forwarded yet another feature request via email.

Ren (蓮) "Okay, I wrote up what's in and what's out. It's all here — one page, nice and clean."

Saki (咲希) "Your scope statement (a detailed description of the project scope including deliverables and boundaries) is missing exclusions, acceptance criteria, and constraints. That's not a scope statement — it's a wish list."

→ A scope statement formally documents what the project will and won't deliver. Without explicit boundaries, any request can be argued as "in scope."

Ren (蓮) "Fine, fine. But before you redline everything — can we at least agree on the big pieces? Like, the XR demo module, the content pipeline, the analytics dashboard. Those are the work packages (the lowest-level tasks we can actually assign and track)."

→ Work packages are the smallest units in a WBS — concrete enough to be estimated, assigned, and monitored.

Saki (咲希) "Those aren't work packages yet. They're categories. We need a WBS (Work Breakdown Structure — a hierarchical decomposition of total project work) to break each one down into manageable units."

→ The WBS organizes all project work into a tree structure. It ensures nothing is missed and nothing is duplicated.

Ren (蓮) "So you want me to turn one page into a tree diagram. Tonight."

Saki (咲希) "I want you to do it properly. Once the scope statement and WBS are approved together, they become the scope baseline (the approved version of the scope statement and WBS) — the reference point for every future decision."

→ The scope baseline locks in what was agreed. Any change after this point must go through formal evaluation.

Ren (蓮) "Wait — that email from Kudo's assistant. Another feature? We haven't even baselined yet and scope is already creeping."