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 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