Creating the Scope Statement - Project Management

scope statement

Documents the project goals and deliverables and serves as a baseline for future project decisions.

Everything we've talked about in this chapter so far, including goals and objectives, deliverables, requirements, constraints, and assumptions, goes into the scope statement. The purpose of the scope statement is to document these items, particularly the goals, deliverables, and requirements, to use as a baseline for the project. As you proceed through the project life-cycle phases, you'll be faced with decisions and changes that you'll want to monitor so that they conform to the original scope of the project. In this way, the scope statement is your map, or baseline, that you use to determine where you're going. If questions come up or changes are proposed, the scope statement is the first place you're going to check to make certain that what's requested is in keeping with the original request.

Creation of the scope statement is one of your most important duties as a project manager. Accurately quantifying the deliverables and detailing the requirements of the project and then getting agreement and sign-off on these deliverables helps assure project success.

Note:Creating the scope statement and project schedule are two of the most important duties a project manager performs.

The scope statement establishes a common understanding of the project's purpose among your team members and stakeholders. It contains the criteria you and the stakeholders will use at the end of the project to determine whether the project was completed successfully. The scope statement will assist you later in determining project cost estimates, resource estimates, activity definition, and project schedules.

Contents of the Scope Statement

You'll use the project charter and the product description to help you write the scope statement document. It's interesting that this is called a scope statement when in fact several elements actually make up the scope statement. It isn't a single statement but several pieces of information contained in one document. If you've followed this chapter in order, most of the work for your scope statement is already done. You understand the product of the project (from the project charter), you know the goals and deliverables, and you have the assumptions and constraints documented. Now it's a matter of putting it all together in one document.

The components of a well-documented scope statement include the following:

  • Project overview, including a description of the product of the project
  • Goals of the project (also known as the project completion criteria— did the project produce what we set out to produce?)
  • Comprehensive list of project deliverables
  • Comprehensive list of project requirements
  • List of exclusions from scope (phase two deliverables mentioned here)
  • High level time and cost estimates
  • Roles and responsibilities
  • Assumptions
  • Constraints

At this point, if you have high level information regarding time and cost estimates, include it in the scope statement with a note explaining the estimates are not final. These will be refined later when we more clearly define the work of the project. The list of exclusions from scope and roles and responsibilities needs a little more explanation.

List of Exclusions

Exclusions are the deliverables or requirements the team identified as not essential to completing this portion of the project. Exclusions from scope for the Logan Street Move project might include setting up the executive management team's office decoration and furnishings, reorganizing the IT department as a centralized service unit, etc. It's important to note what's not included in the project so that there's no misunderstanding later on when those particular deliverables don't show up or don't get done.

Roles and Responsibilities

The roles and responsibilities section in the scope statement is much more detailed than what you defined in the project charter. Here you'll want to identify who is responsible for what. You'll document who has signing authority, who should review, who should create, etc. A sample portion of a responsibility chart is shown in Table below.

Table Roles and responsibilities chart

Scope Statement Template

The following graphic pulls everything together. You can use or modify this template for your future project scope statements. It contains all the elements we've talked about so far plus an area for signatures.

statement of work (SOW)

Contains the details of items purchased on contract and includes the project objectives, a description of the work of the project, and concise specifications of the product or services required.

The scope statement also gets filed in your project notebook and should be published on the project intranet site if you have one.

When your project work is done on contract, the scope statement can serve as the statement of work (SOW). The statement of work is part of the contract. The SOW contains the same details as the scope statement and is used to describe the work of the project in clear, concise terms. You'll specify the product or service required here (the goals of the project) and the deliverables and requirements. I would consider adding a list of key stakeholders, an organization chart, time frames or deadlines, and an initial project schedule to this template if you're using it as a SOW.

The contractor will use the SOW to determine whether they're able to produce the product or service of the project, so it should be as detailed and clear as possible. Either the buyer or the seller can prepare the SOW, but both parties must review and approve it.

Obtaining Sign-Off

Does there seem to be a recurring theme throughout the project documents so far? Yes, you're right, there is—describe the nature of the project, the goals, what we hope to accomplish, and obtain sign-off.

The scope statement, like the project charter, should be signed off. This assures that stakeholders, key management team members, and the project sponsor are all in agreement on the deliverables and requirements of the project. I've witnessed many projects (none of them mine, of course) where the project manager failed to obtain sign-off on the scope statement. And, you guessed it, as the project progressed, memories became very fuzzy and stakeholders thought for sure that requirement X was part of the original plan, while the project manager swore up and down it was part of phase two. If you cannot resolve this situation and end up having to include the new requirement in this project, it usually means that you're going to miss the original planned deadline or run over budget or both. Don't let that happen to you. Document the deliverables and requirements. When a stakeholder comes to you and tries the very famous "I thought that was included," line (most of them could win an Oscar for their performance delivering this line to you), you can politely point them back to the scope statement and remind them that, in fact, that requirement is not part of this project.

The next line you'll likely hear is something like this, "Well, requirement X has to be included. It's essential to the success of the project." One of two things are happening here—okay, maybe three. First, the project manager didn't do a thorough enough job gathering requirements and the stakeholders failed to point out the missing requirements when they reviewed and signed the document. Second, the stakeholder is purposely being a troublemaker and withheld the information during requirements gathering…just because. Third, the stakeholder really never thought about this particular requirement until now. This means that you now have a scope change on your hands, and that brings us right to the next section—the scope management plan.

Creating the Scope Management Plan

scope management plan

Describes and documents how changes to project scope will be managed.

The scope management plan describes what process requestors must go through to request changes and how the changes will be incorporated into the project. The scope management plan also tries to determine the probability of scope changes, their frequency, and their impact. This process will get easier as your experience in project management grows. You'll begin to know what types of changes may occur because of the experience you gained working on projects where change occurred. Don't forget to file a copy of the scope management plan in your project notebook.

As you progress through the project, changes to project assumptions, scope, schedules, and so on make it necessary to repeat some project processes, particularly the planning processes. That's not a bad thing; it's part of applying good project management techniques to your project. One thing that will most certainly occur on your project is change. How you manage and communicate those changes will determine project success. We have one more document to cover in this chapter and that's the communications plan. Let's take a look at what that entails.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Project Management Topics