Plan and Define Project Scope (PMBOK®

Guide Sixth Edition)

Course Overview
Read the Course Overview.

Collecting Requirements and Defining Scope

1. Defining Project Scope

2. The Plan Scope Management Process

3. Inputs to Collect Requirements

4. Tools and Techniques for Collecting Requirements

5. Characteristics of Effective Requirements

6. Outputs of Collect Requirements

7. Techniques for Defining Scope

8. Outputs of the Define Scope Process

9. Components of a Project Scope Statement

10. Exercise: Planning and Defining Project Scope

Course Overview
[Course title: Plan and Define Project Scope (PMBOK® Guide Sixth Edition). The presenter is
Barbara Waters | PMP. Materials in this course are based on the text A Guide to the Project
Management Body of Knowledge (PMBOK® Guide)-Sixth Edition, Project Management
Institute, Inc., 2017. PMBOK, PMI, PMP, CAPM are registered trademarks of the Project
Management Institute, Inc.] So your project is all approved, and you're ready to get started.
What's the first step? You need to figure out exactly what the end result is going to look like
based on the customer's needs. In this course, you'll learn how to plan scope management for
your project, use the collect requirements process to gather and refine stakeholders'
requirements. And then how to turn those into your scope statement with the defined scope
process.

Back to top
 Defining Project Scope
Learning Objective

After completing this topic, you should be able to

 define the term project scope

1.
[Topic title: Defining Project Scope. Materials in this course are based on the text A Guide to the
Project Management Body of Knowledge (PMBOK® Guide)-Sixth Edition, Project Management
Institute, Inc., 2017. PMBOK, PMI, PMP, CAPM are registered trademarks of the Project
Management Institute, Inc.] Imagine you map out a road trip. You include the route you'll travel,
the guest houses you'll stay in each night and the sightseeing and activities you'll do along the
way. You've defined the scope of your trip. If you add side trips to your route, or choose to stay
at five-star hotels while you're travelling, it will exceed the scope of your plan, thereby increasing
the time and money spent. Like a road trip, a project has a scope. This defines everything you
need to do to get from objectives to the results. If you change the project scope, it's likely to
have implications for the project's cost, time, and quality.

Project scope is defined as all the work required to complete a project's deliverables. By making
it clear exactly what is required, you also make it clear what's not required. So project scope is
like a boundary around a project, with everything required to complete it on the inside, and
everything else outside. If you don't draw a boundary early, too little may be put into a project.
And it will fail to meet requirements. Putting in too much could lead to schedules not being met
and costs getting too high.

Just as the project has a scope, the product also has a scope. It's defined by all of the
components, functions, and features the product must have to meet requirements, but not to
exceed these. Exceeding the requirements and adding extra features is called gold plating. This
contributes to scope creep, and it should be avoided. Project scope is the work required to
deliver the product, so project scope is based on product scope. If new features are added to
the product, even using the proper process of integrated change control, it impacts product
scope as well as increases project scope. At the same time, if the project budget is cut, you may
need to decrease quality or amount of work completed, which will impact product scope. So you
see how product scope and project scope are different, yet very closely related and intertwined.

When performing project scope management activities, there is an important consideration to

keep in mind if you are adapting elements of agile methodology. With agile, less time is
purposely spent on trying to define project scope at the outset of a project, and more time is
spent on refining the project scope as project work progresses. This is especially effective in
projects with high risk, significant uncertainty or where a lot of project requirements may be
unknown in the beginning stages of the project. This is in contrast to traditional project
 management methodology, where the goal is to define the project scope at the beginning of the
project. And only integrate changes to the scope when it's really necessary. For example, to
address a problem. So depending on the type of project you're managing, you can select the
best approach for project scope management.

Scope creep is what happens when the scope of a project changes, usually an increase without
the change being managed. Often these changes seem minor, just a tweak here or there to
improve things. But over time, unmanaged changes add up and can have a major impact on
project costs, schedules and quality.

There are a few main causes of scope creep. Unexpected scope-related issues often arise
during a project. And these can change the project's requirements or raise its complexity. For
example, a recent change in a safety regulation causes the project manager of a construction
project to also consider additional training. This will push the project scope beyond what was
planned and may impact the schedule and budget. Usually everyone with an interest in a project
wants it to produce the best possible result. So it's natural to want to go beyond what's required.
For example, by adding extra features to a product. But this kind of perfectionism can change
the scope of a project and end up costing too much time and money. Stakeholders may make
requests that are beyond the original scope of a project. If you just try to avoid conflict by doing
what they ask, it can change a project's scope. This may lead to delays and overspending,
instead you should discuss each request and consider how it will impact scope before going
ahead. Misunderstandings can change a project scope if they affect what work is done, how
long this takes, or how people on the project team understand requirements.

So when you define scope, you need to be especially careful to avoid ambiguity or unclear
statements. These can lead to conflict and costly delays or changes later. By learning to
recognize these causes, you can mitigate the risks they pose to a project.

Back to top

The Plan Scope Management Process

Learning Objective

After completing this topic, you should be able to

 recognize elements to include in the scope management plan and requirements management
plan

1.
[Topic title: The Plan Scope Management Process. Materials in this course are based on the
text A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Sixth Edition,
Project Management Institute, Inc., 2017. PMBOK, PMI, PMP, CAPM are registered trademarks
of the Project Management Institute, Inc.] If you are following along with the PMBOK® Guide,
Sixth Edition, Plan Scope Management is Process 5.1, where the Planning Process Group and
Project Scope Management Knowledge areas intersect. The inputs, tools and techniques, and
outputs are in Figure 5-2. [A figure displays. It contains 3 sections, which are Inputs, Tools and
Techniques, and Outputs. The figure is captioned as Figure 5-2. Plan Scope Management:
Inputs, Tools and Techniques, and Outputs Project Management Institute, A Guide to the
Project Management Body of Knowledge, (PMBOK® Guide) - Sixth Edition, Project
Management Institute Inc., 2017, Page 134.]

You are ready to start planning a new project. Where do you begin? With the schedule, the
budget? No, the first step is to establish the scope of your project, what features the product or
service will have, and exactly how they will meet the customer's expectations. The Plan Scope
Management process will guide you in establishing exactly what work your team needs to carry
out in order for the project to be successful. The purpose of this process is to create a scope
management plan that documents how the project scope will be defined, validated, and
controlled. The scope management plan is a component of the overall project management plan
and provides guidance and direction on how scope will be managed throughout the project.

In order to begin planning the scope of your project, you must gather the information you will
require. The inputs to the Plan Scope Management process include the following. Planning
scope management begins with an analysis of the information found in the project charter. It
provides the rationale for the project and how it will meet the customer's business need. It also
contains the project's objectives and a general description of the anticipated product and its
features. Considering business need and desired features are the first step in determining what
the product will look like and plotting the scope of the project.

The project management plan is a critical input to any of the planning processes. Early in the
planning phase, it contains a rough estimate of the budget allocated for the project and a
general time frame. These parameters contribute to determining the scope of the project. It also
contains a description of the processes that will be used to create the product. The specific
components of the project management plan are the quality management plan, project life cycle
description, and development approach. Quality policies and standards, the life cycle, and the
methodologies, such as plan driven versus agile, serve as influences to the project
management plan.

The enterprise environmental factors that influence scope management planning include
infrastructure that may impact how the work is carried out or what work can be carried out, as
well as marketplace conditions. For example, the availability of raw materials could determine
whether certain product features are included in the scope.

In planning scope management, the project manager will need to comply with the organization's
policies and procedures, which will always influence how work is planned and carried out. Any
historical information and lessons learned from previous, similar projects will also be useful in
determining scope.

Once you have gathered the inputs, it is time to prepare the planning documents.
The tools and techniques for the Plan Scope Management process are expert judgment,
meetings, and data analysis. Use expert judgment to determine how scope was managed on
similar projects, and to capitalize on the expertise of others. Based on the information about
your current project, found in the project charter and project management plan, you'll examine
records from similar past projects. You may also use alternatives analysis, a type of data
analysis, to evaluate the ways in which activities are performed, such as how scope will be
elaborated, validated, and controlled. You may also want to hold planning meetings to draw on
the expert judgment of others. Meeting attendees may include the project sponsor and other
stakeholders who have insight into what the project scope will be and how best to manage it.

The goal of the Plan Scope Management process is to produce two key documents, the scope
management plan and the requirements management plan. The scope management plan may
be broadly based or detailed, depending on the needs of the project. At the very least, it should
describe how the scope statement will be prepared, the process for creating, approving, and
maintaining the work breakdown structure, or WBS, how the acceptance of deliverables will be
obtained, and how scope change requests will be handled. The second key output is the
requirements management plan, a component of the project management plan. It describes
how the project requirements will be analyzed, documented, and managed. Project
requirements are the specifications the product or service must meet in order to satisfy
stakeholders' needs and expectations.

How requirements are managed depends largely on the phase to phase relationship chosen for
the project. For example, in a sequential phase relationship, the plan may indicate that all
requirements will be completed within their associated phases. In a project where phases
overlap, requirements may be carried over from phase to phase and managed throughout the
life cycle of the entire project. Some projects may be a combination of both situations. In
addition to describing how requirements will be managed across project phases, the
requirements management plan includes, activities related to creation of the requirements and
how they will be planned and tracked, the configuration management process that will control
and report changes to the product, the process for prioritizing requirements, and metrics for
evaluating requirements.

So in summary, the Plan Scope Management process is the first process in the Project Scope
Management Knowledge area. You use expert judgment and meetings to create two key
documents, the scope management plan and the requirements management plans, both of
which are subsidiary plans within the project management plan.

Back to top

Inputs to Collect Requirements

Learning Objective

After completing this topic, you should be able to

 identify inputs to the Collect Requirements process

1.
[Topic title: Inputs to Collect Requirements. Materials in this course are based on the text A
Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Sixth Edition, Project
Management Institute, Inc., 2017. PMBOK, PMI, PMP, CAPM are registered trademarks of the
Project Management Institute, Inc.] If you are following along with the PMBOK® Guide Sixth
Edition, Collect Requirements is process 5.2, where the planning process group and project
scope management knowledge areas intersect. The Inputs, Tools & Techniques, and Outputs
are in figure 5-4. [A figure displays. It contains 3 sections, which are Inputs, Tools and
Techniques, and Outputs. The figure is captioned as Figure 5-4. Collect Requirements: Inputs,
Tools and Techniques, and Outputs Project Management Institute, A Guide to the Project
Management Body of Knowledge, (PMBOK® Guide) - Sixth Edition, Project Management
Institute Inc., 2017, Page 138.]

If you were hired to create the blueprints for a house, you'd have to know what the customer
expected, right? For example, should it have more than one floor? What rooms are needed and
how big should they be? In the same way, you can't plan the work needed for any project until
you know exactly what it must deliver. That's what the Collect Requirements process is all
about. It's the process you'll use to gather the requirements a project must meet. The PMBOK®
Guide describes it as determining, documenting, and managing stakeholder needs and
requirements to meet project objectives. The key benefit of this process is that it provides the
basis for defining and managing the project scope, including product scope.

Requirements are functions or features a product must have, as well as needs that stakeholders
want to have met in the project's final result. So requirements depend on the attributes of a
product and on the clients' needs. For example, a requirement for building a new house may be
that windows must be double glazed to meet local building regulations. Another requirement
may be that the house include an open plan living area because this is what the home owner
has requested. Getting to a final set of project requirements isn't as simple as just asking
stakeholders what they need. Often, stakeholders start with very general ideas of what they
want. You have to narrow these ideas down into specifics to make sure you understand what's
really required. It's vital to define and document requirements in as much detail as possible for
the following reasons. They represent the customers' and other stakeholders' expectations.
They form the basis for a project's work breakdown structure, otherwise known as the WBS, and
for all cost, time, and quality planning. And finally, they are needed for control purposes, so you
can make decisions for a project quickly and effectively.

It can be a lengthy process to get a final set of project requirements. By the time you start work
on this, however, other processes have already created some starting points you can use as
inputs. The inputs for the Collect Requirements process include the project charter. The project
charter identifies high-level requirements. It also provides a high-level description of the product
or service a project must deliver. As an example, a project charter might state that a project
must deliver the design for a small, affordable, and fuel efficient family car. It might specify how
 this fits in with the company's aim of expanding into new markets. But it won't tell you the exact
design that will best meet the needs of the company or its customers.

Components of the project management plan are also inputs to this process. The scope
management plan provides direction on how project teams should determine which types of
requirements need to be collected. The requirements management plan outlines processes that
will be used to define and document stakeholder needs. The stakeholder management plan
details stakeholder communications requirements and the level of stakeholder engagement
necessary. Information in the plan is used in the Collect Requirements process as a guide to
determine which stakeholders to involve in a requirement's activities and how best to do so.

Another input to planning scope management is project documents, including the assumption
log, lessons learned register, and the stakeholder register. The stakeholder register lists
stakeholders for the project. The project's results must meet their needs, so you need to consult
stakeholders for detailed information about a project's requirements.

Other inputs include business documents, such as the business case, agreements, and relevant
enterprise environmental factors, and organizational process assets.

Back to top

Tools and Techniques for Collecting

Requirements
Learning Objective

After completing this topic, you should be able to

 identify the tools and techniques you use to collect project requirements

1.
[Topic title: Tools and Techniques for Collecting Requirements. Materials in this course are
based on the text A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-
Sixth Edition, Project Management Institute, Inc., 2017. PMBOK, PMI, PMP, CAPM are
registered trademarks of the Project Management Institute, Inc.] In this topic, you'll learn about
the tools and techniques of the Collect Requirements process.

Throughout all your activities, of course, you'll use the first technique, expert judgment. That of
your own and those around who have the expertise you require for your work.

One group of techniques you could use to collect project requirements is data gathering. Some
data gathering techniques include brainstorming, which we will cover in detail in a moment.
They also include conducting interviews with stakeholders, subject matter experts, and people
who've worked on related projects. These people can help you identify what features and
functions a product or service should have. Most often, you'll hold one-on-one interviews. You
can ask the person you interview a set of questions you've prepared and any other questions
that come up, and you record the person's responses.

Focus groups, another data gathering technique, are a less formal way of collecting project
requirements. In a group of stakeholders and subject matter experts, you guide an interactive
discussion about what a proposed product or service must deliver. This can help you find out
what expectations the stakeholders have. Usually a focus group includes stakeholders with a
similar role or perspective. You use the group to collect requirements focused on a specific
aspect of a project, like the design of a product or the technical requirements it must meet. And
questionnaires let you gather responses to a set of written questions. Using these tools, you can
get information from a large number of people quickly. And information gathered in this way can
usually be evaluated using statistical analysis. You could use an online questionnaire, for
instance, to find out which features customers across the country value most in a new car. But it
probably wouldn't be a good idea to use a questionnaire to find out what requirements executive
managers in your company have for a new car model.

Benchmarking is another data gathering technique and involves studying how other
organizations create similar products and identifying best practices and new innovations.

One important data gathering technique is brainstorming. Brainstorming allows you to generate
and capture many ideas about project and product requirements. Brainstorming is a great way
to generate an unstructured list of possible project requirements. This is because it encourages
everyone in a group to have their say. And what one person says often inspires someone else
with a new idea. For a brainstorming session to work, it's important to follow four rules. Identify
the objective or problem and post it where everyone can see it. Although brainstorming isn't
very structured, its focus must be clear. For example, an objective might be to develop
requirements for a new product. Record all the ideas stakeholders come up with so no good
ideas are lost. Make sure nobody criticizes other people's ideas. This can cause conflict and
keep people from having their say openly. Also, negativity greatly hampers creativity but
positivity fosters it. Encourage everyone to build on other people's ideas. One especially
effective strategy is to use brainstorming after you've already created a mind map. The purpose
of the brainstorming session would be to clarify the earlier set of requirements.

Another important class of techniques is data analysis techniques. These include document
analysis, which involves studying documents such as business plans, marketing materials and
issue logs to identify requirements.

Decision-making is another key technique. Decision making methods can include voting and
multi-criteria decision analysis. Voting methods include unanimity, majority, plurality, and
autocratic voting. In unanimity, everyone agrees with the decision. In a majority, more than 50%
of the group members agree on the decision. A plurality indicates of all the choices, one
decision has the highest number of votes, even if a majority is not achieved. For instance, if
there are three choices, the top choice may represent 45% of the votes, while the second and
third choices represent 29% and 26%, respectively. In an autocratic method or dictatorship, one
person decides for the group, this might sound bad, but in certain situations it is appropriate. For
instance, a risk manager may decide that a particular product feature will not be included
because it adds too much risk. Multicriteria decision analysis involves a systematic approach,
using a matrix to determine the best decision.

Another technique you use to collect requirements includes data representation techniques,
such as affinity diagrams and mind mapping. An affinity diagram can be used to classify large
amounts of data and numbers into groupings so the information is easier to review and analyze.
A mind map is useful because it brings together a lot of ideas. It groups these ideas visually to
make it clear how they relate or differ. At the center of the map is the problem to be solved. As
you think of ideas, you build branches out from the center, each branch groups related ideas. At
the end of each branch, you get to specific ideas that develop from more general ones. When
you're collecting project requirements from a group of stakeholders, the specific ideas you want
to get to at the end of each branch are project requirements.

Interpersonal and team skills are another group of techniques key for effective requirements
gathering. And there are several methods, including the nominal group technique, observation
and conversation, and facilitation. First, we'll discuss nominal group technique. It is a
prioritization tool that lets you guide a group of stakeholders in identifying which requirements
are the most important. The technique can include brainstorming ideas and then ranking them.
Or, if you've already used techniques like brainstorming, it can involve ranking a list of possible
project requirements that you've already put together. An advantage of the nominal group
technique is that it lets each stakeholder in a group have a say about what's most important to
them. Another advantage is that ideas are anonymous, so idea sharing can happen without
leading to conflict. The way people rank their requirements can even stay secret. In case you're
curious, it's called nominal group technique because it's done with a group of people, but the
decision-making happens at the individual level. For example, let's say there are three possible
requirements and only one of them can be included in the final product. Stakeholders can rank
the three requirements in order of what they like the most to the least. In order to score the vote
properly, the facilitator will determine the weight of a first place vote, second place vote, and so
on. The requirement that has the highest overall score is the requirement that will be included,
and it may not be the requirement that had the most number one votes. A variation on the
nominal group technique in Agile is called buy a feature. Stakeholders are given play money
which they can distribute as they wish among the possible features, the feature with the greatest
buying will be included.

Observation is a unique way of identifying requirements. Watching how a task or process is

performed can make you aware of requirements you wouldn't have thought of otherwise. Job
shadowing is a form of observation and involves watching a person or group of people as they
perform their job. This is especially useful for complicated processes, or when the people who
will use a product or service find it difficult to clearly express their requirements. For example,
you might watch an accounting clerk process accounts. This could help you collect
requirements for a new accounting system. You'd be able to record the exact steps required
and might see how the job of the clerk could be made easier. Conversation with the observee
allows you to gain any insight you may need.
 And facilitation involves creating an atmosphere of trust amongst participants, typically during
workshops, to illicit the appropriate information for collecting requirements. Effective facilitation
can build and maintain trust, foster relationships, and open communication between the project
team members.

There are two other tools and techniques for collecting requirements, context diagrams and
prototypes. Context diagrams are a useful model of the inputs and outputs of a system and all
the people surrounding its use.

A prototype is a working model of a product. You can create a prototype early in a project and
let stakeholders use it to see how well it meets their needs. This is a much more concrete way
to collect requirements than simply asking stakeholders what they need. Prototypes are the
most useful if a project must deliver something people will use to complete tasks. For example,
to help collect project requirements for a new accounting system, a project team built a
prototype of the system. The project manager asks a focus group of accounting managers and
end users to try using the prototype to perform accounting tasks. Using an online spreadsheet,
all group members give immediate feedback about the system as they use it. The manager then
meets with the group to get more general feedback. Based on what he learns, the team refines
the prototype and lets the focus group test it again. Once it's clear the prototype meets all
requirements, work on building the final accounting system can start.

So now we have a list of all of the categories of tools and techniques, expert judgement, data
gathering techniques, data analysis, decision making, data representation, interpersonal and
team skills, context diagrams, and prototypes. All of these tools and techniques are used in
combination to effectively gather the requirements for your project.

Back to top

Characteristics of Effective Requirements

Learning Objective

After completing this topic, you should be able to

 recognize examples of good project requirements

1.
[Topic title: Characteristics of Effective Requirements. Materials in this course are based on the
text A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Sixth Edition,
Project Management Institute, Inc., 2017. PMBOK, PMI, PMP, CAPM are registered trademarks
of the Project Management Institute, Inc.] In projects, misunderstandings happen all the time.
One person is measuring in inches and another in centimeters. A team member sees 4 on the
schedule for a task duration and assumes she has 4 days. But it's actually four hours.
Misunderstandings happen because requirements aren't clear or they aren't communicated
clearly. It's easy to misinterpret exactly what a customer wants. And it's common for different
people on a project team to understand specifications a little differently. This is why the Collect
Requirements process is important. And why it's important to do it correctly. Stakeholders and
all the people working on a project need to have the same understanding of what's required. If
they don't, it can spell disaster.

Take this example, say you're managing a project to design and implement a new system for a
call center. Think about this project requirement. The system must significantly improve the
efficiency of the call resolution process. Seems to make sense, right? But the problem with this
requirement is that there isn't a way to assess if it's being met. It's not clear what will be used to
measure efficiency or what's meant by significantly. A better example of a requirement might be,
the system must reduce the average resolution time per call to 5 minutes.

For a project to meet agreed requirements, there must be a way to assess whether the
requirements are being met. So each requirement has to be measurable. It must answer
questions like how much? How many? And how well? It must also be testable so there's an
objective way to verify it. If a requirement is testable, you can verify whether it has been met.
These are examples of some of the techniques you could use to verify requirements.
Demonstrate how a product works to verify it is functioning as required. Observe a product or
service being used, to verify that it performs as required in practice. Examine a product to verify
it has the agreed features.

Let's talk about a couple examples. A pharmaceutical company is developing a training program
for new employees. An early requirement for the project was, must teach the pharmacology of
the company's products. But how can you be sure everyone will agree the training does an
adequate job of teaching how a drug works? This isn't easy to measure or test. The requirement
was changed to, must use three dimensional animations to explain the clinical pharmacology of
the company's products. And include narration for visually impaired employees. This
measurement is measurable and testable. Any stakeholder or project team member can
examine the training product to check if the requirement has been met.

Now, say you're collecting requirements for the license plate holder for the rear bumper on a
new model of SUV. Examples of requirements you can't measure or test are, license plate
holder looks right, will not break under normal use, is rust proof, and is lightweight. For example,
almost anything will crack if enough force is applied. And how light is lightweight? An example of
a requirement you can measure and test is whether the license plate holder on a rear bumper
follows a set of specifications you define. It can also measure and test whether the holder is
made of materials you specify exactly, pass a standard durability test in terms of rust proofing,
and has a certain weight you specify.

As well as being measurable and testable, a requirement must be traceable, forward and back.
You must be able to track it as work proceeds so you know when it has been met. And at the
end of a project, you must also be able to look back and identify exactly how a requirement was
met or why it wasn't. One feature that makes a requirement traceable is a unique ID number.
Giving each requirement a unique identifier that doesn't change throughout a project ensures
that you can track it. Even if circumstances change and it's cancelled. You also need a tracking
 system for logging requirements. And monitoring them throughout the project life cycle. In many
systems, this is called a requirements traceability matrix. Here's how it works. You give each
requirement its unique identifier. And enter the information about it into your tracking system.
Throughout development, as the product goes through creation and testing, you update the
system to show the status of the requirement and when it has finally been met. If any
requirements are changed during development, you have a record of when, why, and how it
changed.

So in summary, product requirements must be clear, measurable, testable, and traceable.

Back to top

Outputs of Collect Requirements

Learning Objective

After completing this topic, you should be able to

 distinguish between the outputs of the Collect Requirements process

1.
[Topic title: Outputs of Collect Requirements. Materials in this course are based on the text A
Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Sixth Edition, Project
Management Institute, Inc., 2017. PMBOK, PMI, PMP, CAPM are registered trademarks of the
Project Management Institute, Inc.] The collect requirements process has two main outputs.
These are the requirements documentation and the requirements traceability matrix.

The requirements documentation is all the details about the requirements that you recorded
during the meetings with stakeholders. Details like the rationale behind why they were prioritized
like they were and all of the agreed upon attributes for each requirement. This gives a baseline
you could use to monitor and control a project throughout its life cycle. The level of detail in the
requirements documentation will differ for different projects but the documentation should do
four things.

Requirements should be grouped by the stakeholders or stakeholder categories they come from
and based on their priority. This helps ensure you can trace requirements easily and guide
project work based on which ones are the most important. It's a good idea to document the
business need or broad project objective that a requirement satisfies. This ensures that
stakeholders and the project team know what overriding objective a requirement is there to
meet. A requirement or its components can be functional, nonfunctional, or quality related. In
other words, it relates to how a product or service must function to features that don't affect its
underlying operation or to perform in standards it must satisfy. Identifying the broad type of each
requirement helps you determine the aspects of project work that are needed to meet it. It's
important to document any assumptions and constraints on which a requirement is based. For
 instance, a requirement to assemble a product by a specified date might depend on a customer
supplying the product components on time.

It's important that all requirements in the requirements documentation are consistent. This
means that meeting one requirement can't rule out meeting another. For example, it might be
impossible to create a camera that's small enough, but also has all the required features. This is
something you'd have to iron out in the collect requirements process before going ahead with
project work. Another example would be training sessions. One requirement is that the duration
of each session be no longer than 20 minutes. But another requirement states it has to cover
certain required content. So the requirements conflict with each other. Either the duration or the
content requirement has to change before the requirements work together and can all be met.

The other output of the collect requirements process is a requirements traceability matrix. [A
table displays. It contains 5 columns and 2 rows. The 5 column headers are ID, Requirement
Description, Backward Traceability, Forward Traceability, and Status.] This is a table that
assigns each requirement a unique ID number, lists the requirement description and its status. It
also lets you relay each requirement back to broader objectives and forward to the more
detailed requirements phases must meet. The requirements traceability matrix has three main
purposes. It ensures each requirement adds value to the project by linking it back to the
business need or objective it helps satisfy. It tracks requirements, including their status,
throughout the project. And it provides a structure for managing changes to the scope of a
project so these changes don't result in requirements not being met.

So the requirements traceability matrix lets you check how far a product or service has come in
meeting each requirement at any point in a project. It's also what you use to map user
requirements to project scope and to product design, development, and testing. For example, it
may map a user requirement like system must remain operational in the case of power cuts, to
a functional requirement like secondary power supply must kick in within 0.1 seconds. The
matrix may also include a summary of the details of each requirement from the requirements
documentation so these can be easily referenced.

In summary, the outputs of the collect requirements process are the requirements
documentation and the requirements traceability matrix. The requirements documentation
identifies each requirement and its attributes. The requirements traceability matrix is a tool you
use to track requirements throughout a project.

Back to top

Techniques for Defining Scope

Learning Objective

After completing this topic, you should be able to

 recognize the tools and techniques you use to define project scope
1.
[Topic title: Techniques for Defining Scope. Materials in this course are based on the text A
Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Sixth Edition, Project
Management Institute, Inc., 2017. PMBOK, PMI, PMP, CAPM are registered trademarks of the
Project Management Institute, Inc.] If you are following along with the PMBOK® Guide Sixth
Edition, define scope is process 5.3, where the planning process group and project scope
management knowledge areas intersect. The inputs, tools, and techniques, and outputs are in
figure 5-8. [A figure displays. It contains 3 sections, which are Inputs, Tools and Techniques,
and Outputs. The figure is captioned as Figure 5-8. Define Scope: Inputs, Tools and
Techniques, and Outputs Project Management Institute, A Guide to the Project Management
Body of Knowledge, (PMBOK® Guide) - Sixth Edition, Project Management Institute Inc., 2017,
Page 150.]

The define scope process is what you use to arrive at a documented agreement about exactly
what a project will include. It involves documenting objectives, deliverables, and requirements in
enough detail to guide the rest of the project. The define scope process occurs early in the
project stages, after you've developed the project charter and collected requirements. But
before you create the WBS, or work breakdown structure, and perform processes related to
planning the schedule. It involves progressive elaboration. This means refining and expanding
on what you know so far from the information you've gathered and the work you've done on the
project.

The defined scope process has five inputs. The project charter provides a high-level description
of a project and of the product, service, or result it must deliver. It outlines basic requirements
and expectations, assumptions, constraints, and risks. Defining scope involves the elaborating
on what's in the project charter.

The project management plan, including the scope management plan, which provides guidance
on which processes should be used to define the detailed product and project scope.

Project documents including the assumption log, requirements documentation, and risk register.

Requirements documentation identifies requirements the project must meet to satisfy

expectations and their relative importance. Defining scope involves moving from these
requirements to more detailed ones that can guide all steps of a project.

Relevant enterprise environmental factors that may influence the project, and organizational
process assets. These can make the process of defining scope easier and more accurate. For
example, project files and lessons learned from previous projects may help you identify
important information about deliverables, risks, assumptions, and constraints that apply to your
current project. Policies, procedures, and templates for a scope statement can also influence
the define scope process.
So how do you go from what's in the project charter, project management plan, project
documents, organizational process assets, and enterprise environmental factors, to a
description of the project's scope? There are five main tools and techniques you use to do this,
expert judgment, data analysis, decision-making techniques, interpersonal and team skills, and
product analysis.

First, expert judgment. Defining product and project scope requires expert judgment, or
judgment based on specialized knowledge. That's because it involves assessing the
requirements as they are described in the inputs, such as the project charter and requirements
documentation, and determining the implications for the rest of a project. Defining scope
involves answering two main questions. What must a product or service's exact specifications
be to meet all requirements given constraints and assumptions? And what precisely must be
done to deliver this product or service according to those specifications? It takes specialized
knowledge to answer these questions. This knowledge can come from a variety of sources.
Sources of expert judgment you can draw on as a project manager might include your team
members, other units in the organization, and consultants you bring in. They might also be
stakeholders like the project sponsor or customers, professional and technical associations,
industry groups, or subject matter experts.

The data analysis technique you use is alternatives analysis. Alternatives analysis focuses on
coming up with alternative ways that work can be done to meet requirements. It involves
thinking creatively about different ways to meet the project deliverables. For instance, a group of
experts might evaluate alternative technologies or designs. They might also debate choices like
whether to make or buy particular components. Through investigation, the best alternatives are
identified.

The method of decision-making techniques you use is multi-criteria decision analysis. Multi-
criteria decision analysis involves a systematic approach using a matrix to determine the best
decision.

An important use of the defined scope process is to make sure all key stakeholders agree on
project and product scope. Using facilitation skills, you bring together cross-functional
stakeholders, people whose interests in a project differ, a workshop format. You guide the group
to think creatively, to come up with solutions, and then reach consensus. You could use this
technique to elaborate on what a product must be like, or what work a project must include to
meet requirements.

The fourth important tool in defining scope is product analysis. It's by analyzing a project's
deliverables that you determine exactly what attributes and features they must have, in other
words, the required product scope. Many different methods are useful for product analysis. Here
are some examples, product breakdown, systems analysis, systems engineering, value
engineering, value analysis, and requirements analysis.

Back to top
 Outputs of the Define Scope Process
Learning Objective

After completing this topic, you should be able to

 describe the purpose of a project scope statement

1.
[Topic title: Outputs of the Define Scope Process. Materials in this course are based on the text
A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Sixth Edition,
Project Management Institute, Inc., 2017. PMBOK, PMI, PMP, CAPM are registered trademarks
of the Project Management Institute, Inc.] Imagine a project is drawing to a close. The team has
designed a technically advanced tracking system. There's just one problem, the customer says
the system was meant to integrate with the company's existing tracking software. This is news
to the project team. Now the customer won't sign off on the project, and the deadline is already
at hand. Doesn't sound like much fun, does it? You can avoid this type of situation on your
projects if you're careful to get sign off on the scope by all parties at the beginning of the project.

The main output of the define scope process is the project scope statement. This is like an
official agreement among all of the project stakeholders. It explicitly identifies what will and what
won't be included in a project's deliverables.

The project scope statement has four main purposes. First of all, it defines the work that will go
into a project through progressive elaboration. This means it refines and expands on what the
team already knows from the project charter and requirements documentation. It's also what
feeds into the process of creating a detailed work breakdown structure where further
progressive elaboration occurs. The scope statement guides the project team and makes it
clear what will and won't go into a project. It describes the deliverables that must be created and
the work effort and methods required to do this. It also sets a baseline. The scope statement is
one of the documents against which progress and change requests will be evaluated. It forms
part of the scope baseline for a project. Finally, it sets stakeholders expectations. The project
scope statement makes it clear to stakeholders what they can expect to receive and what they
can't from a project. It's against these expectations that success will be measured.

Rita, a project manager is working on a project to create a new employee orientation program
for a pharmaceutical company. As per the project plan she delivers the first draft of a chapter for
the HR guide book to internal stakeholders for review. One stakeholder complains there is
missing content, the program hasn't covered the use of company property or security policies
for laptops that are removed from the premises. Rita checks to see if the missing topics were
included in the scope statement, they weren't. But Rita remembers that when she and the team
were collecting requirements, an agreement was reached to cover these topics in a separate
 training project. Rita calls the stakeholder on the phone to discuss the issue and work out the
misunderstanding.

So here's a question, what could Rita have done to prevent the misunderstanding?

She could have clearly identified any exclusions in the scope statement. The scope statement
should make it clear what a project won't deliver as well as what it will. If Rita had itemized the
topics that wouldn't be covered in the chapter based on earlier decisions, stakeholders wouldn't
expect to see this content in a draft. But how do you get to a list of scope exclusions? For
example, suppose you are creating a workplace health and safety manual, it's obvious the
scope statement can't possibly itemize all the content a manual won't contain. But it should
address the most important exclusions that could affect a stakeholders expectations. Identifying
important exclusions to include in the scope statement involves expert judgement. You should
probe stakeholders and draw on the specialized knowledge of experts. The goal is to identify
things that might reasonably be expected of deliverables but that don't actually fall within a
project's scope.

Consider a software development project. Say your company has been contracted to develop all
the artwork, programming, and video components for a new online game. An example of an
exclusion that you outline in the scope statement is that your company won't be handling audio
production for the game. This is a good example of a relevant exclusion, because audio
features are a typical element of an online game. All key stakeholders understand the rationale
for the exclusion and sign off on the scope statement. So now, when your deliverables go for
customer acceptance review, nobody will complain that there's no audio in your product.

The other output of the defined scope process is project documents updates. The process of
analyzing all the components that go into the scope statement can make it clear where new
requirements or changes to existing ones are necessary. Documents you may update are the
assumption log, requirements documentation, requirements traceability matrix, and stakeholder
register.

Back to top

Components of a Project Scope Statement

Learning Objective

After completing this topic, you should be able to

 distinguish between the components to include in a project scope statement

1.
[Topic title: Components of a Project Scope Statement. Materials in this course are based on
the text A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Sixth
Edition, Project Management Institute, Inc., 2017. PMBOK, PMI, PMP, CAPM are registered
trademarks of the Project Management Institute, Inc.] A project's scope statement should have
four main components. The project scope description, deliverables, project exclusions, and
acceptance criteria. Together, these ensure everyone involved knows what falls within the
project scope. They also form a basis for determining how to manage all remaining activities in
the project's life cycle.

The product scope description identifies all the attributes a deliverable must have to meet
requirements. For example, one of the attributes might be that a database management system
must be available 99.8% of the time. The product scope description is an important input for
later processes. For example, you use it during the create WBS process to guide the
development of a detailed work breakdown structure. You also use it as a baseline for later
quality assurance activities, like quality testing and scope validation.

A description of project deliverables is another important component. This makes it clear what
stakeholders should expect to receive throughout a project and when the project closes. For
example, deliverables might include documents for review at specified stages, completed
components, and an end product or service.

A third component of a scope statement is the definition of the project's exclusions. What do you
think is described in this section? The project exclusion section is where you identify what
deliverables won't include. In other words, scope exclusions. This ensures stakeholders know
and agree about what the project won't deliver.

Consider a project to create a new employee orientation program. One of the project's
deliverables is a self-paced training product that employees will be able to walk through in their
own time. In a scope statement, the project manager includes details about the training software
in the sections on the product scope description, project deliverables, and project exclusions. In
the product scope description section, the project manager notes that the training product must
provide 10 minutes of training on the pharmaceutical company's history and market position.
And 20 minutes on the clinical pharmacology of its main drug products. The training must
include 3D animations demonstrating how the drugs work and a minimum of ten test questions.
In the project deliverables section, the project manager specifies that draft versions of the
training content will be submitted for approval no later than May 10th. A version of the develop
training product will be ready for review by June 15th. And a fully developed and approved e-
learning training product will be delivered by June 30th. In the project exclusion section, the
project manager notes that the e-learning product won't cover company policies and guidelines,
which will be adequately covered in the new employee kit. It also won't include audio content, as
per agreement, due to resource and time constraints.

A project's scope statement should also include product acceptance criteria. These are the
standards stakeholders and the project team agree to use to judge whether the project's
deliverables have met requirements. The criteria play an important role at the close of a project
or any of its phases. They're used to verify scope and to confirm completion and acceptance of
deliverables. It's important to detail product acceptance criteria. Otherwise, it's possible that not
everyone will agree that a requirement has been met. Or even that a project is successfully
 completed. For example, a product may meet one set of standards for durability but not another.
If it isn't clear which standards must be used, the product could fail to satisfy some
stakeholders.

Back to top

Exercise: Planning and Defining Project Scope

Learning Objective

After completing this topic, you should be able to

 demonstrate your understanding of the Plan Scope Management, Collect Requirements, and
Define Scope processes

1. Exercise Overview
In this exercise, you'll demonstrate your understanding of how to help a project succeed by
aligning the project requirements and scope, and by creating a project scope statement that
sets the tone for the entire project and defines what should, and shouldn't, be included.

In this exercise, you'll demonstrate that you can

 identify the outputs of the Plan Scope Management process

 identify the inputs, tools and techniques, and outputs of the Collect Requirements process
 recognize examples of well-written requirements
 identify the role the tools and techniques of the Define Scope process play in developing a
scope statement
 describe the purpose of a project scope statement, and
 describe how the components of a project scope statement are used throughout a project

2.
Question

What is the definition of project scope?

Options:

1. The work required to define the features of a product

2. The planning done before a project to ensure it runs smoothly
3. The work done to verify that a project meets all its objectives
4. The total work required for a project's deliverables to meet all its objectives
Answer

Option 1: This is an incorrect option. The work required to define the features of the
product does not include the work required to produce it.

Option 2: This is an incorrect option. The planning before a project is a critical part of
defining and managing its scope, but there is much more involved in keeping to scope than
just initial planning.

Option 3: This is an incorrect option. Verification of work done is crucial to managing a

project but it doesn't define the project's scope.

Option 4: This is the correct option. Project scope entails all the work necessary to
complete the deliverables a project is intended to produce. Doing either more or less than
required can compromise a project.

Correct answer(s):

4. The total work required for a project's deliverables to meet all its objectives

Question

You are planning a software development project.

What types of information will your team members find in the scope management plan
relative to this project?

Options:

1. The scope statement will be developed during a meeting between the customer, the
user representative, and the lead programmer
2. The WBS will be created using project management software and updated daily as
required
3. Formal sign offs of product iterations will be obtained following monthly customer
reviews
4. The budget for the project will be developed by the project manager and approved by
the sponsor
5. Quality reviews of deliverables will be carried out weekly and bugs resolved within one
working day

Answer

Option 1: This is a correct option. This is an example of how the scope statement will be
developed.
 Option 2: This is a correct option. The scope management plan contains the process for
creating the WBS based on the scope statement, and how it will be approved and
maintained.

Option 3: This is a correct option. This is an example of how formal acceptance of project
deliverables will be obtained.

Option 4: This is an incorrect option. Budget and schedule information is found in the
overall project management plan but not in the scope management plan.

Option 5: This is an incorrect option. Information about quality reviews and bug fixing will
be found in the quality management plan.

Correct answer(s):

1. The scope statement will be developed during a meeting between the customer, the
user representative, and the lead programmer
2. The WBS will be created using project management software and updated daily as
required
3. Formal sign offs of product iterations will be obtained following monthly customer
reviews

Question

You are still working on the scope planning documents for the software development
project.

What types of project information will the requirements management plan contain?

Options:

1. How activities related to planning, tracking, and reporting the project requirements will
be performed
2. Archived and current versions of the code will be kept on a secure document storage
site
3. The customer will prioritize requirements in a planning meeting with members of the
development team
4. The metrics for evaluating the success of the project will be rate of return on
investment and customer satisfaction scores
5. Requests for changes to the project scope will be analyzed to determine impact and
then reviewed by the change management board

Answer
 Option 1: This is a correct option. The requirements management plan describes all
activities related to planning, tracking, and reporting the development of project
requirements.

Option 2: This is a correct option. Configuration management processes are included in

the requirements management plan.

Option 3: This is a correct option. The requirements management plan contains the
process that will be used for prioritizing requirements.

Option 4: This is an incorrect option. The metrics described in the requirements

management plan are those that will be used to evaluate the requirements, not project
success.

Option 5: This is an incorrect option. The process for handling changes to the product is
included in the requirements management plan but not changes to project scope in
general. That information is found in the scope management plan.

Correct answer(s):

1. How activities related to planning, tracking, and reporting the project requirements will
be performed
2. Archived and current versions of the code will be kept on a secure document storage
site
3. The customer will prioritize requirements in a planning meeting with members of the
development team

Question

What are some of the inputs to the Collect Requirements process?

Options:

1. Project charter
2. Project management plan
3. Project documents
4. Business documents
5. Agreements
6. Enterprise environmental factors
7. Organizational process assets
8. Requirements traceability matrix
9. Work breakdown structure

Answer
 Option 1: This is a correct option. The project charter is used for collecting requirements.

Option 2: This is a correct option. The project management plan is used as an input to the
Collect Requirements process.

Option 3: This is a correct option. Project documents such as an assumption log or

lessons learned register are used as inputs to the Collect Requirements process.

Option 4: This is a correct option. When collecting requirements, you use business
documents, such as a business case, as inputs to the process.

Option 5: This is a correct option. Agreements such as vendor or customer contracts are
useful inputs when collecting requirements.

Option 6: This is a correct option. Enterprise environmental factors, or EEFs, are one of
the various inputs to the collect requirements process.

Option 7: This is a correct option. Organizational process assets are an input you use
when collecting requirements.

Option 8: This is an incorrect option. The requirements traceability matrix is an output of –

not an input to – the collect requirements process.

Option 9: This is an incorrect option. A work breakdown structure is included as part of the
scope management plan and is not an input to the collect requirements process.

Correct answer(s):

1. Project charter
2. Project management plan
3. Project documents
4. Business documents
5. Agreements
6. Enterprise environmental factors
7. Organizational process assets

Question

What tools and techniques can you use to collect project requirements?

Options:

1. Decision making
2. Expert judgment
3. Context diagram
4. Data gathering, analysis, and representation
5. Prototypes
6. Project charter
7. Interpersonal and team skills
8. Scope management plan

Answer

Option 1: This is a correct option. In order to determine which requirements to include in a

project, you'll need to use effective decision-making techniques, such as voting or
multicriteria decision analysis.

Option 2: This is a correct option. You'll need input from industry and subject matter
experts to help you collect and understand project requirements.

Option 3: This is a correct option. A model of the inputs and outputs of a system, as well
as how people use it, can help you collect project requirements.

Option 4: This is a correct option. Various data gathering, analysis, and representation
methods are important in helping you compile project requirements.

Option 5: This is a correct option. An early working model of a product is a useful way of
letting stakeholders see how the product works and eliciting project requirements.

Option 6: This is an incorrect option. The project charter is one of the inputs to the Collect
Requirements process and provides high-level information. It is not a tool for determining
specific requirements.

Option 7: This is a correct option. To collect project requirements, you must effectively
observe, interview, or facilitate groups of stakeholders so as to elicit relevant information.

Option 8: This is an incorrect option. The scope management plan is not relevant when
collecting project requirements, as it is used to describe deliverable acceptance criteria and
how scope change requests will be handled.

Correct answer(s):

1. Decision making
2. Expert judgment
3. Context diagram
4. Data gathering, analysis, and representation
5. Prototypes
7. Interpersonal and team skills

Question
 You're leading a project to design and manufacture a new range of soft toys for children
aged three to six years.

What are the examples of appropriate requirements for the project?

Options:

1. Bright, attractive colors must be used

2. All materials must meet ISO 8124 flammability standards
3. No parts representing a possible choking hazard should be included
4. All toys must comply with the US Child Safety Protection Act rules for labels warning of
small parts

Answer

Option 1: This is an incorrect option. One person's interpretation of a bright, attractive

color may differ from another person's. So this isn't a requirement that's measurable or
testable or that could be traced throughout the project.

Option 2: This is a correct option. The requirement is measurable, can be tested, and is
traceable throughout a project. Materials either will or won't comply with the specified
standards.

Option 3: This is an incorrect option. The minimum size of parts isn't specified. It's also not
clear if this refers only to outer parts or also to the stuffing materials used for the toys. As a
result, the requirement isn't measurable, testable, or traceable.

Option 4: This is a correct option. This requirement can be measured, tested, and traced
because it identifies the exact standards the toys must meet.

Correct answer(s):

2. All materials must meet ISO 8124 flammability standards

4. All toys must comply with the US Child Safety Protection Act rules for labels warning of
small parts

Question

What characteristics should the requirements documentation have?

Options:

1. It should list requirements by stakeholder and priority

2. It should list the current status of each requirement
3. It should indicate how each requirement helps meet a broader objective
4. It should explain assumptions and constraints for each requirement
5. It should list initial project requirements that must still be refined

Answer

Option 1: This is a correct option. Requirements documentation should identify project

requirements and where they come from, by stakeholder or stakeholder category. They
should also identify the relative importance of each requirement.

Option 2: This is an incorrect option. Requirements documentation identifies project

requirements before you start planning how to meet them or working to do this. So these
documents don't need to record status changes.

Option 3: This is a correct option. Requirements documentation should explain how each
requirement meets a business need or a broader project objective. This helps ensure
everyone knows why the requirements are there.

Option 4: This is a correct option. It's important for the requirements documentation to
identify any agreed upon limitations to a requirement being met.

Option 5: This is an incorrect option. Requirements documentation should list final

requirements that are already measurable, testable, and traceable. These might be
modified as work proceeds but they form the baseline for monitoring and controlling a
project.

Correct answer(s):

1. It should list requirements by stakeholder and priority

3. It should indicate how each requirement helps meet a broader objective
4. It should explain assumptions and constraints for each requirement

Question

What are the characteristics of a requirements traceability matrix?

Options:

1. It enables you to track requirements throughout a project

2. It relates requirements to the scope of the project and to actual product development
3. It identifies each requirement using a unique identifier
4. It describes configuration management activities
5. It lists requirements by stakeholder and priority
6. It identifies the current status of each requirement

Answer
 Option 1: This is a correct option. The requirements traceability matrix is a table that
identifies each product and customer requirement and its status throughout a project.

Option 2: This is a correct option. The requirements traceability matrix maps each
requirement to the scope of a project and to the work that must be done to design, develop,
and test a product. It does this by mapping user requirements to specific functional
requirements.

Option 3: This is a correct option. The requirements traceability matrix uses the unique
identifier assigned to each requirement in the requirements documentation.

Option 4: This is an incorrect option. The requirements management plan is what

describes configuration management activities. The requirements traceability matrix is a
tool you use to implement what's in the plan so that changes to requirements are tracked
and managed properly.

Option 5: This is an incorrect option. It's the requirements documentation that lists
requirements by stakeholder and priority. However, a requirements traceability matrix might
reference this information.

Option 6: This is a correct option. One of the main purposes of a requirements traceability
matrix is to let the project team track the status of each requirement so it's clear what
progress is being made towards meeting it.

Correct answer(s):

1. It enables you to track requirements throughout a project

2. It relates requirements to the scope of the project and to actual product development
3. It identifies each requirement using a unique identifier
6. It identifies the current status of each requirement

Question

What tools and techniques can be used when defining a project's scope?

Options:

1. Asking a project sponsor to assess requirements documentation

2. Identifying alternative methods for attaining project requirements
3. Using multicriteria decision analysis
4. Facilitating groups of stakeholders so that they agree on project scope
5. Carrying out a systems analysis
6. Evaluating a lessons learned register
7. Assessing an assumptions log
Answer

Option 1: This is a correct option. Using expert judgment, like that of a project sponsor,
can help define a project's scope.

Option 2: This is a correct option. Alternatives analysis is a data analysis technique that
can enable you to discover alternative technologies, designs, or approaches that will more
effectively meet project deliverables.

Option 3: This is a correct option. Multicriteria decision analysis is a decision-making

technique that uses a matrix to determine the best decision.

Option 4: This is a correct option. A key technique in defining project scope is using
interpersonal and team skills to guide groups to think creatively about possible solutions
and to reach a consensus.

Option 5: This is a correct option. A systems analysis is one of the product analysis
techniques that are typically used to determine a project's scope.

Option 6: This is an incorrect option. While a lessons learned register may be used as an
input, it is not one of the tools and techniques for deciding on project scope.

Option 7: This is an incorrect option. An assumptions log is an example of an

organizational process asset that is typically used as an input to the Define Scope process.
But tools and techniques must then be applied to determine the actual scope of a project.

Correct answer(s):

1. Asking a project sponsor to assess requirements documentation

2. Identifying alternative methods for attaining project requirements
3. Using multicriteria decision analysis
4. Facilitating groups of stakeholders so that they agree on project scope
5. Carrying out a systems analysis

Question

What purposes does the project scope statement serve?

Options:

1. It defines and progressively elaborates on the work of the project

2. It breaks required project work into manageable components
3. It guides the work of the project team
4. It provides a baseline for evaluating whether requests for changes or additional work
are within or outside the project's boundaries
5. It identifies exactly how a project must be managed
6. It sets the expectations of stakeholders

Answer

Option 1: This is a correct option. The scope statement refines and expands on what the
project charter and requirements documentation contain. It outlines what work a project
should and won't include to meet requirements.

Option 2: This is an incorrect option. Required work is broken down into manageable
components when a work breakdown structure is developed. This occurs after you create a
scope statement, which guides the process.

Option 3: This is a correct option. The scope statement identifies what deliverables the
team must produce and the work and methods they'll use to do this.

Option 4: This is a correct option. The scope statement is one of the documents against
which project progress and change requests will be evaluated. It identifies which product
features and work fall within the project's scope and what falls outside this scope.

Option 5: This is an incorrect option. It's the project management plan that identifies how a
project will be managed. The scope statement is one of the inputs for the plan.

Option 6: This is a correct option. All key stakeholders should sign off on the scope
statement. This ensures they know what to expect and what not to expect from a project's
deliverables.

Correct answer(s):

1. It defines and progressively elaborates on the work of the project

3. It guides the work of the project team
4. It provides a baseline for evaluating whether requests for changes or additional work
are within or outside the project's boundaries
6. It sets the expectations of stakeholders

Question

Match each component of a project scope statement to the role it plays in project
management.

Options:

A. Product scope description

B. Deliverables
C. Project exclusions
D. Acceptance criteria

Targets:

1. Guides the development of a work breakdown structure and provides a baseline for
quality testing
2. Sets stakeholder expectations about what a project will deliver
3. Sets stakeholder expectations about what a project won't deliver
4. Set agreed upon standards for judging the success of a project

Answer

The product scope description identifies all the features and functions that deliverables
must have. This guides decisions about how to break down the work involved and provides
a basis for quality testing.

A description of project deliverables makes it clear what stakeholders can expect to receive
throughout a project.

A description of project exclusions makes it clear what the project won't deliver.

Product acceptance criteria are the standards stakeholders and the team agree to use to
determine if deliverables meet requirements.

Correct answer(s):

Target 1 = Option A

Target 2 = Option B

Target 3 = Option C

Target 4 = Option D

Back to top

© 2022 Skillsoft Ireland Limited