Project Scope Exercise Results

Your Submission

You entered:

No response was received. Please return to the exercise page and submit your analysis.

Objective Review

Objective: Identify which stakeholder statements define the project scope—meaning they clarify what is included, excluded, deferred to a later phase, or handled by an external team/system. For each statement below, the key is to classify it as:

• In Scope (must be delivered in this phase)
• Out of Scope (explicitly excluded)
• Dependency (owned by another group/system you rely on)
• Assumption/Constraint (conditions that limit design choices)
• Future Phase (valuable work intentionally deferred)

Not every statement is “scope.” Some are better used later during analysis/design (data requirements, workflow behavior, creation rules). Those are still important—but they don’t define scope boundaries.

Suggested Classifications

1. Out of Scope: “We do not keep track of what agency the agents work for...”
   Why this defines scope: It draws a crisp boundary: the system manages agents, but does not model agencies. That’s a direct scope exclusion that prevents unnecessary entities, screens, and integrations.
2. Assumption/Constraint: “We already have a database that is working really well for us.”
   Why this helps scope (indirectly): It constrains solution choices (reuse/integrate vs replace). This isn’t a feature boundary, but it does shape architecture, data migration plans, and integration scope. In many projects, “must use existing DB” is a formal constraint.
3. Assumption/Constraint: “Only the venue manager can set up promotions.”
   Why this helps scope: It implies promotions are in scope and introduces an authorization requirement. Roles/permissions are part of scope when they impact features (promotion creation, approval, auditability). The detailed implementation can vary, but the requirement itself is a scope/requirements constraint.
4. Dependency: “The legal department sets up the agent contracts in their system.”
   Why this defines scope: It explicitly places contract creation outside your project. Your system may need to reference contract status/IDs (or import contract facts), but you are not building legal’s contract-management workflow.
5. Dependency: “Mailing rates and methods are handled in the mailroom.”
   Why this defines scope: It assigns shipping logistics elsewhere. Your system may produce mailing outputs (address labels, “ready to mail” status, or handoff reports), but does not optimize postage, carriers, or mailroom operations.
6. In Scope (high-level requirement): “Tickets will include the seat location, price, applied discount, and date/time...”
   Why this defines scope: It declares what the system must issue as an output artifact (a ticket) and the minimum fields it must compute/retain. That’s a product requirement, not just a data detail. The exact class model comes later, but the requirement itself belongs in scope/requirements.
7. Future Phase: “We would like eventually to offer season tickets...”
   Why this defines scope: It explicitly defers a major feature. This helps prevent scope creep while still documenting a roadmap item.
8. In Scope (functional boundary): “Agents use the same features as customers... difference is what seats they see...”
   Why this defines scope: It establishes that agent sales are part of this system and should reuse the same purchase/hold flows, with a key variation: seat-visibility rules based on agreements. That affects scope because it drives feature parity and RBAC rules.
9. In Scope (requirements with deferred detail): “Events can be set up without entering performance dates and times.”
   Why this can define scope: It states the system must support creating an event “shell” independent of scheduling. That impacts workflows, validation rules, and data model optionality. (The exact UX is design-time, but the capability is a requirements boundary.)
10. Future Phase: “In phase 2, we plan to let agents see their commissions during each sale.”
    Why this defines scope: It assigns commission visibility to a later phase, which limits what must be delivered now. You might still capture commission-related data as a foundation, but the real-time display feature is deferred.

What to Take Away

• Scope statements draw boundaries, assign ownership, or defer work to later phases.
• Constraints (existing DB, role limitations) are part of “scope control” because they limit design choices.
• Dependencies (legal contracts, mailroom) clarify what you integrate with vs what you build.
• Future-phase statements are your anti-scope-creep shield.