What item forms the basis for planning and managing project schedules costs resources and changes?

Scope issues are the #1 reason for project failure. A scope management plan is the component of the project management plan that describes how the scope will be defined, developed, monitored, controlled and validated (Project Management Body of Knowledge, 6th Edition).

The core of the scope management plan is the project scope statement. However, the other items establish the foundation underneath the scope statement that are critical to effectively managing and controlling the project scope.

A good scope management plan will have the following sections:

1. Requirements
2. Stakeholders
3. Scope Statement
4. Work Breakdown Structure (WBS)
5. WBS Dictionary
6. Roles and Responsibilities
7. Deliverables
8. Sponsor Acceptance
9. Scope Control

Requirements

A proper scope identification process will allow for a requirements identification step. This is where you contact the stakeholders, meet with them if necessary, and identify and prioritize all of the external requirements the project must meet. It’s important not to miss anything. Most projects have a myriad of requirements originating from many stakeholders, and it’s surprisingly easy to miss one minor one that has an outsized ability to affect the project.

The Project Management Body of Knowledge (PMBOK Guide) includes the creation of a Requirements Traceability Matrix. Essentially, this is a tracking chart whereby the requirements from various stakeholders are given a sign-off at different stages throughout the project life cycle. For example, a landowner near a new road site might be informed of the project at the conception stage, again once the options under consideration have been tabled, and finally at the finished design stage. The requirements traceability matrix is a tracking tool that ensures the project team get the land owners sign off at each stage.

Scope Statement

The scope statement defines the project. It is the core of the scope management plan and the other components lay the foundation. The scope statement is a written description of the project scope, major deliverables, assumptions, and constraints (PMBOK Guide, 6th Edition). It states in writing what work will be part of the project and what will not, and its importance should not be underestimated.

You can’t define every nut and bolt at the beginning of the project, but it is almost always better to spend a little bit of extra time defining the scope. This practice almost always reaps rewards throughout the project.

Here is an example of a bad scope statement:

The following is the right way to build the scope statement which establishes stakeholder expectations and reduces risk of scope changes during the project:

To design a bridge that meets state road design standards while providing for a 1:100 year streamflood event. Environmental concerns such as fish passage and habitat will be reasonably accommodated, as well as all environmental regulations followed.

Work Breakdown Structure

It can be graphical or tabular, and can be structured in various ways:

1. Project phases
2. Project deliverables
3. Subprojects

In it’s most basic form, it’s just a list of tasks, like this:

WBS Dictionary

In PMBOK terms, a WBS Dictionary supports the Work Breakdown Structure.  It itemizes the following things for each work item:

1. Identification number/code
2. Description of work
3. Responsible organization or individual

This is the minimum amount of information. Other items might include start date, deadline, budget, client, milestone, or other resources required in carrying out the work item.

Roles and Responsibilities

Each part of the scope should be connected to the task lead, be it a manager, technical expert, junior technologist, or any other person on the project team. For example, design might be the responsibility of the design engineer, and drafting the responsibility of the draftsperson, and so forth.

Although all roles and responsibilities should generally by known at the project outset, responsibilities can change throughout the project, particularly if the project scope changes.

Deliverables

Most projects have physical deliverables such as such as a building, computer program, report, and so forth. But sometimes the deliverables can be non-physical like the improvement of an assembly line process, or a redesigned product. Since deliverables represent the items that the project has been commissioned to produce, all deliverables should be identified as part of the scope management plan. That way there is no confusion regarding what the project will produce.

Stakeholder Acceptance

In the PMBOK Guide, acceptance of the deliverables is a centralized part of the scope definition process. Deliverables should be identified and the work breakdown structure itemized, but the process isn’t done until the receiver of the deliverable (project sponsor, client, etc.) has seen what they will get and approved it. This does not mean they have received the deliverable, only that they approve what the deliverable will look like before the work to produce it takes place.

It’s a common occurrence that an owner wants something, let’s say a new bridge, and in their mind everything involved in a new bridge is included in the project. Yet the consultant who manages the project deals with many variables that are unknown and/or changing, and thinks in terms of all the things which pop up which they couldn’t anticipate in the original project inception. Let’s say a concrete plant has a malfunction and several components need to be returned, increasing the consultant’s inspection time.  In the owner’s mind, it’s all part of building a bridge, but in the project manager’s mind, it’s outside the scope. This type of situation is very common and highlights the importance of strong scope definition during project planning.

Scope acceptance documents should be included in the scope management plan.

Scope Control

Identifying the scope to a minute precision is a noble activity and worthy of the utmost of a project manager’s respect, but unless there is a scope control process in place there could still be storm clouds on the horizon. Scope creep is a toxic parasite that will eat your project, and project management career, alive. It refers to the slow and steady addition of unauthorized tasks to the project, and if not monitored and controlled, can result in terrifyingly bad project issues.

Procedures should be in place to inspect and examine the scope of the project at regular intervals and important milestones. Also, since most projects have some sort of scope change during their life span, procedures should be in place to allow for efficient change management and communication.

Conclusion

Hopefully this checklist will ensure your projects don’t become part of the statistics for project failure. If you have any comments or questions, I’d love to hear from you.

➔Free 30-day WBS Software Trial

Breaking work into smaller tasks is a common productivity technique used to make the work more manageable and approachable. For projects, the Work Breakdown Structure (WBS) is the tool that utilizes this technique and is one of the most important project management documents. It singlehandedly integrates scope, cost and schedule baselines ensuring that project plans are in alignment.

The Project Management Institute (PMI) Project Management Book of Knowledge (PMBOK) defines the Work Breakdown Structure as a “deliverable oriented hierarchical decomposition of the work to be executed by the project team.” There are two types of WBS: 1) Deliverable-Based and 2) Phase-Based. The most common and preferred approach is the Deliverable-Based approach. The main difference between the two approaches are the Elements identified in the first Level of the WBS.

Deliverable-Based Work Breakdown Structure

A Deliverable-Based Work Breakdown Structure clearly demonstrates the relationship between the project deliverables (i.e., products, services or results) and the scope (i.e., work to be executed). Figure 1 is an example of a Deliverable-Based WBS for building a house. Figure 2 is an example of a Phase-Based WBS for the same project.

Figure 1 – Deliverable Based Work Breakdown Structure

In Figure 1, the Level 1 Elements are summary deliverable descriptions. The Level 2 Elements in each Leg of the WBS are all the unique deliverables required to create the respective Level 1 deliverable.

Phase-Based Work Breakdown Structure

In Figure 2, a Phase-Based WBS, the Level 1 has five Elements. Each of these Elements are typical phases of a project. The Level 2 Elements are the unique deliverables in each phase. Regardless of the type of WBS, the lower Level Elements are all deliverables. Notice that Elements in different Legs have the same name. A Phase-Based WBS requires work associated with multiple elements be divided into the work unique to each Level 1 Element. A WBS Dictionary is created to describe the work in each Element.

Figure 2 - Phase Based Work Breakdown Structure

A good WBS is simply one that makes the project more manageable. Every project is different; every project manager is different and every WBS is different. So, the right WBS is the one that best answers the question, “What structure makes the project more manageable?”.

How to Make a Work Breakdown Structure

A good Work Breakdown Structure is created using an iterative process by following these steps and meeting these guidelines:

1. Gather Critical Documents
2. Identify Key Team Members
3. Define Level 1 Elements
4. Decompose (Breakdown) Elements
5. Create WBS Dictionary
6. Create Gantt Chart Schedule

Caution: It is possible to break the work down too much. How much is too much? Since cost and schedule data collection, analysis and reporting are connected to the WBS, a very detailed WBS could require a significant amount of unnecessary effort to manage.

There are many WBS software tools available. Some of them are based on mind mapping and others are drawing tools. You can read about these tools in this WBS software review.

Here is an example of how to make a WBS with MindView:

How to Use a Work Breakdown Structure

The Work Breakdown Structure is used for many different things. Initially, it serves as a planning tool to help the project team plan, define and organize scope with deliverables. The WBS is also used as the primary source of schedule and cost estimate activities. But, its biggest contributions to a project are is use as a description all of the work and as a monitoring and controlling tool.

Work Packages
Figure 3 shows the House Project Work Breakdown Structure expanded to Level 1, 2, and 3 Elements. The lowest Levels of each Leg and Branch of the WBS are called Work Packages. Work Packages cover information related to the deliverable, such as owner, milestones, durations, resources, risks, etc. This information is described in the WBS Dictionary.

Planning Packages
There is another type of Work Package called a Planning Package. When the project management plan is approved, scope is known, but not necessarily all of the details. In order to apply the 100% Rule and capture all of the scope, Planning Packages are created. It is understood that as details are defined, the Planning Packages eventually evolve to Work Packages. In the House Project, the project manager knows that the house will have fixtures, but at the time construction begins, there is only a fixture allowance and no fixtures identified. Once the fixtures are determined, the associated Planning Package becomes a Work Package. This planning process is call Rolling Wave Planning and is a from of Progressive Elaboration.

Figure 3 – WBS Work Packages and Control Accounts

Control Accounts
The other application of the WBS is as a monitoring and controlling tool. This is accomplished by defining Control Accounts. Control Accounts are WBS Elements at which the project plans to monitor and report performance. The Control Accounts can be any Element in the WBS. In the House Project, the project manager decides that the project risks associated with using subcontractors can be better managed if the project reports performance for each subcontractor. To monitor their performance, Elements 3.1, 3.2 and 3.3 have been identified as Control Accounts. However, the remaining work in Elements 1.0 and 2.0 will be performed by company resources with less risk and the project does not feel like monitoring and controlling is needed at lower Levels. To assist with the monitoring and reporting, project management information tools are used to collect, analyze and report information at any Element within the WBS.

Create a WBS with the MindView software free trial. Check it out.

Related Links: