According to the Project Management Body of Knowledge, Project Scope Management is the knowledge area concerned with managing how the scope will be defined, verified, and controlled. Scope is the summation of work required to produce the end product, service, or result.
Scope Management Plan
The PMBOK dictates that a scope management plan be adopted as part of the overall project management plan. It can be a standalone document or a section within the overall plan.
The four primary parts of a scope management plan that are produced during Scope Management are:
- Requirements
- Scope Statement
- Work Breakdown Structure
- WBS Dictionary
Requirements
In this step, the requirements that the project must meet are assembled and documented. The project team and stakeholders need to have a list of the requirements, from all stakeholders, that the project must meet.
It tends to be highly specific to each industry. In the software development industry for example, requirements are a major part of the process because there are so many of them and they change constantly. Tracking them is so laborious that the use of a Requirements Traceability Matrix is recommended. However, in the engineering industry the requirements usually consist of meeting the design/construction standards of a few different organizations. A simple list of the requirements is sufficient, just to make sure the project team is familiar with them.
Scope Statement
This written statement defines the boundaries of the project. It contains the following items:
- Description of the deliverables
- End result or product
- Justification for the project
- Should attempt to answer seven questions: Who? What? When? Where? Why? How? and How Many?
As you can see, it should be more than a broad outline of the project. It should contain enough information to assist people in the interpretation of future scope changes. It should also ensure that all stakeholders are familiar with the scope.
There is no standard format, and long paragraphs and point form are often used together in the same scope statement. It can also be formal or informal, the choice is up to the project manager.
Work Breakdown Structure
The Work Breakdown Structure (WBS) is the list of tasks which compose the project. It seems simple, but it’s the foundation upon which most project management tools are based, thus it is critically important if the project is to be adequately planned and controlled. In fact, it is so important that the Project Management Institute has published a separate manual as part of the standard, called the Practice Standard for Work Breakdown Structures.
It might be important, but it’s also very simple. It is the breakdown of the project scope into smaller, more manageable pieces. For example,
- Build a house
- Excavation
- Foundation
- Concrete forms
- Concrete pouring
- Framing
- Electrical
- Plumbing
- Drywall
- Carpet
- Roofing
Although I have omitted a few things for brevity that are part of a complete house building project (don’t do that in real projects!), the point is that this is a simple, effective WBS that meets the standard. More sophisticated WBS’s include information like cost account codes for tracking, responsible organization, and others. Technically, budget and schedule are part of separate PMBOK knowledge areas but I see them put in WBS tables all the time and I don’t see a problem with that either.
A common issue is deciding when to stop separating tasks – how much decomposition is enough? The answer is that you want to decompose the scope into tasks that are:
- Easy to estimate
- Have only one major responsible party.
In the above example, pouring the concrete is probably a major sub-component of “foundation.” It has its own cost, and a different responsible party (the concrete supplier), thus it is a good candidate for further decomposition.
WBS Dictionary
The WBS is usually displayed in graphical form. As such, there is limited data that can be displayed for each item. The so called “WBS dictionary” expands on each item.
- Account code
- Responsible organization
- Quality requirements (i.e. ASTM standards, etc.)
- Technical references
- Acceptance criteria
- Contracts and agreements
- Milestone dates
- Cost estimates
As is the case with the WBS, the last two items are technically part of other knowledge areas but displaying them directly in a WBS is helpful and a widely adopted practice.
Terms of Reference
The official project scope statement is produced by the project manager and approved by the project sponsor. Scope statements that predate the project, or are otherwise produced outside the project, are not official project scope statements.
Often consultants and contractors are required to bid on a document which describes the scope of the project. This statement is often called a “Terms of Reference” or a “statement of work.” It is important not to confuse this with a scope statement. In fact, they can and often do contain major oversights and irregularities from the scope as intended by the owner organization.
Scope Changes
As a general rule, unplanned changes to project scope should be minimized. That being said, it is a frequent occurrence that a scope change makes sense. For example, the addition of certain tasks now can save money later.
In some industries a scope change is used as an opportunity to make more profit. Even for reputable consultants and contractors, a project is underbid knowing that the terms of reference are poor and lucrative scope changes are inevitable. This usually comes from poor planning or loopholes in agreements.
The further into a project, the greater the size of the scope changes will be. The size and cost of rework will be greater and the many changes to work already completed will require an incrementally greater effort.
Project managers should learn to develop strong business cases for scope changes. Stakeholders will demand the appropriate analysis before they agree to it. The following tools will assist in building a business case for scope changes:
- Net Present Value analysis, to demonstrate long term value (life cycle vs. one time cost).
- Value engineering, to investigate the underlying drivers of design features, so the design can be enhanced.