Section 1.3. Defining Project Scope and Objectives

1.3. Defining Project Scope and Objectives

Project scope is defined as the specific endpoints or boundaries of the project as well as the responsibilities of the project manager and team members.^[5] A clearly defined project scope ensures all stakeholders (individuals and organizations that are involved in or that might be affected by project activitiesproject team, application architect, testing, customer or sponsor, contracts, finance, procurement, contracts and legal) share a common view of what is included as the objectives of the project.

^[5] Radical Project Management, Rob Thomsett, 2002, Prentice Hall

Clear project objectives/requirements lead to a better understanding of the scope of the project. During the analysis step in the porting process, customer objectives and requirements are gathered, and these objectives transform themselves into work breakdown structures and eventually project deliverables. Project objectives and requirements provide a starting point for defining the scope of the project. After all project objectives have been laid out, the project scope becomes more defined.

One way to define the scope of a project is to list objectives that will and will not be included in the project. A requirements list from the customer is a good start. After the requirements have been gathered, the project manager and the technical leader review the list in detail. If there are questions about the requirements list, they should appear in the "not to be included" list of objectives, at least initially. The list is then reviewed by the customer, who may make corrections to the list. The list is revised until all parties agree that it presents the true objectives of the project.

Again, it should be sufficiently detailed so that it lists requirements that will and will not be included in the project. Yes, it is really that important to include details that are beyond the scope of the project. Objectives that do not provide enough definition to the scope of the project may turn out to be a point of contention as the project draws closer to its release date. An example of this might be listing how pieces of the porting work will be delivered to the porting teamwill it be in phases, or will it be in a single delivery? Will each delivery be considered a phase, or will there be smaller pieces of work within a phase? How many phases will make up the entire project? The list not only defines the project itself, it also sets the expectations for all stakeholders in the project.

Here are the basic rules to follow when creating the project objectives list:

1. Define project scopes in as much detail as possible.

2. Confirm that all stakeholders agree to project scopes.

3. List unresolved items on the "not-included/not-in-scope" list until they are resolved.

Table 1-1 shows an example of a simple "in-scope" and "not-in-scope" table for a sample porting project.

Table 1-1. In-Scope and Not-in-Scope Objectives

Project: Customer X Application Port to Linux
In Scope	Not in Scope
Port Directory, Mail, and Order Entry modules to Linux to be divided up in three phases. Each module will be one phase.	System tests of in-scope modules are not included in the porting project. Customer will be responsible for systems test. Packaging of application is not in scope.
Functional verification tests on these modules will be conducted by porting team. Definition of functional verification tests and acceptance criteria will be defined in another section.	Fixing bugs found to be present in the original source code are not in scope. External customer documentation of ported modules is not in scope. Customer to produce external customer documentations.
Provide debugging assistance to customer developers during system verification tests.

Part of defining the objectives is listing the acceptance or success criteria. A consensus regarding the porting project success criteria must be reached by all stakeholders. Project success may mean passing a percentage of system tests on the Linux platform or passing a level of performance criteria set out by the systems performance groupthat is, if the project objectives are to run a specific set of tests or performance analysis, respectively. Regardless of how the project success is defined, all stakeholders must understand and agree on the criteria before the porting effort starts, if possible. Any changes to the criteria during the course of the porting cycle must be communicated to all stakeholders and approved before replacing the existing criteria.