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

Chapter 30: Defining the Project Scope

In the previous chapter, we saw how to capture requirements for a project. The next step in managing a project after we gather the requirements is to define the Project Scope. In this chapter, we are going to take a look at how exactly this project scope definition happens.

So, lets get started!!!

What is Project Scope?

We have gone through this multiple times over the course of the previous chapters but still for the sake of completeness lets define project scope here as well. A Projects Scope outlines what work will be done/accomplished as part of the project and also outlines what would not be done as part of the current project.

Why is Scope Definition Important?

Do I need to say why scope definition is important? Without a list of what needs to be done, how can you expect a team to execute a project? Without knowing what to do, the team will be lost and eventually the project will be a failure.

Beginning Scope Definition

The project charter developed during initiation and the stakeholder requirements document, also called the requirement documentation, contain enough information about the project and the product to start defining the project scope. Now that the project is in the planning stage, you have more information than you had in the initiation stage. Therefore, you are in a better position to analyze the needs and expectations related to the project and convert them into requirements. Furthermore, the assumptions and constraints can be revisited and analyzed at greater length, and additional assumptions and constraints can be identified. This will help to define the project scope with more clarity and specificity.

Purpose of the Project Scope Statement:

The Project Scope Statement is the output of the Project Scope Definition activity. The project scope statement serves the following purposes:

• It serves as a component to the baseline that will be used to evaluate whether the request for a change or additional work falls within or beyond the scope of the project.
• By providing a common understanding of the project scope, the scope statement helps bring the stakeholders onto the same page in their expectations.
• Because the scope statement describes the deliverables and the work required to create those deliverables, it is used to create a WBS, which helps in scheduling the project.
• It serves as a guide for the project team to do more in-depth planning, if necessary, and to perform work during project execution.

Scope Definition Process

The scope definition process can be summarized at a high level using the picture below:

As you can see in the picture, the scope definition process uses some inputs, applies some tools and techniques and then produces the output: which in this case will be the project scope document. Let us now take a look at these 3 steps in detail.

Input to Scope Definition

The project charter developed during project initiation presents the high-level project and product description. It also contains other information relevant to defining the scope, such as the project approval requirements. Project and product requirements listed in the requirement documentation also contain critical information for defining the scope.

Some of the organizational process assets that can be helpful in defining the scope are:

• Template for the project scope statement
• Scope-related project files from previous projects
• Lessons learned from previous projects or from previous phases of this project
• Policies and procedures relevant to defining the project scope

Trivia:
It’s critical to the success of the project that you determine the scope correctly: only the required features and functions for the product and only the required work to produce those features and functions; nothing less, nothing more.

Tools and Techniques for Scope Definition

The Tools and Techniques used for Scope Definition are:

• Identification of alternatives - This is a technique used to apply nonstandard approaches to perform project work; in this case, to define the project scope. A host of general management techniques can be used in this category; the most common ones are brainstorming and lateral thinking. Brainstorming was covered in detail in the previous chapter. Lateral thinking is synonymous with thinking outside the box. The idea is to think beyond the realm of your experience to search for new solutions and methods, not just better uses of the current ones.
• Product analysis - To finalize the details of the project scope, you might need to perform product analysis, which might include techniques such as product breakdown, requirement analysis, system analysis, system engineering, value analysis, and value engineering. The goal is to translate the project objectives into tangible deliverables and requirements.
• Facilitated workshops - The facilitated workshops described in the Previous Chapter can also be used in defining the scope.
• Expert judgment - You can use help from relevant experts in the organization to develop parts of the detailed project scope.

Output of Scope Definition

Depending on the input, the scope definition process can generate two kinds of output:
1. The project scope statement that contains the original scope definition and
2. Updates to some project documents

Changes and Updates

In the process of defining the project scope, you may end up modifying the existing requirements or adding new requirements. You may also learn more about the stakeholders. So, the documents that may be updated as a result of defining the scope are:

• Requirements documentation
• Requirements traceability matrix
• Stakeholder register

Project Scope Statement

The key output item of the Define Project process is the project scope statement, which is sometimes also called the detailed project scope statement or just the scope statement. The scope statement basically states what needs to be accomplished by the project.

It provides a documented baseline for the following:

• Developing a common understanding among the stakeholders about the project scope
• Making project decisions throughout the lifecycle of the project
• Measuring performance deviations from the scope

The specific elements of the project scope statement are:

• Project assumptions and constraints - Assumptions and constraints are initially included in the project charter. However, at this stage, you have more information about the project, and therefore you can revisit the initial assumptions and constraints, and you might be able to identify more assumptions and constraints. You should document the specific assumptions related to the project scope and also analyze their impact in case they turn out to be false. Due to the uncertainty built into them, the assumptions are potential sources of risk.

The constraints related to the project scope must also be documented in the scope statement. Because the constraints limit the team’s options, the constraints’ impact on the project must be evaluated. The constraints can come from various sources, such as a predetermined deadline for the completion of the project or a milestone, limits on the funds available for the project, and contractual provisions. However, the following are common constraints to consider across all projects:
o Quality
o Resources
o Scope
o Time

Some of the other terms which we might use in the subsequent chapters related to this topic are:

• Project deliverables - A deliverable is a unique and verifiable product, a capability to provide a service, or a result that must be produced to complete a project, a process, or a phase of the project. The deliverables can also include project management reports and documents. The scope statement provides the list of deliverables and their descriptions.
• Project exclusions - This involves drawing boundaries around the project by specifying what is included and what is not, especially focusing on the gray areas where the stakeholders can make their own assumptions, different from each other. It generally identifies what is excluded from the project, which helps to manage stakeholder expectations.
• Product description - The scope statement must describe the product scope and the product acceptance criteria.
     o Product scope description - Product scope is defined as features and functions that characterize a product, service, or result to be delivered by the project. The requirements documentation produced during the Collect Requirements process will help define the product scope.
     o Product acceptance criteria - This defines the process and criteria for accepting the completed products that the project will deliver.

Trivia:
You must be able to make a distinction between objectives, deliverables, and requirements. For example, in a project to launch a website, the website is a deliverable. That the website must print a warning message at the login time is a requirement, and that the website should increase the company revenue by 3 percent is an objective.

Previous: Requirements Collection Process

Next: Creating WBS

Chapter 27: Managing Scope

In the previous chapter, we saw how important it is to create the Project Management Plan and also about how to create it. Let us now get into the Scope Management part of our Project Planning phase.

What is Scope?

The scope of a project consists of the project scope and the product scope. The project scope is defined as the work that must be performed to deliver the required products, services, or results with the specified functions and features. The product scope is the set of functions and features that characterize a product, service, or result to be delivered by the current project.
It is about both what is included in the project and what is not. In other words, scoping a project means drawing boundaries around it, so that everyone knows what will be done and what will not be done. The importance of managing the project scope cannot be overemphasized because it has a profound impact on the overall success of the project.

Trivia:
Project scope is not the same thing as the product scope. Project scope is the work required to deliver the product scope.

Is Scope Management Important?

If you feel the scope management is not important, imagine this:

Let’s say you started a project to deliver an online banking website for ABC Bank and are 6 months into development. The go live date is in 12 weeks and the customer wants to include credit card information in the website. This was not part of the initial estimates & scope.
Unfortunately, your project manager accepted this because he wanted to please the customer.
Now think what will happen to you and your team mates? You all will be neck deep in unexpected work and the next 12 weeks will be most miserable work days of your life and that is only if you manage to deliver the project to the customer. If you don't, then its only going to get worse…
If your project manager had put his foot down and said, the credit card details were not part of the initial scope & estimate and a change of this magnitude cannot be taken up in such a short notice of 12 weeks, imagine the scenario…

Now you get the idea of why scope management is important?

What is Project Scope Management

The major goal of scope management is to ensure that the required work and only the required work is included and performed in the project.

Just go back to the previous paragraph and read the example. If the project manager had a scope management document that outlined the list of tasks that will be completed as part of the project, he could use that to substantiate his argument that, such a large chunk of work cannot be taken up this late in the project execution.

The Project Scope Management will do the following:

1. Collect requirements - Define the project and product requirements and develop a plan to manage those requirements. This will help clarify what needs to be done.
2. Define scope - Develop a detailed description of the project and the product that will determine what needs to be done.
3. Create work breakdown structure (WBS) - Break down the scope into concrete, manageable components.
4. Verify scope - Formalize the acceptance of the completed project deliverables. Identify how you will verify that the project scope has been executed as planned.
5. Control scope - Determine how to monitor the status of the project and product scope and monitor and control changes to the scope.

Let us take a picture to understand this better.

Note: The above picture is a high level view. Each stage may involve an in depth analysis by the Project Manager to capture accurate information.

Let us now take a look at which process group each of these activities belong to and what the output of these activities would be.

Scope Management Process	Process Group	Output
Collect Requirements	Planning	Requirement management plan and other requirement documents
Define Scope	Planning	Project scope statement
Create WBS	Planning	WBS and scope baseline
Verify Scope	Monitoring and controlling	Acceptance of deliverables and change requests
Control Scope	Monitoring and controlling	Work performance measurements

Developing the Project Scope Management Plan

Before starting to perform the five scope management processes, you develop the scope management plan. This work is recommended to be part of the effort of developing the project management plan. This plan will work as a guide for handling the following:

• How can you define the scope? To answer this question, the scope management plan includes the following:
      o A process to prepare a detailed project scope statement based on the preliminary project scope statement.
      o A process that will enable the creation of the work breakdown structure (WBS) from the detailed project scope statement and will establish how the WBS will be maintained and approved.
• How can you verify the scope? The scope management plan answers this question by including a process that describes how the formal verification and acceptance of the completed project deliverables will be obtained.
• How can you control the scope? The scope management plan answers this question by including a process that specifies how the requests for changes to the detailed project scope statement (which we also refer to as the scope statement) will be processed.

Whether the project scope management plan is informal and high-level (without too much detail) or formal and detailed depends upon the size, complexity, and needs of the project.

The project scope management plan becomes part of the project management plan.

So, the project scope planning specifies how to define, verify, and control the project. Before you can actually define the scope, though, you need to have a very crucial item in place: stakeholder requirements.

Previous: Developing Project Management Plan

Next: Collecting Requirements