Gather Requirements

A company sells, delivers, and supports client projects. Today, this happens across disconnected spreadsheets. The Project Delivery Tracker needs to: let Sales convert a won Opportunity into a Project, let Delivery track Milestones and log time, let Support log Cases against a live Project, and give leadership a real-time view of project health — a genuinely cross-departmental system, not a single-team tool.

As a Sales rep, I want a won Opportunity to automatically create a
Project, so that Delivery has zero manual setup work.

As a Delivery lead, I want to track Milestones with due dates and
status, so that I can see which projects are at risk of slipping.

As a Support agent, I want to log a Case against a specific Project,
so that Delivery has full visibility into support burden per client.

As a leader, I want a real-time dashboard of project health across
every department, so that I can intervene before a project fails.

Each story reuses Module 41's exact "As a... I want... So that..." format — this capstone doesn't introduce a new requirements process, it applies the one already established, one final time, at genuinely larger scope.

"A real-time dashboard across every department" already implies the data model needs Project as a shared, central object that Sales, Delivery, and Support all relate to — not three separate, disconnected systems. Recognizing this now, during requirements gathering, is exactly Module 41\'s "catch problems on paper, cheaply" principle — the alternative is discovering this need for a shared central object midway through building three separate department-specific systems.