The Preliminary Scope Statement is one of the first project artifacts you will want to develop. Why you ask? Because it is where you start to shape the scope of the project. What is the project about — what high level objectives? What are the general business needs trying to be addressed? Generally, how much risk, cost, time and resources do we think this project will consume? What benefits do we expect to gain from this work?
You might not know all of these things at the point of writing the Preliminary Scope Statement, but consider it your first baseline, and expect that you might need to iterate through a few versions. It is not intended to be perfect. And if you go in with the expectation that it should be perfect, then also go in with the expectation to be disappointed. It’s too early in the project to be confident of the entire scope of the project. Otherwise, you could just jump straight into developing the requirements, defining the design and getting started. Avoid jumping in. Take some time to shape the scope of the project, and socialize it with stakeholders before spending more money and effort.
A Preliminary Project Scope Statement occurs during the initiation phase of a project. 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.
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.
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.com/risk-management-and-issue-management-process-primer/)
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.
10.Project Milestones
Identify the project milestones.
| Milestone Date | Milestone Name | Milestone Description |
| [Jan 1] | System Requirements Complete | System requirements version 1.0 are approved and baselined so that the project can begin design and development. |
| [June 1] | Development Complete | Software development is complete and ready for integration testing |
| [Dec 1] | 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.
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.
