Define Project Scope during the Initiation Phase

Project context and project scope are very closely related. To define project context, you need to ask questions that show you where the system fits in terms of the larger picture. To define a project's scope, you need to ask how much of this system’s potential you will attempt to build.

Have you ever watched children test their boundaries?
They keep pushing outward until someone or something makes it clear that they should not go any further.
Setting scope requires the same process of pushing. Keep asking questions that take you further away from the core problem until you reach agreement that you have gone too far and need to pull back. Then write down why you chose that boundary so that your decision can be reviewed and used as input to other project phases and projects. A well-defined and communicated scope statement is one of the primary methods of managing a client's often-changing expectations of what they will ultimately receive from a project. This is developed during the proposal phase of the project and is included within the more comprehensive scope of work document. There are really two types of scope statements, each serving a different purpose in clarifying scope and expectations of a project and its deliverables.

1. The first is a product or deliverable scope statement;
2. the second is a project scope statement.

The deliverable and project scope statements should be developed in conjunction with the site-survey process and verified during the subsequent field verification audit process. Both of these are opportune times to visually communicate to clients what will and what not will be delivered by the integrator, as well as and who will and who will not be responsible for the implementation effort.

Most software developers are used to asking project clients and users questions like

Do you want the quick and dirty version, or all the bells and whistles?

Typically, the answer is somewhere in between, but where is the boundary? This is what you need to define.
You establish the scope of the project by asking boundary-defining questions of the project clients and users:

1. Are there other related projects planned or underway? Where do the different projects intersect?
2. Are later phases planned? How much do we attempt in each phase?
3. How much of the functionality will remain manual? Where is the boundary between manual and automated processes?
4. What aspects of the functionality are more hardware than software dependent?
5. Should we include (specific feature or requirement here)?

The last question is perhaps the most important. This is where you ask project clients and users problem-specific questions until they tell you that you have gone beyond the scope of their needs for this project. For example, for the course project you might ask if you 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 our regular discounts?

The users might tell you that they only worry about the standard seating configuration and regular promotions. In this case, custom seating arrangements and custom promotions would be out of the current scope.
Saying that something is beyond the current project scope does not make it unimportant. You should document these items because they will likely become requirements for another project phase, or even another project.

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