Preliminary Project Scope Statement

This Preliminary Project Scope Statement was hosted on the now defunct pmdocuments website.

A document template can be found below.

If you can't access the MS Word template, you can use this:

Preliminary Project Scope Statement

[Project Name]

Date

[Company Name]

Address

City, State Zip

Contents

1. Project Description

2. Project Purpose

3. Project Objectives

4. Project Requirements

5. Project Assumptions

6. Project Constraints

7. Project Boundaries

8. Project Risks

9. Project Deliverables

10. Project Milestones

11. Project High Level Work Breakdown Structure (WBS)

12. Rough Order of Magnitude (ROM) Estimate

13. Authorization

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.

SEE SAMPLE DIAGRAM IN THE MS WORD DOCUMENT.

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.

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.

Activity

Estimated Time

Define Requirements and Design

100-150 Resource Hours

Develop Product

200-400 Resource Hours

Test Product

100-150 Resource Hours

Deploy Product

100-150 Resource Hours

13.Authorization

If approval is required, provide the names of those business sponsors that must sign the Preliminary Project Scope Statement.

Approved by the Project Sponsor:

__________________________________________ Date:___________________

[Project Sponsor]

[Project Sponsor Title], [Project Sponsor Organization or Division]

Note: Add other signatories as needed