Creating a Project Scope Statement
This step involves creating a detailed description of the project and it's deliverables using the scope plan, project charter and the requirements documentation. It may need to be done more than once because it may not be possible to fully define the scope of a complex project in one pass. As high-level requirements are refined into more detailed requirements and as these are translated into deliverables this can bring additional risks, assumptions and constraints to light, which can in turn affect the scope of the project.
 |
The scope plan, the project charter and the requirements documentation produced in the previous step are all used to produce the project scope statement, which documents the project deliverables and the activities required to create them. Based on this statement, the project team can undertake more detailed planning.
It also serves as a benchmark against which requests for change or additional work can be considered. Specifically it will answer the question whether these requests within the projects original scope or outside of it. The project scope statement includes:
 |
Product Scope Description
This details the features and functions of the deliverables your project will produce. It answers the question of what is being produced rather than why or how.
Product Acceptance Criteria
These are the standards required to satisfy the customer's quality expectations and gain acceptance of the final product. This can be summarized as the process and criteria for accepting completed products, services, or results. These criteria include things like: major function, capacity, accuracy, availability, running costs and repair times.
Project Deliverables
These could be could be any of the building blocks of a project including project documents, software of physical objects.
Project Exclusions
These represent things that outside of the project boundaries.
Project Constraints
There are three types of project constraints:
• Technological constraints relate to the sequence in which individual project activities must be completed.
• Resource constraints relate to the lack of necessary resources that may force parallel activities to be performed in sequence.
• Physical constraints may be caused by contractual or environmental conditions.
The reason for identifying them is to highlight possible delays to the completion of the project.
Project Assumptions
Assumptions presume that what you're planning or relying on is true, real, or certain. For example, your project might require someone with specific technical skills and your assumption is that this person will be available when needed.
As the project stakeholders provide more information, which can then be analyzed a better understanding of the project needs will emerge which in turn allows for the definition and expansion of the preliminary project scope statement.
Once the scope boundaries are set for the deliverables, what is and is not included with the product and project scope can be determined. The final output produces the project scope statement, which is a full and detailed document able to describe all of the deliverables, the work required to achieve them, and product acceptance criteria.
The project management team are responsible for the refinement of the preliminary scope statement, which is achieved by canvassing the stakeholders and then translating their expectations and objectives into specific deliverables. This step should also determine the priorities assigned to the project requirements which can then can be used to feed in to the decision-making process where trade-offs need to be made.
Product analysis may be required to determine what problems exist with a previous product and then to decide on the requirements how to improve it. The final stage of product analysis is to specify the work necessary to achieve the improved requirements.
 |
The project scope statement must ensure that all stakeholders have a common understanding of the project scope and its objectives. The link between individual requirements within the project charter and project scope statement should be maintained to show the justification of every requirement included in it. The project charter is the key document in which the entire project requirements are traced back to because it states the sponsor's needs.
The project charter provides the high-level project description and product characteristics. It also contains project approval requirements. The project charter is described above. If a project charter is not used in the performing organization, then comparable information needs to be acquired or developed, and used as a basis for the detailed project scope statement.
Requirements documentation describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more is known. Before being baselined, requirements must be unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders.
 |
The format of a requirements document may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing executive summary, detailed descriptions, and attachments.
Expert judgment is used to analyze the information needed to develop the project scope statement. This is available from many sources, including:
1. Other units within the organization
2. Consultants
3. Stakeholders, including customers or sponsors
4. Professional and technical associations
5. Industry groups
6. Subject matter experts
 |
For projects that have a product as a deliverable, as opposed to a service or result, product analysis can be an effective tool. Each application area has one or more generally accepted methods for translating high-level product descriptions into tangible deliverables. Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis.
Identifying alternatives is a technique used to generate different approaches to execute and perform the work of the project. A variety of general management techniques can be used such as brainstorming, lateral thinking, pair wise comparisons, etc.
Requirements workshops are focused sessions that bring key cross-functional stakeholders together to define product requirements. Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences.
Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. Another benefit of this technique is that issues can be discovered and resolved more quickly than in individual sessions.
In summary, defining the scope will create the scope statement which is a detailed description of the project outcomes, including the major deliverables, budget constraints, key schedule milestones, project assumptions and constraints, and known risks.
You may also be interested in:
Project Scope Management | Scope Creep and Project Change Control | Planning How to Manage the Project Scope | Documenting the Project Requirements | Creating a Project Scope Statement | Creating the Work Breakdown Structure | Validating and Controlling Project Scope.
|
|
