A Preliminary Project Scope Statement is one of the outputs of the Project Initiation process group. The purpose of the Preliminary Project Scope Statement is to identify the high level project objectives. The objectives must be clear, actionable and measurable.
Recommended sections for the Preliminary Project Scope Statement include:
1. Project Description
Explain what the project is, and how it will be accomplished. Explain the ultimate intended outcome of the project. This should serve as a brief introduction. Provide some background about the history of how the project got to this point.
2. Project Purpose
State the purpose of the project. Tie the purpose to the organization’s strategic goals and objectives if possible. Tell the reader why this project is being started and what need it is fulfilling. Identify if there are any specific mandates, policies or laws that are driving this change.
3. Project Objectives
Provide clear, actionable and measurable objectives of the project. The objectives should be clear enough so that the project can be measured against the objectives once completed. The ultimate success of a project is whether the project achieved its stated objectives. Take time to clearly document the objectives here.
An example of an objective is:
The system/product/service will cut response times in half, thus allowing the organization to process twice as many tickets.
4. Project Requirements
Identify the high level requirements of the product or service that will be developed. Remember that this is not a detailed list of system requirements or specifications at this point. The requirements might be at a level that is sufficient for performing an alternatives analysis to identify vendors and service providers that can meet the requirements.
An example of a requirement is:
The system will provide users with the ability to create and maintain a login account and profile online.
If you have elicited enough requirements where it makes sense to group the requirements by category, then feel free to display the requirements by category. Generally, there are two types of requirements: functional and non-functional. Non-functional requirements are generally broken into groups like security, usability, quality, scalability, privacy, maintainability, etc.
5. Project Assumptions
Assumptions are conditions at the start of the project that must be considered. For example, when developing the new software system that is going to take 3 years to fully complete, an assumption could be that the project budget is approved each year for three years so that the project scope is not impacted.
6. Project Constraints
Constraints are situations or events on the ground that must be considered and accounted, for which the project has no control over. For example, a constraint can be a hard deadline or completion date. Other constraints could be resources, tools or hardware — so that if the project has no budget for additional servers, then the project must find a way to develop the new system using the hardware already in place. This could mean juggling servers to fit specific development environment needs while ensuring that the production environment stays up.
7. Project Boundaries
If the product or system boundary is known, describe it here. For example, if a system requires access to multiple external systems (e.g., a system of systems), then it might make sense to break the scope of work into multiple phases so that the scope of the first phase of development would be to only develop the core functionality. A later phase would integrate the remaining functions. In this scenario, you essentially could have two projects. Therefore, clearly defining the project boundaries helps set the scope of work that is to be accomplished.
An example of a system boundary concept is:
The online store will integrate with the shopping cart and credit card purchasing modules for the initial release. The second release will contain social media integration modules.
Don’t be afraid to use architecture diagrams here if it helps visually clarify a system boundary. The figure below is one of a multitude of types of system diagrams.
Preliminary Project Scope Statement – System Boundary Image
8. Project Risks
State the known risks. These risks are generally at a high level since not much is known about the details of the project yet. If a Benefit-Cost Analysis was performed, then risks identified during the Benefit Cost Analysis should be placed here. For example, if the project is going to span 5 years and touch multiple third-party systems, then integration and technology change would be risks to consider here. (For examples on how to write a risk statement, visit http://pmdocuments/category/risk-management/)
9. Project Deliverables
Identify the products and services that the project will deliver. The intent of this section is to list the product or system deliverables (e.g., An online shopping site), and not the project management deliverables (e.g., Requirements Management Plan)
An example of a product deliverable is:
An online store with a shopping cart and credit card purchasing capability.
Identify the project milestones.
System Requirements Complete
System requirements version 1.0 are approved and baselined so that the project can begin design and development.
Software development is complete and ready for integration testing
Deployed to Production
System passes integration and end-user acceptance testing and is deployed to production
11.Project High Level Work Breakdown Structure (WBS)
If you have decomposed the high level work that needs to be done, then provide the high level work breakdown structure (WBS) here. A high level WBS is sometimes referred to as a Rough Order of Magnitude WBS, or ROM WBS. (For more information on WBS development, visit http://www.pmdocuments.com)
12.Rough Order of Magnitude (ROM) Estimate
Provide ROM estimate information here. If the work has been decomposed and a ROM estimate calculated, then provide the information here. (For more information on ROM estimate development, visit http://www.pmdocuments.com)