Define Project Scope during the Initiation Phase

Project context and project scope are closely related but address different questions. Context defines where the system fits — the people, systems, and organizational environment it operates within. Scope defines how much of that system's potential you will attempt to build in this project. Context establishes the boundary between your system and the world outside it. Scope establishes the boundary between what your system will do now and what it might do in the future.
Defining scope precisely is one of the most consequential activities in the project initiation phase. A scope that is too narrow produces a system that fails to meet business needs. A scope that is too broad produces a project that overruns its budget, misses its deadline, and delivers an incomplete system. The discipline of scope definition is the discipline of asking the right questions until you find the boundary that the project can actually deliver — and then documenting that boundary so clearly that it can be enforced throughout the project lifecycle.

A useful way to understand scope definition is to observe how children test boundaries. They push outward, incrementally, until someone or something signals that they have gone too far. Scope definition works the same way. You keep asking questions that take the conversation further from the core problem until stakeholders agree that you have gone beyond what this project should address. That boundary, the point where stakeholders say "not this project" — is your scope limit.
The critical discipline is to document why you chose each boundary. Scope decisions are not permanent — they are project-specific. A feature excluded from the current scope is not unimportant; it is a candidate for a future phase or a separate project. If you document it clearly, it becomes a useful input to project planning rather than a forgotten discussion.
A well-defined scope statement is one of the primary tools for managing stakeholder expectations throughout a project. Stakeholders have a natural tendency to expand their vision of what a project will deliver as development progresses. A documented, agreed-upon scope statement provides the baseline against which change requests are evaluated. Without it, scope creep — the gradual, uncontrolled expansion of project scope — is inevitable. There are two distinct types of scope statements, each serving a different purpose:

1. Product or deliverable scope statement — describes the features and functions that characterize the system or deliverable being built. It answers the question: what will this system do when it is complete?
2. Project scope statement — describes the work that must be performed to deliver the product. It answers the question: what activities, resources, and effort are required to build and deploy the system?

Both scope statements should be developed during the proposal and initiation phases and verified through stakeholder review. They serve as the formal record of what was agreed, providing legal and contractual clarity about what the project will and will not deliver, and who is responsible for each aspect of implementation.

Most development teams are comfortable asking broad questions about desired functionality — do you want the minimal viable version or the full-featured system? The answer is almost always somewhere in between. The scope definition process gives that answer precision. You establish scope by asking boundary-defining questions of project clients and users — questions that progressively move from the core system functionality outward until stakeholders tell you that you have gone too far. The five foundational boundary questions are:

1. Are there other related projects planned or underway? Where do they intersect with this project? Understanding adjacent projects prevents duplication of effort and identifies integration dependencies that belong in the project context rather than the project scope.
2. Are later phases planned? How much functionality will be attempted in each phase? Phased delivery allows scope to be defined incrementally — each phase has its own scope boundary, with later phases dependent on the decisions made in earlier ones.
3. How much of the functionality will remain manual? Where is the boundary between manual and automated processes? Not every business process should be automated in a given project phase. Identifying what remains manual prevents over-engineering and keeps scope aligned with organizational change capacity.
4. What aspects of the functionality are hardware-dependent rather than software-dependent? Hardware constraints may place certain functionality outside the software system's scope entirely, or may impose integration requirements that affect the software design.
5. Should we include [specific feature or requirement]? This is the most important question. Ask it repeatedly, with increasing specificity, until stakeholders tell you that you have exceeded the scope of their current needs.

Consider a practical example from a ticketing system project. You might ask stakeholders whether the system should include:

1. Support for all types of sporting events?
2. All types of community functions?
3. Custom seating arrangements?
4. Block sales to special groups?
5. Custom promotions on top of regular discounts?

Stakeholders might respond that for this project phase, they only require support for the standard seating configuration and regular promotions. Custom seating arrangements and custom promotions are therefore out of scope — not because they are unimportant, but because they are beyond what this project will deliver. They are documented as out-of-scope items and become candidates for a future phase.

Scope decisions directly constrain the analysis and design models that the development team produces. A use case model can only represent functionality that is within scope. A class model can only represent the domain concepts that the in-scope use cases require. A sequence diagram can only trace the interactions that the in-scope scenarios involve. This means that scope definition errors propagate forward through every subsequent modeling activity. If a feature is incorrectly included in scope, the team builds models for functionality that will not be implemented — or worse, implements functionality that was never needed. If a feature is incorrectly excluded from scope, the team discovers the gap late in the project when the cost of adding it is at its highest. The relationship between scope and the data dictionary is equally direct. The data dictionary defines the vocabulary of the problem domain — but only for the portion of the domain that is within scope. In the ticketing system example, if custom seating arrangements are out of scope, the data dictionary does not need to define "seating zone," "accessible seating block," or "premium section" for this project phase. Including those definitions would be premature and would suggest a scope boundary that does not exist. Similarly, scope boundaries determine which actors appear in the use case model. An actor who only interacts with out-of-scope functionality is not a primary actor in this project. Identifying actors prematurely — before scope is defined — produces use case models that represent a system larger than the one being built.

Traditional project management frameworks such as PMBOK treat scope management as a formal process with defined inputs, tools, and outputs. The scope management plan, work breakdown structure (WBS), and scope baseline provide the infrastructure for controlling scope throughout the project lifecycle. Change requests that affect scope are evaluated against the baseline through a formal change control process. Agile methodologies manage scope differently but address the same fundamental challenge. In Scrum, the product backlog is the living record of all desired functionality — it is deliberately unbounded. Scope for a given sprint is defined through sprint planning, where the team selects backlog items that can be completed within the sprint timebox. This approach makes scope decisions iterative and explicit at every planning cycle rather than front-loaded into a single initiation phase document. The product owner role in Scrum performs the same function as scope definition in traditional project management — deciding what is in the current sprint, what is in the backlog for a future sprint, and what will never be built. The difference is cadence: Scrum makes scope decisions every two weeks rather than once at project initiation. In both methodologies, the core discipline is identical: decide what is in scope, document why, and use that decision as the baseline for managing change. The boundary-defining questions — are there related projects, are later phases planned, where is the manual-automated boundary — are as relevant in a sprint planning meeting as they are in a traditional project charter review. For distributed teams and multi-vendor projects, scope definition becomes even more critical. When development work spans organizational boundaries, an ambiguous scope statement does not just create internal confusion — it creates contractual disputes. Each team or vendor interprets an undefined boundary in the way that is most convenient for their delivery, producing integration failures that are expensive to resolve.

A discipline that is frequently overlooked is the formal documentation of out-of-scope items. Saying that something is beyond the current project scope does not make it unimportant — it means that it is deferred. Out-of-scope items that are not documented tend to resurface as late-stage requirements, introduced by stakeholders who assumed the feature was always part of the plan. A simple out-of-scope register captures each excluded item, the reason it was excluded, and its priority as a candidate for future phases. This register serves three purposes. First, it demonstrates to stakeholders that their requests were heard and considered, even when excluded. Second, it provides input to future project planning — the out-of-scope register for phase one becomes the starting point for phase two scope definition. Third, it provides evidence in scope disputes that a particular feature was explicitly discussed and deliberately excluded, rather than forgotten or overlooked. The boundary-testing process — pushing outward until stakeholders say stop — only produces value if the boundaries that are found are recorded. Scope definition without documentation is scope discussion, not scope management.

Click the Exercise link below to select user statements that help you define the scope of the course project system.
Project Scope - Exercise