Chapter 11: Project Scope Management as part of Project Planning

Aim: To understand the Processes those are part of the Project Scope Management area. They are:
• Collect Requirements
• Define Scope &
• Create Work Breakdown Structure

Scope management is the set of processes that ensures that the requirements of the customer are captured in a specification of work that ensures the delivery of the project’s deliverables, that all the project work is done, and that only the work required to complete the project is done. In other words, scope management makes sure that the project is completed without expending any unnecessary effort.

The collect requirements process seeks to use multiple tools and techniques to collect all of the project requirements from all of the stakeholders. This process attempts to leave no stone unturned and results in a complete list of project requirements. When properly performed, the collect requirements process dramatically reduces surprises as the project progresses toward completion.

The table below shows the inputs, tools and techniques, and outputs for the collect requirements process.

Collect Requirements
Inputs	Tools & Techniques	Outputs
Project charter Stakeholder Register	Interviews Focus groups Facilitated workshops Group creativity techniques Group decision-making techniques Questionnaires and surveys Observations Prototypes	Requirements documentation Requirements management plan Requirements traceability matrix

You can learn more about the Collect Requirements Process by Clicking Here

The next process, define scope, is the process that clearly states what the project will and will not accomplish. The supporting documents are reviewed to ensure the project will satisfy the stated goals and the resulting scope should state the stakeholders’ needs and clearly communicate the expectations for the performance of the project.

The table below shows the inputs, tools and techniques, and outputs for the scope planning process.

Define Project Scope
Inputs	Tools & Techniques	Outputs
Project charter Requirements documentation Organizational process assets	Expert judgment Product analysis Alternatives identification Facilitated workshops	Project scope statement Project document updates

You cal learn more about the Define Project Scope process by Clicking Here

Work Breakdown Structure

Many inexperienced project managers move too quickly from the scope statement to the activity sequencing processes. This practice is a mistake and often leads to activity omissions and inaccurate plans. PMI stresses the importance of creating a work breakdown structure (WBS) before moving to activity management processes.
The WBS provides the project manager and project team with the opportunity to decompose the high-level scope statement into much smaller, more manageable units of work, called work packages. The resulting WBS should provide a complete list of all work packages required to complete the project (and most importantly nothing more).

The table below shows the inputs, tools and techniques, and outputs for the create WBS process.

Create WBS
Inputs	Tools & Techniques	Outputs
Project charter Requirements documentation Organizational process assets	Decomposition	WBS WBS dictionary Scope Baseline Project document updates

In creating the WBS, the project team repeatedly decomposes the work of the project into smaller and smaller units of work, resulting in a collection of small work packages. The process continues until the resulting work packages are simple enough to reliably estimate duration and required resources. Don’t go overboard, though. When you have work packages that are manageable and represent a single work effort, stop the process. Each project is different, so this process results in different levels of detail for each project.

Exam Watch:
The term “work package” refers to an individual project activity. The work package is the lowest level WBS component. According to the PMBOK, “A work package can be individually scheduled, cost estimated, monitored, and controlled.”

The last main feature of the WBS is that it is organized in a hierarchical fashion. The highest level is the project. The children that represent project phases, divisions, or main deliverables are listed under the project. Each child process or task is divided into further levels of detail until the lowest level, the work package, is reached. Below is a sample WBS with multiple levels.

In addition to the WBS itself, another output of the create WBS process is the WBS dictionary. The WBS dictionary is a document that supports the WBS by providing detailed information for each work package. The WBS dictionary can contain many types of information, including
• Work package name or identifier
• Accounting code identifier
• Description of work
• Technical specifications
• Quality requirements
• Owner or responsible party assignment
• Required resources
• List of schedule milestones
• Associated schedule activities
• Cost estimates
• Acceptance criteria
• Contract information

You can learn more about the Create WBS process by Clicking Here

Prev: Chapter 10

Next: Chapter 12

Summary - Project Scope Planning

In the previous chapters, we have successfully completed the Project Scope Planning section of Project Planning. Let us quickly summarize the key points we learnt in this topic.

• After a project has been initiated, the project management plan is developed to specify how the project at hand will be executed, monitored & controlled, and closed.
• The project management plan can contain subsidiary plans, such as a quality management plan, a risk management plan, a project scope management plan, and a scope baseline.
• The scope baseline consists of the project scope statement, work breakdown structure (WBS), and WBS dictionary.
• Collecting requirements is part of the scope planning, which creates requirements documentation.
• The project charter and requirements documentation are used to define the scope, which creates the project scope statement.
• The project scope statement is a document that defines the scope of a project, including the product scope, by stating what needs to be accomplished by the project.
• It includes project deliverables, product description, product acceptance criteria, assumptions and constraints, and project exclusions.
• The project scope statement and requirements documentation are input items to creating the work breakdown structure (WBS), which is a breakdown of project deliverables into manageable pieces called work packages, which in turn are used to develop the project schedule.
• The WBS is supported by another document called the WBS dictionary, which offers details for the WBS components.
• The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all change requests are evaluated.
• The WBS is the heart of project management, as it is used in managing many aspects of the project, including developing the schedule.

Previous: Before & After WBS

Next: Important Terms - Project Scope Planning

Chapter 32: Before and After the WBS

In the previous chapter, we saw how to create the WBS. Since the WBS is an important artifact, it would be better if we take a look at it with some more details.

So, lets get started!!!

Creating the WBS:

Even though we looked at how to create the WBS in great detail, it would make it easier for you to understand the whole process if we have another picture to explain it. Below is a picture that explains how the WBS is created.

In the picture above, each of the boxes is a document/artifact and arrows indicate the direction in which data flows. The numbers indicate the order in which data flows. For ex: The contract and the SOW are inputs to create the Project Charter. Similarly the Project Charter is an input to create the Stakeholder Register and these two together are inputs to the Requirement Documentation step and so on.

The WBS is at the heart of project management. It affects directly or indirectly almost all the processes that are performed after its creation.

Processes Based on the WBS:

As part of managing the project, there are many processes that are directly based on the WBS as part of the Scope Baseline. They are:

1. Cost Estimation
2. Quality Planning
3. Risk Identification
4. Procurement Planning
5. Defining Activities for Project Schedule
6. Budget Determination

Let us look at a diagram to understand this better.

The three most important things you need to understand about Project Scope Planning are:
• You need to collect requirements by using the Collect Requirements process before you can define the project scope.
• The requirements documentation generated by the Collect Requirements process and the project charter generated during the project initiation are used to define the scope, which is documented in the project scope statement.
• The requirements documentation and the project scope statement are input items to create the work breakdown structure (WBS), which is a breakdown of project deliverables into manageable pieces called work packages. The WBS is supported by another document called the WBS dictionary, which offers details for the WBS components.


Previous: Creating the WBS

Next: Summary - Project Scope Planning

Chapter 31: Creating a Work Breakdown Structure (WBS)

In the previous chapter, we saw how to create the Project Scope Document. The next step in planning for a projects scope is to create the Work Breakdown Structure or WBS. This is what we are going to look in this chapter.

So, lets get started!!!

What is WBS?

WBS stands for Work Breakdown Structure. It is something that helps breakdown the whole projects scope into smaller and more manageable pieces. This is also a very important process in project management. To be able to actually execute the project, the project scope is broken down into manageable tasks by creating a work breakdown structure (WBS). In other words, a WBS is a deliverable-oriented hierarchy of the work that must be performed to accomplish the objectives of and create the deliverables for the project.

How to create the WBS?

Just like other documents related to project planning & management, the WBS is created using a set of inputs, by applying a set of tools & techniques to create the WBS. The picture below is a high level summary of how the WBS is created.

The project scope statement contains the list of deliverables and the product description. The requirements documentation describes the product and project requirements. Information in these two items provides the basis for creating the WBS. You should always consider organizational process assets while going through this and several other processes. In this case, the organizational policies and procedure related to creating the WBS, as well as relevant project files and lessons learned from previous projects, are some examples of organizational process assets that can be helpful.

Furthermore, even though each project is unique, there are similarities among sets of projects in an organization. These similarities can be used to prepare templates that will be used as a starting point for the WBS, to avoid the duplication of work. With or without templates, you will need to go through breaking down the deliverables, a very important step in creating the WBS.

Decomposition

Decomposition is a technique used for subdividing the project deliverables into smaller, manageable tasks called work packages. The WBS is a hierarchical structure with work packages at the lowest level of each branch. Based on their complexity, different deliverables can have different levels of decomposition.

To understand Decomposition better, let us take a look at an example WBS of a Website Development Project

In any WBS – the lines are called “Branches” and the boxes are called “Nodes”. For practical understanding purposes, each of these nodes can be considered as one manageable piece of work.

As you can see, we have decomposed the whole project work into 3 parts:
1. User Interfaces
2. Server &
3. Database

Each of these parts is further divided into more nodes which carry out a specific function that is part of the higher level activity.

How do you decompose a Project Work?

You can decompose the project work by executing the following steps:

1. Identify the deliverables and the work involved by analyzing the project scope statement and the requirements documentation.
2. Understand the relationships among the deliverables.
3. Structure and organize the first level (Server, UI and Db in our example) of the WBS hierarchy. Based on the project at hand, you can use one of the following approaches:
     o Use the deliverables as the components in the first level.
     o Use the phases of the project as the components in the first level.
     o Use the subprojects as components in the first level. A subproject is a part of the project that is independent enough of the rest of the project that it can be performed by another project team. This approach is useful when you want to outsource parts of the project.
     o Use different approaches within each branch of the WBS, for example, a subproject and deliverables in the first level.
4. Decompose the upper level into more detailed components for the lower level.
5. Keep decomposing to lower levels until necessary and sufficient decomposition has been achieved.
6. Assign identification codes to the WBS components.

Trivia:
As the work is decomposed to lower levels of detail, work components become more concrete and manageable. However, you should avoid excessive decomposition, because it will lead to a large number of work packages, and it will not be possible to manage all of them effectively. In other words, excessive decomposition leads to inefficient use of management and other resources. Necessary and sufficient decomposition is the key.

During decomposition, the components are defined in terms of how the project work will actually be executed and controlled. You must verify the correctness of the decomposition at each level by verifying that the lower-level components are necessary and sufficient for the completion of the corresponding higher-level deliverables.

Trivia:
While using the technique of decomposition, remember a useful concept or trick: rolling wave planning. It’s a fancy term that refers to handling a deliverable or subproject that currently cannot be decomposed fully because you don’t know the details about it yet. For example, it is to be executed far into the future. You leave the decomposition of such a deliverable at a level allowed by the available information and wait for further decomposition until more information becomes available. Yes, you got it right. This is an example of progressive elaboration.
The WBS document is the key item of the Create WBS process, but there are some other output items as well.

Output of Creating WBS

The output of the Create WBS process consists of the following items:

Work breakdown structure

As explained earlier, the WBS is a deliverable-oriented hierarchical structure that decomposes the deliverables into the work that will be executed by the project team to create the planned deliverables and to accomplish the planned project objectives. The project manager creates this document with the help of the project team. Following are some important characteristics of the WBS:
• Control account - Remember that each node represents a deliverable or a component of it at certain level, and each deliverable will have scope, schedule, and cost attached to it. Some suitable nodes in the WBS are selected as management control points. At each of these control points, scope, schedule, and cost are integrated for the purposes of monitoring and controlling the performance. For example, the integrated scope, schedule, and actual cost at these points can be compared to the earned value to measure the project performance. Such management points are called control accounts. Each control account may have one or more work packages under it. Obviously, each work package must belong to only one account; otherwise, some factors, such as cost, will be double counted or counted multiple times. A WBS component that is below the control account, that has a well-defined work content but does not yet have a detailed schedule, is called a planning package.
• Code of account - Each component in the WBS hierarchy, including work packages, is assigned a unique identifier called a code of account identifier. These identifiers can then be used in estimating costs, scheduling, and assigning resources.
• Scope - The WBS embraces the full scope of the project. If a task is not included in the WBS, it will not be done as a part of the project.
• Step toward team building - Because the project manager creates the WBS with the help of the project team, it is also the beginning of the team-building process on the part of the project manager.
• Step toward scheduling - The WBS decomposes the project work into manageable pieces that can be assigned to individuals. This helps define the responsibilities for the team members and is the starting point for building the schedule.
• Reference for communication - Throughout the project, the WBS works as a reference for communication regarding what is included in the project and what is not.

WBS dictionary

This is a supporting document for the main WBS document to provide details about the components of the WBS. The details about a component might include elements such as a code of account identifier, description of work involved, quality requirements, acceptance criteria, a list of milestones schedule, cost estimates, required resources, contract information, and the organization or group responsible for this component.

Updates

During the create WBS process, the project team might realize that something out of the existing scope must be included in order to accomplish something in the scope. This will give rise to a change request, which might also come from other stakeholders during or after the first creation of the WBS. After the change request has been approved, not only the WBS will be changed—the scope statement must also be updated accordingly. The impact of the approved change request on the project scope management plan must be evaluated, and the plan must be updated accordingly.

Scope baseline

This is not a different item in and of itself. The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all the change requests will be evaluated.

Trivia:
Do not confuse the WBS with other information breakdown structures, such as the organizational breakdown structure (OBS), which provides a hierarchy of the performing organization and can be used to identify organizational units for assigning the WBS work packages. Remember, the end goal of the WBS is to specify the project scope in terms of work packages; this is what distinguishes the WBS from other information breakdown structures.

A Last Word:

You might be wondering who creates the WBS. Well, as expected, it is your responsibility, and you, the project manager have to create it with the help of your team.


Previous: Defining Project Scope

Next: Before & After the WBS