Project Scope Management
Project Goals
Provide a high-level description of the project scope. Identify why the project was initiated and what opportunities it is supposed to seize or what problems it is intended to solve. Note that the original project goals were outlined in the Project Charter, so you should revisit the original document to ensure consistency.
Project Feasibility
Comment on project feasibility. Mention which model was used to assess the project's feasibility (e.g. NPV, IRR, payback, weighted-scoring model, strategic importance, strategic risk management, etc.) Keep in mind that the first feasibility estimate was done for the Project Charter or even for the project's Business Case, so you will probably have to revisit the original calculations and assess whether or not the inputs into the formula (project cost estimates, increase in revenue and/or decrease in costs, discount rates) have changed.
Another important factor to remember is that the measures of feasibility mentioned in the Project Plan template should be synchronized with the factors used by the senior executives of the organization to assess the value of the ventures at the portfolio process checkpoints.
Scope Inclusions and Exclusions
Identify the key features that will be included in the scope of the project. At the same time, provide a list of high-level scope items that should be excluded from the scope of the project. For example, for the "Scope Inclusions" section the document may state:
- Feature 1: Three-bedroom, two-bathroom Victorian style family home
- Feature 2: Separate two-car garage
- Feature 3: Swimming pool
- Feature 4: (etc.)
And for the "Scope Exclusions" part:
- Fence around the property
- Property landscaping
- House furnishings
- Household appliances
These sections allow the project manager to establish the scope boundaries, in particular any high-level items that will be specifically excluded from the list of deliverables to avoid possible arguments in the future.
Scope Definition Documentation
There are several possibilities available for this section of the document. Generally, the content here is high-level, but if the project is very small and does not require any separate detailed scope documentation — a fairly rare situation — this section can be used for that detailed description.
However, if the project is of medium or large size, separate scope documentation is necessary to cover all the details, and this should definitely exist in a form of a separate standalone document. These documents tend to have a variety of names and titles as one moves from industry to industry, from company to company and even from one department of the same organization to another. They are called "System Requirements Specifications", "Software Requirements Specifications", "Detailed Design" in software and IT industries; "Requirements Specs", "Statement of Work", "Bill Of Materials" and blueprints in the engineering field and several other fields.
The point of this paper is not to dwell on specific document names but rather to highlight the importance of the detailed scope documentation in general and provide a reference to it in the project plan in particular.
Thus, it is very important to provide a link or a location of the Scope Definition documents in this section of the project plan.
|
Overview and Recipient Stakeholders
