Project Scope Planning Tools & Techniques

The project scope is a description of all the work that must be done on a project. It includes all of the deliverables and all of the activities needed to create the deliverables. Scope planning links with schedule planning and resource/budget planning since each task or activity must be scheduled to occur at a particular time in the project and each task or activity requires an individual or organization be assigned to do the work.

I have found that often a project leader or project team will confuse the concept of project scope with that of product scope. Product scope is the complete list of features, functions, or characteristics that a product or service is intended to provide. The activities needed to complete the product scope are elements of the project scope. However, the project scope will include many additional activities that are unique to managing the project but are not deliverables within the product. For example, the project scope includes preparation and support for meetings, reviews, supplier management, and preparation of documentation. When a project leader or project team member only considers product scope while planning the project, they will under plan the amount of time and resources needed to complete the project.

Many organizations have customized tools or templates to assist the project team with scope planning. I recommend that you use those if they are available. I have found five scope planning tools or techniques to be helpful, depending upon the uncertainty and complexity of the project. These are the Traceability Matrix, the Scope Statement, a Deliverables Deployment, the Work Breakdown Structure (WBS), and the WBS Dictionary.

Traceability Matrix

The Traceability Matrix is most commonly used on Complex projects. The matrix is a table that traces each requirement through any related sub-project's requirements and through the project life cycle to ensure that it is fully satisfied. It is both a planning tool, showing the project management team's intention with respect to meeting the requirement, and a tracking tool, as it also shows the results of any test or analysis that demonstrates the requirement has been partially or fully met.

The types of requirements included in a traceability matrix typically include:
Business goals or objectives
Product requirements
Business process requirements
Logistical support requirements
Regulatory or agency requirements
Project safety or security requirements
When these requirements are flowed down to sub-projects, the allocation methodology is documented and, if necessary, interfaces control documents are used to control the interaction between sub-projects.

Project Scope Statement

The Project Scope Statement is a document that is used to provide clarity for both the project team and project stakeholders. The scope statement describes the major deliverables, provides a high-level description of acceptance criteria, and many times will also include constraints and project exclusions. On a Simple or Focused project, the Scope Statement can usually be captures within a paragraph or two. On a Full-scale or Complex project, the Scope Statement may be several pages in length.

When a large project has many divers stakeholders and project work is being accomplished in several locations, the Scope Statement becomes a continuing reminder of what the project is supposed to do, and what it is not supposed to do. It is referred to at Tollgate reviews to ensure the project stays on course and does not suffer scope creep.

Deliverables Deployment Diagram

The Deliverables Deployment Diagram is a socpe planning technique for Extreme or Adaptive projects. This technique starts with a deliverable of the project and then asks the question, "What is needed to create that deliverable?" This question may need to be asked several times to break the project deliverables down into actionable activities. This technique is especially powerful when the project deliverable has been changed and a revised scope must be established. I normally will create this diagram in fishbone or mind-map layout. Once all of the activities are identified, I then transfer them into a WBS Dictionary.

Work Breakdown Structure

The Work Breakdown Structure (WBS) is a deliverables oriented, hierarchical decomposition of project requirements. Major deliverables are subdivided into smaller more manageable activities. These activities then become the building blocks used to plan the project. A WBS is typically developed in layers. At the highest layer are the major project deliverables. As project planning progresses, each of these are decomposed into sub-activities. In a phased project, the decomposition of some deliverables may not occur until earlier phases are completed. Each activity can be further decomposed to lower and lower layers until the activity is at a level that can be planned and managed by the project team. If a project is not decomposed sufficiently, the project leader and project team may not be aware of significant risk items until the risk is out of control. If a project is decomposed excessively the decomposition creates many unnecessary tasks that generates an enormous bureaucratic burden on project management without providing improved oversight of the project.

There are several different ways to decompose the major project deliverables. They can be decomposed based upon subdividing deliverables as described in the Deliverables Deployment Diagram. They can also be decomposed based upon business process. They can be decomposed based upon which organization or department will do the work. It can also be decomposed based upon which project phase in which different elements of the work will be done. Any of these methods is acceptable and often a WBS is developed in a mix and match mode where different levels are developed using different approaches. My recommendation is to organize the decomposition based upon the way you intend to control the project. When organized in that manner, you can roll up lower levels of performance to quickly provide a high-level assessment of project status. However, on Complex projects, often there is a WBS structure that is mandated for the sub-projects. This aids the program manager in his or her effort to consolidate the sub-project inputs into an overal program plan and status. This approach is a benefit for the program manager but is often a bureacratic nightmare for the sub-project leader.

A WBS can be presented in two different modes. One mode is a diagram that looks like an organizational chart. The top of the chart is the major deliverables. As each layer is decomposed, additional levels are shown on the chart. The second mode is a table. The left column(s) shows the level of decomposition. Typically a numbering system or code is used to identify each item in the table. Each digit in the identifier number represents a different layer of decomposition. The table mode often is soon transformed into a WBS Dictionary which is discussed in the next section.

WBS Dictionary

The WBS Dictionary incorporates the table mode of showing a WBS with additional information about each of the activities. Typically a WBS Dictionary is built using a spreadsheet. The WBS information is in the first few columns of the spreadsheet. Additional columns are added that are the repository of both planning and controlling information about each activity. I prefer to use the columns:
Task Deliverable
Responsible Individual/Organization
Duration
Budget
Risk Factors
Status

When managing a project using a spreadsheet as the project management information system the WBS Dictionary is the primary planning tool and tracking tool. Many Simple and Focused projects are managed using the spreadsheet approach. When that approach is chosen, the WBS Dictionary documents the result of the planning processes. As the project unfolds and additional activities are identified or if the project needs to be rebaselined at a Tollgate meeting, the spreadsheet is updated.