Baseball Complex Construction Project

Scope Statement

Writing a Scope Statement

An effective scope statement is necessary to guide a project to successful completion. Learn about the different sections in a scope statement, and get hints on how to minimize scope creep.

A scope statement is one of the most critical pieces of a project, and writing one can be a difficult task for a project manager – no matter what type of project management methodology is being used. But, an effectively written scope statement can help the rest of the project flow along with minimal problems. It is written after the project charter, and includes everything that the project is intended to produce.

A project charter is usually used for three different reasons:

Authorizing the project

Providing a high level overview

Identifying the main stakeholders

The charter often includes the name of the project owner as well as project sponsors. It also identifies objectives or goals, and constraints on resources or time. Finally, the charter is used as a focal point throughout the life of the project, which can be especially useful during change control meetings for minimizing scope creep. Scope creep is a phenomenon where the scope of a project gradually increases over time.

What's in a Name?

The name of the project be very clear and concise. An effective project name reads something like 'Create a Marketing Plan For Increasing Sales of Widget X in Chicago'. This is much better than 'Marketing Plan Project', which is definitely concise but by no means clear. The aim of the project name is to document the project so that everyone involved is aware of what is expected during the life of the project. A good project name also helps provide a vision of where the project is headed.

Writing the Scope Statemment

Now that you have the project charter and the name, you can start by filling in the project name, project charter, and a listing of the project owner, sponsors, and stakeholders on the scope statement.

Justifying Your Existence

Next, A project justification will need to be identified, as well as project requirements, milestones, and deliverables. Any non-goals - items that fall outside of the scope of the project - need to be identified here.

Project justification is simply identifying the reason for the project's existence. It is usually a statement or two identifying why the project is being created. It’s important to have the project justification identified because this helps to give overall direction to the project as well as emphasizing the final goal. The project justification should be clear and precise manner so that it identifies a quantifiable measure of success for the end of the project. An effective justification might read like the following:

This project is to create a successful marketing plan for the month of August 2008, in order to increase sales of Widget X by 15% in the Chicago metropolitan area. This is a good example of an effective justification because it is quantifiable and qualitative. Distinct boundaries are set as to what is the expected result of the project so there is no ambiguity.

How Much?

Finally, cost estimates need to be provided within the scope statement. This information may be readily available or it may need to be compiled from various sources, but the scope statement is where it needs to be documented all together. This can be a cumbersome task, but it is a necessary one. As the project progresses, everyone involved knows where they can look should a question arise.

Requirements, Deliverables, and Non-Goals

The next section in the scope statement should list the requirements of the project. The requirements are objectives that must be met during the project, and often they include significant milestones or goals. The objectives need to be quantifiable and identified clearly.

Any milestones or goals need to be also clearly identified, as well as any non-goals. Non-goals are items that are specifically not going to be addressed by the project, which helps to eliminate the scope creep. By clearly identifying these as non-goals, the scope cannot include them later on without going through a change management process. Ultimately, many project managers track their milestones, goals, and/or deliverables using a Work Breakdown Structure.

The deliverables for a project need to be clearly identified within a scope statement. If necessary, deliverables need to be tied to specific milestones in the project schedule. The deliverables also need to be agreed upon by the major stakeholders as well as the project owner.

Deliverables may include any training necessary for personnel at the culmination of the project. Or deliverables may be a final product to be provided to the stakeholders. No matter what makes up a project's deliverables, specific details regarding them is the golden rule. The more clearly the deliverables are identified and specified, the less chance there will be for scope creep to occur later on.

Cost estimates for the project should also be included in the scope statement. This is an essential process of project planning, so the cost estimates should be as accurate as possible. If the cost estimates are too low, the project will go over budget - sometimes significantly so.

If the cost estimates are too high, resources that are allocated to the project - whether they are money, equipment or people - are unavailable for other projects and could negatively affect them. So the more on track the cost estimates are, the more efficient and successful the project will be. This can be a difficult task for the project manager to do, but effective cost management is a critical success factor for projects.

Finalization and Acceptance

The last significant section of a scope statement is the formal acceptance signatures. Once the project manager has compiled all of the documentation into a concise and clear statement, all of the major stakeholders as well as the project owner need to sign off on it.

This is a very significant step and can be a very useful tool in mitigating scope creep as well. A meeting should be held where everyone can be provided a copy of the scope statement. At that time, any discrepancies can be cleared up or last minute changes can be made.

Once everyone signs off on the scope statement, there should be agreement between all parties and the project can begin. By having everyone sign the scope statement, there is very little chance of surprises down the road. And in the event that something does pop up, there is documentation of what was agreed upon initially so that changes can be made if necessary. If anything does change down the road and the scope does need to be increased for some reason, signatures should be obtained from everyone once more.

Exhaustively detailed specifics, clear and concise language throughout, and avoiding ambiguity are the keys to making a scope statement effective and useful. It is also very beneficial to have all of this information documented in one place - even if the process of creating it is enormous.

The task of creating a scope statement can encompass a great deal of time for any project manager, but the rewards usually include more successful projects and minimized scope creep throughout. And this can be a highly desirable benefit, as scope creep is often a significant cause of project failure. So document as much as possible, as clearly as possible, and make sure everyone involved is aware of what is expected. Through clear and concise documentation, a scope statement's usefulness shines all the way to project success.

(Stallsworth, 2014)

Stallsworth, Eric (2014). Writing a Scope Statement. Retrieved on 24 October 2015 from http://www.brighthubpm.com/templates-forms/2491-writing-a-scope-statement/

Scope Management Plan

Project Scope Management follows a five step process; Collect Requirements, Define Scope, Create WBS, Verify Scope, and Control Scope.

Collect Requirements – this first step is the process by which we define and document the requirements needed to meet all project objectives. The foundation of this process is the project charter and stakeholder register. From these, the team can identify requirements, collectively discuss details associated with meeting each requirement, conduct interviews and follow-on discussion to clarify the requirements, and document the requirements in sufficient detail to measure them once the project begins the execution phase. This documentation also serves as an input to the next step in the process which is to define scope.

Define Scope – this step is critical to project success as it requires the development of a detailed project/product description to include deliverables, assumptions, and constraints and establishes the framework within which project work must be performed.

Create WBS – this process breaks project deliverables down into progressively smaller and more manageable components which, at the lowest level, are called work packages. This hierarchical structure allows for more simplicity in scheduling, costing, monitoring, and controlling the project.

Verify Scope – this is the process by which the project team receives a formalized acceptance of all deliverables with the sponsor and/or customer.

Control Scope – this is the process of monitoring/controlling the project/product scope as well as managing any changes in the scope baseline. Changes may be necessary to the project scope but it is imperative they are controlled and integrated in order to prevent scope creep.

Scope Management Approach

It is important that the approach to managing the projects’ scope be clearly defined and documented in detail. This section of the Scope Management Plan provides a summary of the Scope Management Plan in which it addresses the following:

Who has authority and responsibility for scope management

How the scope is defined (i.e. Scope Statement, WBS, WBS Dictionary, Statement of Work, etc.)

How the scope is measured and verified (i.e. Quality Checklists, Scope Baseline, Work Performance Measurements, etc.)

The scope change process (who initiates, who authorizes, etc.)

Who is responsible for accepting the final project deliverable and approves acceptance of project scope

For this project, scope management will be the sole responsibility of the Project Manager. The scope for this project is defined by the Scope Statement, Work Breakdown Structure (WBS) and WBS Dictionary. The Project Manager, Sponsor and Stakeholders will establish and approve documentation for measuring project scope which includes deliverable quality checklists and work performance measurements. Proposed scope changes may be initiated by the Project Manager, Stakeholders or any member of the project team. All change requests will be submitted to the Project Manager who will then evaluate the requested scope change. Upon acceptance of the scope change request the Project Manager will submit the scope change request to the Change Control Board and Project Sponsor for acceptance. Upon approval of scope changes by the Change Control Board and Project Sponsor the Project Manager will update all project documents and communicate the scope change to all stakeholders. Based on feedback and input from the Project Manager and Stakeholders, the Project Sponsor is responsible for the acceptance of the final project deliverables and project scope.

Roles and Responsibilities

In order to successfully manage a projects’ scope it’s important that all roles and responsibilities for scope management are clearly defined in the Scope Management Plan. This section defines the role of the Project Manager, Project Team, Stakeholders and other key persons who are involved in managing the scope of the project. It should state who is responsible for scope management and who is responsible for accepting the deliverables of the project as defined by the projects’ scope. Any other roles in scope management should also be stated in this section.

The Project Manager, Sponsor and team will all play key roles in managing the scope of this project. As such, the project sponsor, manager, and team members must be aware of their responsibilities in order to ensure that work performed on the project is within the established scope throughout the entire duration of the project. The table below defines the roles and responsibilities for the scope management of this project.

Scope Definition

The scope definition section details the process of developing a detailed description of the project and its deliverables. This can only be completed after the requirements have been identified and defined during the requirements definition process. During the requirements definition process three documents were created; Requirements Documentation, Requirements Management Plan and a Requirements Traceability Matrix. You can refer to these documents when defining the projects’ scope.

This section of the Scope Management Plan should explain the process you followed to develop the detailed description of the project and its deliverables. If you used other documents such as the Project Charter, Preliminary Project Scope Statement or Requirements Documentation you should identify them and all other documents used. You should tie the scope definition process back to the requirements definition as the projects’ scope answers the requirements for the project.

You should also document the tools and techniques used to define the project scope such as expert judgment, product analysis, alternatives identification or facilitated workshops.

The scope for this project was defined through a comprehensive requirements collection process. First, a thorough analysis was performed on the company’s current software applications based on employee and user feedback. From this information, the project team developed the project requirements documentation, the requirements management plan, and the requirements traceability matrix for what the new software application must accomplish.

The project description and deliverables were developed based on the requirements collection process and input from subject matter experts in software design, technical support, programming and business applications. This process of expert judgment provided feedback on the most effective ways to meet the original requirements of providing a new software platform from which the company can improve its financial tracking and internal financial processes.

Project Scope Statement

The project scope statement details the project’s deliverables and the work necessary to create these deliverables. The Project Scope Statement should contain the following components:

Product Scope Description – describes what the project will accomplish

Product Acceptance Criteria – describes what requirements must be met in order for the project to be accepted as complete

Project Deliverables – detailed list of deliverables the project will result in

Project Exclusions – description of work that is not included in the project and outside of the scope

Project Constraints – lists limits on resources for time, money, manpower, or equipment (capital)

Project Assumptions – describes the list of assumptions the project team and stakeholders are working under to complete the project

The project scope statement provides a detailed description of the project, deliverables, constraints, exclusions, assumptions, and acceptance criteria. Additionally, the scope statement includes what work should not be performed in order to eliminate any implied but unnecessary work which falls outside the of the project’s scope.

This project includes the design, programming, and testing of a new software application for tracking the company’s finances. The deliverables for this project are a completed software application for finance tracking with the flexibility to modify and expand the application as necessary in the future. This project will be accepted once the new software has been successfully tested in each department and has been shown to be compatible with the company’s current information technology (IT) infrastructure. This project does not include ongoing operations and maintenance of the software. Only internal personnel and resources may be used for this project. Additionally, the project is not to exceed 180 days in duration or $450,000 in spending. Assumptions for this project are that support will be provided by the project sponsor and all department managers and that adequate internal resources are available for the successful completion of this project.

Work Breakdown Structure

The Work Breakdown Structure (WBS) and Work Breakdown Structure Dictionary are key elements to effective scope management. This section of the Scope Management Plan should discuss how the project scope is to be subdivided into smaller deliverables in the WBS and WBS Dictionary and how these smaller components are managed during the life of the project.

In order to effectively manage the work required to complete this project, it will be subdivided into individual work packages which will not exceed 40 hours of work. This will allow the Project Manager to more effectively manage the project’s scope as the project team works on the tasks necessary for project completion. The project is broken down into three phases: the design phase; the programming phase; and the testing phase. Each of these phases is then subdivided further down to work packages which will require no more than 40 hours of work and no less than 4 hours of work (see WBS structure below).

In order to more clearly define the work necessary for project completion the WBS Dictionary is used. The WBS Dictionary includes an entry for each WBS element. The WBS Dictionary includes a detailed description of work for each element and the deliverables, budget and resource needs for that element. The project team will use the WBS Dictionary as a statement of work for each WBS element.

WBS Dictionary

Level WBS Code Element Name Description of Work Deliverables Budget Resources                     

Scope Verification

Scope verification discusses how the deliverables will be verified against the original scope and how the deliverables from the project will be formally accepted. The deliverables for the project should be formally accepted and signed off on by the customer throughout the lifecycle of the project and not held back as a single deliverable at the end of the project.

As this project progresses the Project Manager will verify interim project deliverables against the original scope as defined in the scope statement, WBS and WBS Dictionary. Once the Project Manager verifies that the scope meets the requirements defined in the project plan, the Project Manager and Sponsor will meet for formal acceptance of the deliverable. During this meeting the Project Manager will present the deliverable to the Project Sponsor for formal acceptance. The Project Sponsor will accept the deliverable by signing a project deliverable acceptance document. This will ensure that project work remains within the scope of the project on a consistent basis throughout the life of the project.

Scope Control

Scope control is the process of monitoring the status of the scope of the project. This section of the Scope Management Plan also details the change process for making changes to the scope baseline.

The Project Manager and the project team will work together to control of the scope of the project. The project team will leverage the WBS Dictionary by using it as a statement of work for each WBS element. The project team will ensure that they perform only the work described in the WBS dictionary and generate the defined deliverables for each WBS element. The Project Manager will oversee the project team and the progression of the project to ensure that this scope control process if followed.

If a change to the project scope is needed the process for recommending changes to the scope of the project must be carried out. Any project team member or sponsor can request changes to the project scope. All change requests must be submitted to the Project Manager in the form of a project change request document. The Project Manager will then review the suggested change to the scope of the project. The Project Manager will then either deny the change request if it does not apply to the intent of the project or convene a change control meeting between the project team and Sponsor to review the change request further and perform an impact assessment of the change. If the change request receives initial approval by the Project Manager and Sponsor, the Project Manager will then formally submit the change request to the Change Control Board. If the Change Control Board approves the scope change the Project Sponsor will then formally accept the change by signing the project change control document. Upon acceptance of the scope change by the Change Control Board and Project Sponsor the Project Manager will update all project documents and communicate the scope change to all project team members stakeholders.

(Piscopo, 2015)