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. 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.
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:
Table 1-1 shows an example of a simple "in-scope" and "not-in-scope" table for a sample porting project.
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.