Chapter 5

Managing the Project Scope

CERTIFICATION OBJECTIVES

5.01   Planning Project Scope Management

5.02   Collecting and Eliciting Project Requirements

5.03   Defining the Project Scope

5.04   Creating the Work Breakdown Structure

5.05   Validating the Project Scope

5.06   Controlling the Project Scope

Two-Minute Drill

Q&A    Self Test

Have you ever set out to clean your garage and ended up cleaning your attic? It usually starts by needing to move the car out of the garage so you can really dig in and clean. As you move your car, you realize the car could really use a cleaning, too.

So you clean out the car. You dust it down, clean the windows inside and out, and vacuum out pennies, old pens, and some green French fries. The vacuum, you discover, has something caught in the hose, so you have to fight to clear the blockage to finish cleaning out the car. Once the inside’s spick-and-span, you think, “Might as well wash and wax the car, too.”

This calls for the garden hose. The garden hose, you notice, is leaking water at the spigot by the house. Now you’ve got to replace the connector. This calls for a pair of channel-lock pliers. You run to the hardware store, get the pliers—and some new car wax. After fixing the garden hose, you finally wash and wax the car.

As you’re putting on the second coat of wax, you see a few scratches on the car that could use some buffing. You have a great electric buffer but can’t recall where it is. Maybe it’s in the attic? You check the attic only to realize how messy things are there, too. So, you begin moving out old boxes of clothes, baby toys, and more interesting stuff.

Before you know it, the garage is full of boxes you’ve brought down from the attic. The attic is somewhat cleaner, but the garage is messier than when you started this morning. As you admire the mess, you realize it’s starting to rain on your freshly waxed car, the garden hose is tangled across the lawn, and there are so many boxes in the garage you can’t pull the car in out of the rain.

So what does this have to do with project management? Plenty! Project management requires concentration, organization, and a laser-like focus. In this chapter, we’ll be covering project scope management, the ability to get the required work done—and only the required work—to complete the project. We’ll look at how a project manager should create and follow a plan to complete the required work to satisfy the scope without wandering off or embellishing on the project deliverables.

Exploring Project Scope Management

Two types of scopes are involved in project management: the project scope and the product scope. The product scope includes all the details and specifications of the result of the project for the recipients of the project: the user, the customer, and the organization. The project scope describes all the work required to create the product scope. In some instances, the product scope and the project scope are melded together into one project scope, while in other projects, these are two distinct scopes. Your exam may include a question or two about the concept of product scope, but the overwhelming concern of this book, and project management, is the project scope.

The approach that you take with your project has a direct effect on how you’ll manage the project scope. In a predictive life cycle, the deliverables are all defined up front before the project execution begins. In an adaptive or agile life cycle, the project scope and deliverables are defined through iterations of planning and executing. The elements of the project scope in an agile environment are agreed upon at the launch of each iteration.

Predictive life cycles have a reputation for wanting all requirements and deliverables defined early in the project, and then the project tends to be somewhat rigid and against changes to the project scope. An agile environment is practically the opposite: change is expected, welcome, and part of the overall project management approach. Predictive life cycles protect the project scope and requirements from change, whereas agile and adaptive life cycles define and prioritize requirements in a backlog and determine how many requirements the team can create in the current iteration.

Tailoring Project Scope Management

The project scope is based largely on the requirements, which are typically gathered before the project is initiated. Requirements gathering has long been the responsibility of a business analyst, though project managers may take on this role. Requirements gathering can also be part of the organization’s portfolio planning or program planning, or even set up as a separate project. Requirements elicitation, technically and from the PMBOK Guide point of view, takes place within the project scope management knowledge area.

Your organization may utilize the business analyst approach, and that’s fine; but for your exam, you should know that stakeholder requirements elicitation and documentation will fall under project scope management. As the project manager, you may work with a business analyst or take on the role of business analyst to do the following:

   Define business needs and/or problems the project will address.

   Recommend solutions for the business needs and/or problems identified.

   Perform requirement elicitation and document the stakeholder requirements.

   Lead the project to implement the solutions.

   Close out the requirements by transitioning the solution to the project stakeholders.

Of course, when appropriate, the project manager and the business analyst work together to identify problems and solutions, elicit requirements, and document the requirements the project must satisfy. There should not be an antagonistic relationship between the project manager and the business analyst. By clearly identifying roles and responsibilities, having open communications, and working in a spirit of collaboration, the project manager and business analyst should have no problems working together on the requirements gathering activities.

Each project and organization is unique, and this uniqueness allows for the tailoring of the scope management processes. Consider the following key project management processes and how they could be tailored for a project and an organization:

   Knowledge and requirements management Knowledge and requirements management systems may be in play to help organize, document, and communicate the requirements. The knowledge and management systems may also help the project manager and the business analyst access requirements from previous projects and apply them to the current endeavor.

   Scope validation and scope control Each organization can have unique scope validation and scope control processes that supersede the information I’ll share in this chapter about these processes.

   Development approaches An organization may use an agile, adaptive, or predictive approach to manage its projects. In addition, the life cycle could be incremental or iterative, depending on what the project is creating and the preferences of the organization. Some organizations could even create a hybrid approach for their projects.

   Requirements stability Loosely defined requirements can hinder a predictive approach, but they may work well in an agile or adaptive approach to project management. Unstable requirements mean the requirements could evolve and change as the project moves forward.

   Governance Each organization can have its own governance to implement its rules, policies, and procedures. The project must operate within the governance boundaries to be successful in the organization.

A big consideration in this project management knowledge is the difference between the predictive and the agile and adaptive environments. While the predictive environment is keen on defining and documenting all requirements upfront in a project, agile and adaptive environments are not. Adaptive and agile projects release prototypes of the solution to allow requirements to move through requirements refinement. Requirements in an agile environment are added and prioritized in a backlog. At the start of each iteration, the requirements are prioritized, and the team decides how many of the prioritized requirements can be delivered in the iteration.

CERTIFICATION OBJECTIVE 5.01

Planning Project Scope Management

This first process in project scope management is to create the scope management plan, which defines how the project scope will be defined, the techniques you and the project team will use to validate the scope, and what approach is in place or will be created to control changes to the scope. Project scope management has several purposes:

   It defines what work is needed to complete the project objectives.

   It determines what is included in the project.

   It serves as a guide to determine what work is not needed to complete the project objectives.

   It serves as a point of reference for what is not included in the project.

   It defines how the scope will be controlled.

   It communicates how scope validation will occur in the project.

So what is a project scope statement? A project scope statement is a description of the work required to deliver the product of a project along with the assumptions and constraints that may affect the work of building the project scope. The project scope statement defines what work will, and will not, be included in the project work. A project scope guides the project manager on decisions to add, change, or remove work in the project.

Project Scope vs. Product Scope

Project scope and product scope are different entities.

A project scope deals with the work required to create the project deliverables. For instance, a project to create a new barn would focus only on the work required to complete the barn with the specific attributes, features, and characteristics called for by the project plan. The project scope is specific to the work required to complete the project objectives.

Product scope, on the other hand, is the attributes and characteristics of the deliverables the project is creating. For the barn project, the product scope would specifically define the features and attributes of the barn: the materials to be used, the dimensions of the different rooms and stalls, the expected weight the hayloft should carry, electrical requirements, and more. The project scope would not include features of a flower garden, a wading pool, or a fence.

The project scope and the product scope are bound to each other. Throughout the project execution, the work is measured against the project plan to verify that the project is on track to fulfill the project scope. The product scope is measured against requirements, while the project scope is measured against the project plan.

Creating the Scope Management Plan

Planning the project scope involves progressive elaboration. The project scope begins broad and through refinement becomes focused on the required work to create the product of the project. The project manager and the project team must examine the product scope—what the customer expects the project to create—to plan on how to achieve that goal. Based on the project requirements documentation, the project scope can be created.

In order to build the scope management plan fully, you’ll rely on four inputs:

   Project charter The project purpose and high-level objectives

   Project management plan The quality management plan, the project life cycle description, and a definition of the project development approach

   Enterprise environmental factors The organization’s culture, infrastructure, personnel administration, and marketplace conditions

   Organizational process assets The organization’s policies, procedures, historical information, and lessons learned from past projects

Using Scope Planning Tools and Techniques

The goal of scope planning is to create the scope management plan and the requirements management plan. The project manager and the project team must have a full understanding of the project requirements, the business need of the project, and stakeholder expectations to be successful in creating the scope statement and the scope management plan. Recall that there are two types of scope:

   Product scope Features and functions of the product of the project

   Project scope The work needed to create the product of the project

The project manager and the project team can rely on three tools and techniques to plan the project scope:

   Expert judgment Use someone more knowledgeable than the project team, the project manager, and even the key stakeholders to guide the scope planning process. Expert judgment can come from experts within the organization or outside, such as consultants.

   Data analysis The project manager can rely on data analysis, such as alternatives analysis. Data analysis also reviews the options for collecting and refining requirements, creating the product scope, scope validation options, and scope control.

   Meetings The planning meetings’ approach is really part of the organization’s culture and will likely include the project sponsor, project team members, key stakeholders, and other experts. Consider, for example, what work is like for a project manager in a bank versus a project manager in a small, entrepreneurial company. The culture of both entities differs regarding how a project is initiated, planned, and then managed. Of course, the project charter, the requirements documentation, and organizational process assets will guide the scope planning process as well.

Creating the Scope Management Plan

The scope management plan explains how the project scope will be managed and how scope changes will be factored into the project plan. Based on the conditions of the project, the project work, and the confidence of the exactness of the project scope, the scope management plan should also define the likelihood of changes to the scope, how often the scope may change, and how much the scope can change. The scope management plan also details the process of how changes to the project scope will be documented and classified throughout the project life cycle. Every scope management plan should define four processes:

   The process to create the project scope statement

   The process to create the work breakdown structure (WBS) based on the project scope statement—and the methods for maintaining the WBS integrity and the process for WBS approval

   The process for formal acceptance of the project deliverables by the project customer

   The process for evaluating and approving or declining scope change requests

The process of creating the scope management plan also includes creating the requirements management plan, which defines how you and the project team will collect, document, and protect the project requirements. The requirements management plan defines configuration management for the product and the tracking approach you’ll utilize in this project. This plan also defines how requirements may be prioritized, any metrics for requirements measurements, and the requirements traceability matrix. The requirements management plan maps out how requirements will be tracked, reported, and prioritized. The requirements management plan can also define the configuration management activities, such as product changes, reporting requirements, and authorization levels for changes to the product.

The requirements management plan defines how requirements will be managed throughout the phases of the project. This plan also defines how any changes to the requirements will be allowed, documented, and tracked through project execution. You’ll also need to prioritize the project requirements and define what metrics will be used to measure requirement completion and acceptability.

CERTIFICATION OBJECTIVE 5.02

Collecting and Eliciting Requirements

Projects don’t exist without stakeholders. Sure, sure, sometimes they are a pain in the neck, but if it weren’t for them, there would be no reason to have projects—or project managers. Stakeholders and project managers need to work together as a team; the stakeholders know what they want as the result of your work, and the project manager and the project team can make that result a reality. The project manager’s role, often along with a business analyst, is to elicit requirements from the stakeholders to create the best possible solution to satisfy the needs of the stakeholders and the organization, and to ensure the longevity of the solution.

The goal, whether the project manager or a business analyst is leading the work, is the same: Find detailed specifications about exactly what the stakeholders want and expect from the project. Once the requirements have been identified—clearly identified—the project manager and team can work toward specific results. Though loose, open-ended, foggy requirements waste time, money, and effort in a predictive project life cycle, such requirements are more likely in an agile environment.

You’ll be gathering broad categories of requirements:

   Business requirements These define why the project has been initiated and what are the high-level expectations for the project.

   Stakeholder requirements These are the individual stakeholder and stakeholder group requirements for the project.

   Solution requirements These describe the features, function, and characteristics of the project deliverable. Solution requirements are more fully described by two sub-requirement categories:

   Functional requirements These describe how the solution will work, what the solution will manage, and all the capabilities the solution will provide for the stakeholder. It’s how your project deliverable will operate.

   Nonfunctional requirements These describe the conditions within which the functional requirements must operate. You might hear this also described as the quality requirements or environmental requirements, where the solution will operate at its ideal level or performance. You can recognize nonfunctional requirements when stakeholders talk about speed, capacity, security, user interfaces, or production.

   Transition and readiness requirements These requirements describe the needed elements to move from the current state to the desired future state—for example, training requirements or dual-supporting systems.

   Project requirements The project may have requirements in the way it is managed, specific processes that are to be followed, and other objectives that the project manager is obligated to meet.

   Quality requirements Any condition, metric, performance objective, or condition the project must meet to be considered of quality. These should be measurable and not ambiguous goals.

The project charter may rely on a current state assessment and compare it to the desired future state assessment. This is basically a project before-and-after—your project deliverables create the future state. Other charters simply define the high-level goals of the project, and then it’s up to you, your project team, and any other experts to figure out how to make it happen.

You’ll also rely on project documents, such as the assumptions log and the lessons learned register. A key project document is the stakeholder registry to confirm that you’re communicating, interviewing, and eliciting requirements from all the stakeholders. Recall that some stakeholders won’t want your project to succeed at all—those nasty, negative stakeholders. Just because they despise the project doesn’t mean you get to ignore them. You’ll need to work with both positive and negative stakeholders during requirements gathering and throughout the project. Expert judgement is a tool and technique you’ll use to begin eliciting requirements, and this will include stakeholders and experts in your discipline.

Interview the Stakeholders

One of the most reliable data-gathering techniques is interviewing, which is a conversation between you and the project stakeholders about their needs, wants, and demands for the project. It’s a learning process for you to absorb information from the project customer by asking them questions. You need and want the interviewees to talk to you, so you’ve got to ask questions. Let me rephrase that: You need to ask good questions.

The interviewer should go into the interview armed with some questions that allow the stakeholder to ramble a bit and other questions that allow the stakeholder to be precise about the project deliverables. You probably aren’t going to ask the stakeholder how to create the deliverable, but you’ll likely ask how they’ll be using the product that you’ll be creating. You want to see how they’ll be using the deliverable as part of their day-to-day lives. This is where you’ll categorize the requirements as functional or nonfunctional.

Interviews are usually done one-on-one, but there’s no reason why a project manager can’t have several interviewers participating in the session. As a rule, however, the more people who participate in the interview, the more complex the elicitation process becomes. Smaller groups allow for a more conversational tone to the meeting. Sometimes, however, the project manager will need a subject matter expert to help the conversation along.

Leading a Focus Group

Focus groups provide an opportunity for a group of stakeholders to interact with a moderator about the requirements of the project, the current state of an organization, or how they’ll see the project deliverables affecting the organization once the project is completed. Like an interviewer, the moderator is armed with questions, but he should be well versed on the topic to branch into new contributing discussions on the project requirements.

An ideal focus group has six to twelve people in one room, and the moderator should encourage open, conversational discussion. The moderator, often not the project manager, should be neutral to the project, have the ability to draw people into the conversation, and keep the session on track to the goals of the project. A scribe or recorder should document the discussion in the session so the project manager and team can review the results of the meeting and act accordingly.

Relying on Surveys

Surveys are a fine approach to eliciting requirements from a large group of stakeholders in a relatively short amount of time. The challenge with surveys, however, is that they must be responded to and tabulated, and the survey questions must be well written to generate accurate responses. When the general requirements are known, closed-ended questions are ideal, but you should restrict the type of information the respondent may provide. Open-ended questions allow the respondent to write essays about a topic, but it takes more time to tabulate the responses.

Survey writers need to determine the best type of questions, and they must consider the audience of the survey. You’ll also want to consider how quickly you’d like respondents to complete the survey and how you’ll collect and tabulate the results. Obviously, electronic surveys are ideal, as you can quickly sort the data, create charts, and track who has responded.

Leveraging Data Analysis

One of the best data analysis tools to use in requirements gathering is document analysis. You, the team, and any experts will review all the project documentation and information. You’ll identify requirements through the documentation and identify information and specifics about the requirements. While your project may have tons of documentation, here are some good examples of documents for data analysis:

   Agreements and contracts

   Business plans

   Business process documentation

   Business rules repositories

   Process flow information for the organization

   Marketing information

   Problems and issues logs from the current and past projects

   Regulatory documentation

   Request for proposal (if one exists)

   Use cases

Making Group Decisions on Requirements

Rarely are all the requirements for a project clearly defined when the project launches. There are probably some cases, such as in manufacturing or construction, in which certain types of projects are repeated over and over, and theses projects may be based on the same initial set of requirements, but usually the requirements for each project vary wildly, because each project is unique. When you’re managing a large project, you need to work with groups of stakeholders to elicit their requirements for the project deliverables.

Sometimes stakeholders have a general idea of what they’d like you to create, but they aren’t certain. Consider market opportunities, problems that need to be solved, and implementations of new materials, software, or organization-wide changes. The requirements in these instances can go in multiple directions and demand a good plan and uniformity to create a successful project and useable deliverable.

When multiple solutions exist for a project, or the stakeholders aren’t entirely certain what the exact project requirements should be, group creativity techniques can be useful. These techniques help the key stakeholders generate ideas, solutions, and requirements for the project. Here are some examples you should know for your PMP exam:

   Brainstorming The group of participants brainstorms about a topic and throws out as many ideas as possible to generate solutions and requirements.

   Nominal group technique Like brainstorming, this approach generates ideas, but the ideas are voted on by the stakeholders and ranked based on usefulness. There are four steps to implementing the nominal group technique:

1.   Each participant brainstorms the problem or opportunity with her ideas.

2.   The facilitator writes all ideas from each person on a white board.

3.   Each idea is discussed for clarity and understanding.

4.   The participants privately vote on each idea from a low score of 1 to a high score of 5. Rounds of voting and discussion can take place to reach a consensus on the highest scoring ideas.

   Mind mapping Mind maps link ideas, thoughts, requirements, and objectives to one another. You might use mind maps after a brainstorming or nominal group technique to organize possible solutions and requirements, and to show where differences exist between the stakeholders (see Figure 5-1).

FIGURE 5-1 Mind maps visualize project requirements while they’re being created.

   Affinity diagram This group creativity technique is often used for solutions. It groups ideas into clusters, each of which can be broken down again to analyze each subset. It’s basically a decomposition and organization of project ideas and requirements.

   Multicriteria decision analysis This approach relies on a systematic approach of determining, ranking, and eliminating project criteria such as performance metrics, risks, requirements, and other project elements. These approaches use a table called a “decision matrix” to measure and score these project elements.

   Delphi Technique This approach uses rounds of anonymous surveys to foster consensus. Each round of surveys is based on answers from the past round so each participant can freely and anonymously comment on others’ thoughts and inputs about the project requirements. The idea is that the comments will lead the group toward the most appropriate answer without the political attachment that may occur if the process were not anonymous.

If you’re wondering why it’s called the Delphi Technique, it’s named after the Oracle at Delphi—the most important oracle from Greek mythology. The technique was first used in 1944 at the start of the Cold War to predict how technology may affect warfare.

Using Group Decisions

When many project stakeholders have loads of different competing objectives about the project deliverables, it’s sometimes best for the project manager to hand the decision back to the project stakeholders. This approach generally allows the majority to vote on the project direction, but it doesn’t always garner goodwill, cohesion, or buy-in from all the project stakeholders. You should be familiar with four different models of group decisions:

   Unanimity All the stakeholders agree on the project requirements (and then rainbows appear, the sun shines, and bluebirds sing).

   Majority This is probably the most common group decision, in which a vote is offered and the majority wins.

   Plurality Like a majority rule, this approach allows the biggest section of a group to win, even if a majority doesn’t exist. You might experience this when there are three possible solutions for the project and the stakeholders vote their opinion for each solution in uneven thirds of 25 percent, 35 percent, and 40 percent. The group that represents the 40 percent would win, even though more people (60 percent) are opposed to the solution.

   Autocratic The project manager, project sponsor, or the person with the most power forces the decision, even though the rest of the group may oppose the decision. No warm, fuzzy feelings here.

Hosting a Requirements Workshop

Let’s face facts: Sometimes stakeholders have agendas. And by sometimes, I mean they always do. When you’re managing a project with stakeholders from across the organization, you’ll be dealing with different departments, different functions, and different lines of business. The stakeholders from each of these groups may have different expectations and requirements for the project, and these expectations will often clash. A requirements workshop, sometimes called a facilitated workshop, aims to find commonality, consensus, and cohesion among the stakeholders for the project requirements.

If you’re in software development work, you’ve probably participated in a joint application design (JAD) workshop. These strive to gather all the requirements and to create a well-rounded, balanced application for all the stakeholders. In manufacturing, project managers use a requirements workshop, sometimes called the voice of the customer (VOC), where the voice of the customer dictates what the project will create. You might also know VOC as quality function deployment (QFD). The idea is that quality is achieved by giving the customer exactly what they expect.

Your workshop might create user stories; these are short narratives about what the solution should provide and how the deliverables will work for the end users or customers. User stories follow a role-goal-motivation sequence. For example, it describes the stakeholder role, what they are trying to accomplish as their goal, and how the requirement equates to a benefit to the stakeholder.

Utilizing a Context Diagram

Imagine that your project is to install, configure, and roll out an organization-wide e-mail and calendaring server. A context diagram would illustrate all the components that would interact with your server. It would show the other computers on the network; the network itself; other servers, routers, and switches; and other hardware. Then the context diagram would show the people who interact with the server and their different roles, such as administrators, users, and support personal. These things and people that interact with the server are called actors in the context diagram.

Creating Prototypes

Have you ever seen a model of a skyscraper, or what about a mockup for a new web site, application, or even a brochure? These are prototypes that allow the stakeholder to see how the result is going to function. Prototypes help the project manager confirm that she understands the requirements the stakeholder expects from the deliverable. Some prototypes are considered throw-away, and they don’t really work beyond communicating the idea of the deliverable. Others are considered functional or working prototypes and evolve into the final deliverable of the project.

A common prototype is a storyboard to show the flow of the interaction, activities, or information in a business system. Though you might be familiar with the idea of the Hollywood movie storyboard, the storyboard in project management helps to uncover the requirements the project needs for all the steps to be taken in the workflow. For example, a storyboard could show the flow of activities a customer could take to search a web-based catalogue, add an item to the shopping cart, set the shipping preferences, and then pay for the product. The storyboard could continue with the payment being processed, a confirmation page and e-mail, and order fulfillment from the warehouse all the way to the customer’s address.

Observing Stakeholders

When it comes to learning a new skill, one of the best pieces of advice out there is this: It’s easier to watch someone peel a banana than it is to describe how to peel a banana. This is true in requirements gathering, too—by observing someone do his work, you can see the processes, approaches, and challenges of his work more clearly than by just hearing about his work. Observing stakeholders is an excellent way to gather requirements, especially when your project is likely to affect their day-to-day work life, processes, and methods of operation in your organization.

As an observer, you can shadow a person and watch how he does his work. You might complete the shadowing as a passive or invisible observer. In this role, you work quietly, stay out of the way, and take notes on the processes you see. As an active or visible observer, you’re stopping the person doing the work, asking loads of questions, and seeking to understand how the person is completing his work.

Benchmarking the Requirements

Benchmarking is an approach you can use throughout the project. Benchmarking compares two similar things to see which is performing better. For example, you might compare software packages, organizations, or different pieces of equipment. Benchmarking, in requirements collections, enables you to compare the requirements for your project against organizations that have completed similar work to see how their projects and products performed to help you better define what’s needed in your project.

Managing the Requirements

The goal of eliciting the project requirements is to identify clearly and manage the requirements so the project scope can be created and the in-depth project planning can begin. It’s ever so important for the project manager, the project team, and the key project stakeholders to be in agreement with the intent, direction, and requirements of the project before the project scope is created.

You should be familiar with two outputs of the process to collect project requirements:

   Requirements documentation The clearly defined requirements must be measurable, complete, accurate, and approved by the project stakeholders. The requirements documentation may start broadly and, through progressive elaboration, become more distinct, but the identification and agreement of what is required and demanded of the project is paramount. This includes definitions of the functional and nonfunctional requirements, acceptance criteria, documentation of the impact of the deliverable on the organization, and any assumptions or constraints that have been identified.

   Requirements traceability matrix (RTM) A requirements traceability matrix will track each requirement from its first entry, through executing, all the way into the operational transfer. When you’re managing loads of requirements, an RTM can help you track several characteristics for each requirement:

   Requirement name

   Requirement’s link to the business and project objectives

   Project scope and WBS entry

   Any relevant data, coding, cost, or schedule about a requirement

   Requirement’s current status as active, cancelled, deferred, added, approved, assigned, or completed

   Testing activities for each requirement

   Comments or notes about the requirement

An RTM can help you ensure that every requirement in the project has been created to specification. This will help in quality control processes and in scope validation later in the project. Figure 5-2 shows an example of an RTM.

FIGURE 5-2 An RTM can track elements and delivery of requirements.

CERTIFICATION OBJECTIVE 5.03

Defining the Project Scope

The process of scope definition is all about defining the project and product scope. It creates the project scope statement that fully communicates what the project will, and will not, create as a result of the project work. The project scope statement is a clear vision of what the result of the project will create. If you wanted to create a new house, you probably wouldn’t stop by the lumberyard; pick up a truck of lumber, some cement, and nails; and set about building your dream house. You’d follow a logical approach: you’d first define the house and would then go about planning and creating the house.

The same is true with project management. Your organization and stakeholders may have a general idea of where the project should end up, but a detailed, fully developed plan is needed to get you there. Scope definition is the process of breaking down the broad vision for the project into logical components to reach its completion.

Examining the Inputs to Scope Definition

You should be very familiar with the inputs to scope definition; you’ve seen these several times already in the book. The following is a quick refresher of each input and its role in this process:

   The project charter The project charter authorizes the project and the project manager and provides a high-level view of the project, the product, and the requirements for approval.

   Project management plan The project management plan includes the scope management plan, which defines the approach for creating the project scope statement.

   Project documents The project documents can be useful in creating the project scope statement. The assumption log, requirements documentation, and risk register are needed for this process.

   Requirements documentation The project scope is founded on the requirements documentation, as this is what’s expected of the project.

   Enterprise environmental factors Consideration of the enterprise environmental factors, such as the organization’s culture, infrastructure, personnel administration, and the marketplace conditions, can contribute to the creation of the project scope statement.

   Organizational process assets The formal and informal guidelines, policies, and procedures that influence how a project scope is managed, and lessons learned from past projects, can help define the scope statement.

You’ll rely on the project’s scope management plan, because it defines how the scope will be defined, managed, and controlled. Once your project is in motion, you can also expect change requests to influence the definition of your project scope.

Consulting with Experts

Throughout the PMBOK Guide you’ll see references to “expert judgment.” It should come as no surprise that developing the project scope also includes this tool and technique. The experts for the project scope are the stakeholders, customers, users, and consultants to the project work. For a project to be successful, the project manager and the project team must know what the stakeholders of the project expect. This means communication must occur between the project manager and the stakeholders. Business analysts may be involved or may even facilitate the process of scope definition, but the result is the same: the expectations of the project stakeholders must be identified, documented, and then prioritized.

This is also the time to define what constitutes project success. Unquantifiable metrics, such as customer satisfaction, “good,” and “fast,” don’t cut it. The project manager and the stakeholders must agree on metrics that indicate a project’s success or failure. These are the key performance indicators (KPIs) that projects are often measured against.

Finding Alternatives

Project managers, project team members, and stakeholders must resist the temptation to fall in love with a solution too quickly. Alternative identification is any method of creating alternative solutions to the project’s needs. This is typically accomplished through brainstorming and lateral thinking. Lateral thinking challenges assumptions, shifts perception, and uses creativity to find better solutions.

Facilitating Meetings and Workshops

A tool and technique that the project manager may utilize to create the project scope statement is facilitation. Good meeting management techniques, workshop leadership, and facilitating conversations are all needed during the creation of the project scope statement. Because you’ll likely be working with stakeholders with differing backgrounds, differing understanding of the project work, and differing goals for the project, facilitation is a valuable interpersonal skill for the project manager.

Using Product Analysis

Product analysis is, as the name implies, the process of analyzing the product the project will create. Specifically, it involves understanding all facets of the product, its purpose, how it works, and its characteristics. Product analysis can be accomplished through one or more of the following:

   Product breakdown Breaks down the product into components, examining each component individually and to determine how it may work with other parts of the product. This approach can be used in chemical engineering, for example, to see how a pharmaceutical product is created and how effective it is.

   Systems engineering Focuses on satisfying the customers’ needs, cost requirements, and quality demands through the design and creation of the product. An entire science is devoted to systems engineering in various industries.

   Value engineering Deals with reducing costs and increasing profits, all while improving quality. Its focus is on solving problems, realizing opportunities, and maintaining quality improvement. Value engineering is also concerned with the customers’ perception of the value of the different aspects of the product versus the project’s cost to create the product’s features and functions.

   Value analysis Similar to value engineering, focuses on the cost/quality ratio of the product. For example, your expected level of quality of a $100,000 automobile versus a $6700 used car is likely relevant to the cost of each. Value analysis focuses on the expected quality against the acceptable cost.

Examining the Project Scope Statement

The project scope statement, an output of scope planning, clearly defines the project and product scope of the project, major deliverables, assumptions, and constraints. It is the guide for all future project decisions when it comes to change management. It is the key document to provide understanding of the project purpose. The scope statement provides justification for the project’s existence, lists the high-level deliverables, and quantifies the project objectives. The scope statement is a powerful document that the project manager and the project team will use as a point of reference for potential changes, added work, and any project decisions.

The scope statement includes or references the following:

   Product scope description Recall that the product scope description defines the characteristics and features of the thing or service the project is aiming to create. In most projects, the product scope will be vague early in the scope planning process, and then more details will become available as the product scope is progressively elaborated.

   Project deliverables The high-level deliverables of the project should be identified. These deliverables, when predefined metrics are met, signal that the project scope has been completed. When appropriate, the scope statement should also list what deliverables are excluded from the project deliverables. For example, a project to create a new food product may state that the packaging of the food product is not included as part of the project. Items and features not listed as part of the project deliverables should be assumed to be excluded.

   Product acceptance criteria The scope statement defines the requirements for acceptance. Product acceptance criteria establish what exactly qualifies a project’s product as a success or failure.

   Project exclusions Every project has boundaries. The scope statement defines the boundaries of the project by defining what’s included and what’s excluded in the project scope. For example, a project to create a piece of software may include the created compilation of a master software image but exclude the packaging and delivery of the software to each workstation within an organization. The project scope must clearly state what will be excluded from the project so there’s no ambiguity as to what the stakeholders will receive as part of the product.

Obviously, the project scope statement is a hefty document that aims to create the confines of the project and the expectations of the project manager, the project team, and the project customers. It defines what’s in and what’s out of the project scope. Overall, the project scope statement sets the tone of the project expectations and paints a picture of what the project will create and how long and how much it’ll take to get there.

During the scope statement creation, the project manager may also face, believe it or not, change requests from the project stakeholders. Change requests are managed through the integrated change control process, which basically means that any proposed change is reviewed and its impact on all areas of the project are considered. If a change is approved, the scope statement should be updated to reflect the approved change.

Reviewing the Project Document Updates

When you create the project scope statement, several project documents may need to be updated:

   Assumption log Any new assumptions are added to the log.

   Requirement documentation The scope statement creation can result in new requirements to be identified and documented.

   Requirements traceability matrix The matrix is populated with the requirements, and the project manager and team begin tracking the requirements in the project.

   Stakeholder register Ideally, stakeholders are identified early in the project, but the project scope creation could uncover new stakeholders for the project.

CERTIFICATION OBJECTIVE 5.04

Creating the Work Breakdown Structure

As you hopefully know by now, the WBS is a deliverables-oriented collection of project components. It is a breakdown of the project work into smaller components. Work that doesn’t fit into the WBS does not fit within the project. The point of the WBS is to organize and define the project scope. As you can see in Figure 5-3, each level of the WBS becomes more detailed.

FIGURE 5-3 A sample structure for a technology project

The WBS is not a list of activities or a chart of the activities required to complete the work—it is a visual representation of the high-level deliverables divided up into manageable components. The smallest element in the WBS is called the work package. The components in the WBS are typically mapped against a code of accounts, which is a tool to number and identify the elements within the WBS. For example, a project manager and a stakeholder could reference work package 7.3.2.1, and both would be able to find the exact element in the WBS.

The components in the WBS should be included in a WBS dictionary, a reference tool to explain the WBS components, the nature of the work package, the assigned resources, and the time and billing estimates for each element. The WBS dictionary includes the following:

   Code of account identifier

   Description of each work package

   Related assumptions and constraints

   Related milestones

   Activities linked to each WBS dictionary entry

   Responsible party for each entry

   Needed resources, time, and costs

   Quality metrics

   References for technical specifications

   Acceptance criteria for each element

   Cost estimates

   Agreement information

The WBS also identifies the relationship between work packages. Finally, the WBS should be updated to reflect changes to the project scope. The following are some essential elements you must know about the WBS:

   It serves as a major component of the project scope baseline.

   It’s one of the most important project management tools.

   It serves as the foundation for planning, estimating, and project control.

   It visualizes the entire project.

   Work not included in the WBS is not part of the project.

   It builds team consensus and project buy-in.

   It serves as a control mechanism to keep the project on track.

   It allows for accurate cost and schedule estimates.

   It serves as a deterrent to scope change.

Using a Work Breakdown Structure Template

One of the tools you can use in scope definition is a WBS template. A WBS breaks down work into a deliverables-orientated collection of manageable pieces (see Figure 5-4). It is not a list of activities necessary to complete the project. A WBS template uses a similar project’s WBS as a guide for the current work. This approach is recommended, since most projects in an organization are similar in their project life cycles—and the approach can be adapted to fit a given project.

FIGURE 5-4 This section of the WBS has been expanded to provide more detail.

Depending on the organization and its structure, an entity may have a common WBS template that all projects follow. The WBS template may have common activities included in the form, a common lexicon for the project in the organization, and a standard approach to the level of detail required for the project type.

Decomposing the Project Deliverables

Decomposition is the process of breaking down the major project deliverables into smaller, more manageable components. So what’s a manageable component? It’s a unit of the project deliverable that can be assigned resources, measured, executed, and controlled. So how do you decompose the project deliverables? It’s done this way:

1.   Identify the major deliverables of the project, including the project management activities. A logical approach includes identifying the phases of the project life cycle or the major deliverables of the project.

2.   Determine whether adequate cost and time estimates can be applied to the lowest level of the decomposed work. What is adequate is subjective to the demands of the project work. Deliverables that won’t be realized until later portions of the project may be difficult to decompose, since many variables exist between now and when the deliverable is created. The smallest component of the WBS is the work package. A simple heuristic of decomposition is the 8/80 rule: no work package smaller than 8 hours and none larger than 80 hours.

3.   Identify the deliverable’s constituent components. This is a fancy way of asking whether the project deliverable can be measured at this point of decomposition. For example, the decomposition of a user manual may have the constituent components of assembling the book, confirming that the book is complete, shrink-wrapping the book, and shipping it to the customer. Each component of the work can be measured and may take varying amounts of time to complete, but it all must be done to complete the requirement.

4.   Verify the decomposition. The lower-level items must be evaluated to ensure they are complete and accurate. Each item within the decomposition must be clearly defined and deliverable-orientated. Finally, each item should be decomposed to the point that it can be scheduled, budgeted, and assigned to a resource.

5.   Other approaches include breaking it out by geography or functional area, or even breaking the work down by in-house and contracted work.

There are many approaches to creating the WBS. You can arrange the WBS by the project life cycle, by elements of the product scope, or even by simply identifying the major deliverables of the project. Whatever approach you select, you should identify all deliverables in the WBS. Some deliverables, however, may not be clear at the start of the project, and a marker can be added to the WBS signifying more information will be coming later—that marker is called a planning package.

Planning packages are often part of a control account. A control account is a control point within the WBS to track scope, costs, and schedule for a portion of the project deliverables. For example, you’re constructing a home and you have allotted $125,000 of your budget for the kitchen deliverable. That’s $125,000 for everything in the kitchen deliverable: lights, cabinets, plumbing, appliances, and so on. The control account is like a budget and schedule for the scope portion of the kitchen. The items to be determined within the kitchen, such as what appliances will be installed, are planning packages. You don’t have to know on the first day of the project what cabinets will be installed, but there is a deadline for the cabinets to be selected to finish the project on time. Control accounts track schedule, costs, and scope for a portion of the project.

Defining the Scope Baseline

Traditionally, the scope baseline is made up of three documents: the project scope statement, the WBS, and the WBS dictionary. Technically, however, there are a few more elements that go into the scope baseline. Here’s everything that’s considered to be part of the scope baseline:

   Project scope statement

   WBS

   Work packages

   Planning packages

   WBS dictionary

When a change enters the project scope, you’ll likely have to update these items, with the assumption that the change will affect the planning packages. The scope baseline must be in balance with the schedule and costs for the project.

CERTIFICATION OBJECTIVE 5.05

Validating the Scope

Imagine a project to create a full-color, slick catalog for an electronics manufacturer. The project manager has completed the initiation processes and moved through planning, and now the team is executing the project work. The only trouble is that the project manager and the experts on the project team aren’t sharing their work progress with the customer. Plus, the work they’re completing isn’t in alignment with the product description or the customer’s requirements.

The project team has created a trendy 1950s-style catalog with funky green and orange colors, lots of beehive hairdo models, horn-rimmed glasses, and tongue-in-cheek jokes about “the future” of electronics. The manufacturer wants to demonstrate a professional, accessible, current look for its publications. What do you think will happen if the project manager presents the catalog with his spin rather than following the request of the customer?

Scope validation is the process of the project customer accepting the project deliverables. Scope validation occurs at the end of each project phase or as major deliverables are created. Scope validation ensures that the deliverables the project creates are in alignment with the project scope. It is concerned with the acceptance of the work. A related activity, quality control, is concerned with the correctness of the work. Scope validation and quality control work together, as the quality of the work contributes to scope validation. Poor quality processes will typically result in scope validation failure. In the catalog example, working closely with the customer throughout the project, not just at the end, will save time, prevent frustration, and help the project team better understand what the customer wants—and that’ll make the project more successful, save time, and money.

You’ll be doing some scope validation when you pass the PMP examination. Your project is to pass the exam, and once you do, you’ll have verified that you’ve completed your project scope. Study smart, work hard, and keep after it. If you’ve made it this far, you can go just a bit farther. You can do it!

Should a project get cancelled before it has completed the scope, scope validation is measured against the deliverables up to the point of the project’s cancellation. In other words, scope validation measures the completeness of the work up to cancellation, not the work that was to be completed after project termination.

Examining the Inputs to Scope Validation

To validate the project scope, which is accomplished through inspection, there must be something to inspect—namely, work results. The work results are compared against the project plan to check for their completeness and against the quality control measure to check the correctness of the work.

One of the biggest inputs of scope validation is the requirements documentation you created as part of the collect requirements process. This information describes the requirements and expectations of the product, its features, and its attributes. The product documentation may go by many different names, depending on the industry:

   Plans

   Specifications

   Technical documentation

   Drawings

   Blueprints

The project manager will also rely on the project management plan, the scope baseline, and the traceability matrix to help compare what was promised to the customer and what was created. Work performance data such as nonconformance, degree of accuracy, and other performance metrics are also needed to see how well the deliverable conforms to the criteria for acceptance by the project customer.

Inspecting the Project Work

To complete scope validation, the work must be inspected. This may require measuring, examining, and testing the product to prove it meets customer requirements. Inspection usually involves the project manager and the customer inspecting the project work for validation, which in turn results in acceptance. Depending on the industry, inspections may also be known as the following:

   Reviews

   Product reviews

   Audits

   Walkthroughs

Formally Accepting the Project Deliverables

Assuming the scope has been validated, the customer accepts the deliverable. This is a formal process that requires signed documentation of the acceptance by the sponsor or customer. Scope validation can also happen at the end of each project phase or at major deliverables within the project. In these instances, scope validation may be conditional, based on the work results. When the scope is not validated, the project may undergo one of several actions: it may be cancelled and deemed a failure, sent through corrective actions, or put on hold while a decision is made based on the project or phase results.

Scope validation creates work performance information about the project, scope validation, customer feedback, and status of deliverables that have, or have not, been accepted. When the deliverables are not accepted, you may need to issue a change request for defect repair. This change request will follow the project integration management approach. When the defect has been corrected and passed through quality control, it may then move back to scope validation for acceptance by the customer.

CERTIFICATION OBJECTIVE 5.06

Controlling the Scope

When it comes to project management, the one constant thing is change. Changes happen, or try to happen, all the time in projects. The project manager must have a reliable system to track, monitor, manage, and review changes to the project scope. Scope control focuses on three things:

   It facilitates scope changes to determine that changes are agreed upon.

   It determines whether a scope change has happened.

   It manages the scope changes when, and if, they happen.

Examining the Inputs to Scope Control

Throughout a project’s life, the need and desire for change will come from project team members, the sponsor, management, customers, and other stakeholders. These change requests must be coupled with supporting evidence to determine the need of the change, the change’s impact on the project scope (and usually on other processes as well), and the required planning, schedule, and budget to account for the changes.

See the video “Change Control.”

Using the Project Management Plan

The project management plan does offer some specific direction on how changes are allowed into the project. Although most project managers are resistant to changes in the project once the scope has been created and agreed upon, changes are sometimes valid. You’ll rely on the change management plan as a general direction of the flow of decisions to determine whether a change is valid for your project. This assumes, of course, that you, the project manager, have control over change management decisions.

You’ll also rely on the configuration management plan to determine how change is allowed specifically to the product scope. Configuration management is the control and documentation of the features and functions of the project’s product. It’s important for you to communicate the impact of change on the product to all the stakeholders as part of the change control review.

A project document that you’ll reference in scope control is the performance measurement baseline. The results of earned value management, which I’ll discuss in Chapter 7, are compared against what was planned to show how well the project is performing overall. This information can help determine whether corrective or preventive actions or a scope change is required to rectify problems within the project.

Finally, you’ll rely on your favorite project management tool, the scope baseline. The scope baseline represents the sum of the components and ultimately the project work that makes up the project scope. The change requests may be for additional components in the project deliverables, changes to product attributes, or changes to different procedures to create the product. The WBS and WBS dictionary are referenced to determine which work packages would be affected by the change and which may be added or removed because of the change.

Relying on the Scope Management Plan

Remember this plan mentioned earlier in the chapter? It’s an output of scope planning and controls how the project scope can be changed. The scope management plan also defines the likelihood of the scope to change, how often the scope may change, and how much it may change. You don’t have to be a mind reader to determine how often the project scope may change and by how much; you just must rely on your level of confidence in the scope, the variables within the project, and the conditions under which the project must operate. The scope management plan also details the process of how changes to the project scope will be documented and classified throughout the project life cycle.

Referencing the Requirements Management Plan and Documentation

The requirements management plan, the requirements traceability matrix, and the actual requirements documentation are inputs to the control scope process. The requirements management plan defines how changes to the requirements are allowed and how they’re to be managed. The actual requirements documentation is also needed, because it contains the specific elements that the scope change may be affecting. You’ll use the requirements traceability matrix to see how a change in the requirements may directly affect other requirements in the project.

Considering the Change Management Plan

Some project managers despise change requests. Change requests can mean additional work, adjustments to the project, or a reduction in scope. They mean additional planning for the project manager and time for consideration, and they can be seen as a distraction from the project execution and control. Change requests can address preventive actions, corrective actions, defect repair, or scope enhancements. Change requests are an expected part of project management.

Why do change requests happen? Which ones are most likely to be approved? Most change requests are a result of the following:

   Value-added events The change will reduce costs (often due to technological advances since the time the project scope was created).

   External events These could be things such as new laws or industry requirements.

   Errors or omissions Ever hear this one: “Oops! We forgot to include this feature in the product description and WBS!” Errors and omissions can happen both to the project scope (the work to complete the project) and the product scope and typically constitute an overlooked feature or requirement.

   Risk response A risk has been identified and changes to the scope are needed to mitigate the risk.

Considering the Results of Controlling Scope

Work performance information is an output of the control scope process. Work performance data is an input to scope change control; the contents of work performance data—the actual measurements of the project—are evaluated to determine what the needed changes may be, which will be an output of control scope as work performance information. The information is not meant to expose variances as much as it’s meant to drive root-cause analyses of the variances. Project variances happen for a reason: the correct actions required to eliminate the variances may require changes to the project scope.

There is a distinct difference between work performance information and performance measurement, as shown in Table 5-1.

TABLE 5-1 Performance Reports vs. Performance Measurement

Creating More Change Requests

It sounds funny, but it’s not: controlling scope can create more change requests. More change requests will mean more planning, and you know that planning is iterative. As change requests are presented, evidence of change exists, or corrective actions are needed within the project, the project manager and the project team will need to revisit the integrated change control process. Change within the project may require alternative identification, study of the change impact, analysis of risks introduced by the change, and solutions to problems within the project execution. Changes made as part of this planning could cause the project plan, WBS, and baselines to be revised.

Often, the reasons for change include faulty deliverables, quality problems, or poor performance of the project deliverables. Corrective actions are activities that will make an effort to bring the project back in line with the project plan. Errors and omissions in the product specifications are scope changes, not corrective action changes.

Updating the Project Management Plan

Changes to the project management plan will also go through the project’s integrated change control process. This includes changes to the scope management, scope baseline, schedule baseline, cost baseline, and the performance measurement baseline. The change management plan within the project management plan and governance will determine how significant of a change to the project management plan will require a change request and the formal change control.

When changes to the project scope have been approved, the documented project scope must be updated to reflect these new changes. The stakeholders affected by the scope changes must be notified. The WBS must also be updated to reflect the components added or removed from the project. Scope changes can include cost updates, schedule updates, quality updates, or changes to the project deliverables.

When the project scope is to be changed, the new requirements must pass through the planning processes. The changes must be evaluated for cost and schedule estimates, risk, work considerations, product specification, and technical specification.

Updating Project Documents

The lessons-learned documentation should be updated as an output of scope change control. The project manager should document reasons why changes were approved, corrective actions were taken, and components were added or removed from the scope, and she should also document the reasoning behind these decisions. Lessons learned will serve as future historical information to help guide other project managers.

When changes are made, the project baselines will need to be adjusted to reflect these changes. Such changes can affect cost, schedule, and scope. The changes that affect the appropriate baseline should be updated to reflect the new project scope. The new baselines serve as a point of reference for the remainder of the project (assuming there are no additional changes). Should other changes occur, the baseline should be updated, enabling the project to continue. Scope changes will cause the requirements documentation and the requirements traceability matrix to be updated to reflect the new set of project requirements.

CERTIFICATION SUMMARY

Projects exist to satisfy the project requirements. Project requirements are discovered through interviews, focus groups, workshops, and other elicitation techniques to help the stakeholders and the project team clearly understand what the project should create. The requirements documentation, the requirements management plan, and a requirements traceability matrix all help the project stay focused on expected deliverables and serve as input to the project scope. A business analyst may lead the requirements collection process along with a project manager, or even before the project manager is selected and the project initiated.

Project scope management is the ability to complete all the project’s required work—and only the required work. This means no extras, no favors, and no cutting corners. The project scope is the focus of the project—or rather, the work necessary to complete the project. Project scope management is a tool the project manager uses to determine what work is necessary in the project and what work is extraneous.

Projects big or small fit within the confines of the performing operation’s strategic plans. Projects don’t meander, at least not often, outside of the business focus of the organization. You won’t find too many car manufacturers creating projects to make chocolate pies. Projects fit within the vision and function of the organization within which they operate.

Determining the project scope takes plenty of scope planning. The project manager and the project team must have a clear vision of the project, the business need for the project, the requirements, and the stakeholder expectations for the project. The result of the scope planning processes is the scope statement. The scope statement says, in no uncertain terms, what is included in the project and what is excluded.

For your PMP exam, focus on protecting the project scope. This includes finding the real purpose of the project so the scope is in alignment with identified needs. Once the scope has been created, the project team, the stakeholders, the project sponsor, and even the project manager should not change the scope—unless there is overwhelming evidence of why the scope needs to be changed.

KEY TERMS

To pass the PMP exam, you’ll need to memorize these terms and their definitions. For maximum value, create your own flashcards based on these definitions and review them daily. The definitions can be found within this chapter and in the glossary.

affinity diagram   Clusters similar ideas together and allows for decomposition of ideas to compare and contrast project requirements.

brainstorming   People generating as many ideas a possible and then analyzing the ideas.

business analyst   Organizational role that is responsible for eliciting requirements from stakeholders and analyzing the requirements to predict feasibility, likelihood of project success, and estimated time and costs to create the requirements.

business requirements   Why the project has been initiated and what the high-level expectations are for the project deliverables and performance.

context diagram   A diagram that illustrates all of the components, called “actors,” that interact with a project’s solutions, such as systems, software, hardware, and people.

decomposition   The process of breaking down the major project deliverables into smaller, manageable components. The smallest item of the project’s decomposition into the WBS is called the “work package.”

Delphi Technique   A consensus-building group creativity technique that uses rounds of anonymous surveys during requirements elicitation. The Delphi Technique may also be used during risk assessment.

facilitated workshop   A collection of stakeholders from throughout the organization who come together to analyze, discuss, and determine the project requirements.

focus group   A conversation of stakeholders led by a moderator to elicit project requirements.

interview   Formal, direct discussion used in project integration management as part of the data gathering technique to create the project charter.

majority decision   A group decision process by which a vote is offered and the majority wins.

mind mapping   A visual representation of like and opposing ideas, thoughts, and project requirements.

multicriteria decision analysis   An approach that relies on a systematic method of determining, ranking, and eliminating project criteria such as performance metrics, risks, requirements, and other project elements.

nominal group technique   A group creativity technique that follows the brainstorming model but scores each brainstorm idea.

observation   A requirements elicitation process whereby an observer shadows a person to understand how the person completes a process. An observer may be a participant observer or an invisible observer.

plurality decision   A group decision process approach that allows the biggest section of a group to win even if a majority doesn’t exist.

product scope   The attributes and characteristics of the deliverables the project is creating.

project scope statement   The definition of what the project will create for the project stakeholders. It includes the product scope description, product acceptance criteria, project deliverables, project exclusions, project assumptions, and project constraints.

prototype   A mockup of the project deliverable to confirm, adapt, or develop the project requirements.

quality requirements   Any condition, metric, performance objective, or condition the project must meet in order to be considered of quality.

requirements documentation   A clearly defined explanation of the project requirements. The requirements must be measurable, complete, accurate, and approved by the project stakeholders.

requirements management plan   Defines how requirements will be managed throughout the phases of the project. This plan also defines how any changes to the requirements will be allowed, documented, and tracked through project execution.

requirements traceability matrix   A table that helps the project team identify the characteristics and delivery of each requirement in the project scope.

scope baseline   Comprises the project scope statement, the work breakdown structure, and the WBS dictionary.

scope management plan   Explains how the project scope will be managed and how scope changes will be factored into the project plan. Based on the conditions of the project, the project work, and the confidence of the project scope, the scope management plan should also define the likelihood of changes to the scope, how often the scope may change, and how much the scope can change.

scope validation   An inspection-driven process led by the project customer to determine the exactness of the project deliverables. Scope validation is a process that leads to customer acceptance of the project deliverables.

stakeholder requirements   The individual stakeholder and stakeholder group requirements for the project.

systems engineering   Focuses on satisfying the customers’ needs, cost requirements, and quality demands through the design and creation of the product. An entire science is devoted to systems engineering in various industries.

unanimity decision   A group decision process whereby all participants are in agreement.

value analysis   Like value engineering, this focuses on the cost/quality ratio of the product. Value analysis focuses on the expected quality against the acceptable cost.

value engineering   Deals with reducing costs and increasing profits, all while improving quality. Its focus is on solving problems, realizing opportunities, and maintaining quality improvement.

voice of the customer   The initial collection of customer requirements that serves as part of quality function deployment in a facilitated workshop.

work breakdown structure   A decomposition of the project scope statement into work packages. The WBS is an input to seven project management processes: developing the project management plan, defining the project activities, estimating the project costs, determining the project budget, planning the project quality, identifying the project risks, and planning the project procurement needs.

work breakdown structure dictionary   A companion to the WBS, this document defines all of the characteristics of each element of the WBS.

work breakdown structure templates   Based on historical information, this is a WBS from a past project that has been adapted to the current project.

TWO-MINUTE DRILL

Planning Project Scope Management

   The scope management plan communicates how the project scope will be managed and how scope changes will be allowed. It defines how the scope statement is created, how the WBS is created, the scope validation process, and the project’s change control system.

   All change requests should be written and entered into the project’s change control system. Changes to the project scope may affect all the project’s knowledge areas: schedule, cost, quality, resources, communication, risk, procurement, and stakeholder management. The knowledge area of project integration management evaluates the project change and its impact on the entire project.

   Scope management is the process that follows the scope management plan. It ensures that the scope includes all the required work—and only the required work—to complete the project. It documents how changes may enter the scope and how frequently the scope is expected to change.

Collecting and Eliciting Project Requirements

   Collecting the project requirements is the process of eliciting the requirements from the project stakeholders so that the project manager and the project team may create the project deliverables. The project manager, the project team, and/or a business analyst elicit requirements from the stakeholders.

   Eight tools and techniques can be used to collect requirements: expert judgment, data gathering, data analysis, decision-making, data representation, interpersonal and team skills, context diagrams, and prototypes.

   A requirements traceability matrix is a table that maps all the project requirements; their characteristics, related data, and expected delivery dates; and any comments or notes about each requirement. The RTM helps the project manager, the project team, and the stakeholders confirm that all the requirements have been included in the project and have been created as expected.

Defining the Project Scope

   Progressive elaboration is the process of allowing the project scope to start broad, and then, through iterations of analysis, development, and refinement, making the project scope more specific.

   The project scope builds the product scope. If the project scope contains work that’s not needed, the product scope has changed from what the project customer is expecting. The product scope and the project scope support each other.

   Projects move through product-oriented processes to create the project’s product. These processes are typically marked by phases unique to the project work—for example, foundation, framing, roofing, finishing, and so on. Project management processes are the activities universal to all projects.

   There are two scopes: the project scope and the product scope. The project scope is the work to be completed to create the product. The product scope describes the features of the product and its characteristics.

   Project scope definition is concerned with what the project will include for the project stakeholders, but it’s also concerned with what won’t be included in the project. By establishing and communicating boundaries for the project, the project manager and the project team can focus on creating the agreed-upon project requirements.

Creating the Work Breakdown Structure

   The WBS is a deliverables-oriented decomposition of the project scope. It is not the activity list, but the predecessor to creating the activity list. The WBS reflects, in detail, the elements and components that contribute to the project scope.

   The smallest item in the WBS is called the “work package.” The work package should follow the 8/80 rule, which means it should not take fewer than 8 hours and no more than 80 hours of labor to create the work package item. (Don’t worry; this is just a heuristic. There may be small items that you want to account for in your WBS that don’t follow this guideline.)

   A WBS dictionary is a reference tool that explains the WBS components, the nature of the work package, the assigned resources, and the schedule and billing estimates for each element. The WBS also identifies the relationship between work packages.

Validating the Project Scope

   At the end of the project or project phase—or even at major deliverables within the project—scope validation happens. Scope validation is the process of formally accepting the project work as defined in the product documentation, in the project scope, or in the contractual agreement, if relevant. Formal acceptance requires sign-off for acceptance of the product.

   Scope validation involves two techniques: decision and inspection. It’s completed by the project stakeholders to determine whether the project has delivered on its promises. The goal of scope validation is for the project customer to sign off on the project deliverables.

Controlling the Project Scope

   By accurately defining the project scope, communicating how the scope will be managed, and then working with project stakeholders to control changes to the scope, the schedule and cost objectives are easier to maintain.

   Should a change occur to the project scope, configuration management must be enacted. Configuration management documents and controls changes to the features and function of the project’s product. Configuration management strives for consistency between the project scope and the product scope.

   “Scope creep” is a loose term used to describe the small, seemingly innocent but unapproved changes the project team may allow into the project execution that can rob the project of time and costs. Scope creep can also be known as project poison.

SELF TEST

1.   You are the project manager of the OQH Project and are working with the project stakeholders to determine the project requirements. You and the stakeholders are brainstorming privately to come up with as many solutions to the project as possible. After the brainstorming session, a recorder documents all the solutions on a white board so everyone can see the ideas and how they may be related. After the solutions have been documented, you lead the group through a voting process to discuss and rank each idea and requirement that has been proposed. What is this requirements gathering technique called?

A.   Brainstorming

B.   Nominal group technique

C.   Affinity diagram creations

D.   Mind mapping

2.   You are the project manager for the HGD Project and will need as many inputs to the scope planning as possible. Mary, your project assistant, recommends that you use some of the organizational process assets to help with your project scope planning. Of the following, which one is not an organizational process asset?

A.   Organizational procedures

B.   Organizational policies

C.   WBS

D.   Historical information

3.   You are a project manager for your organization. In your role as the lead project manager, you are required to cross-train and coach your project team members. Sarah, a project manager in training, wants to know which project documents can stem from templates? What should be your answer?

A.   Risk policies

B.   Organizational policies

C.   Scope management plans

D.   Historical information

4.   You are the project manager for a technical project. The project product is the complete installation of a new operating system on 4500 workstations. You have, in your project cost and schedule estimates, told the customer that the estimates provided will be accurate if the workstations meet the hardware requirements of the new operating system. This is an example of which of the following?

A.   Risk

B.   Assumption

C.   Constraint

D.   Order of magnitude

5.   You are the project manager for the NBG Project. The project is to develop new software that is supported on mobile devices. The project customer has defined a maximum budget, performance metrics, and other quality metrics for the project deliverable to be acceptable. One requirement of the project is that it must be completed within six months; this is an example of which of the following?

A.   Schedule

B.   Assumption

C.   Constraint

D.   Planning process

6.   As a PMP candidate, you must be familiar with the project management terms. Sometimes the terms seem confusing, such as project scope statement, scope baseline, or even the scope control process. Which of the following best describes the project scope statement?

A.   The description of the project deliverables

B.   The authorizing document that allows the project manager to move forward with the project and to assign resources to the tasks

C.   A document that defines all the required work—and only the required work—to create the project’s deliverables

D.   The process of planning and executing all the required work to deliver the project to the customer

7.   During the planning phase of your project, your project team has discovered another method to complete a portion of the project scope. This method is safer for the project team, but it may cost more for the customer. This is an example of which of the following?

A.   Risk assessment

B.   Alternative identification

C.   Alternative selection

D.   Product analysis

8.   You are the project manager of a large software development project. Hundreds of requirements need to be documented, annotated, and communicated to the project stakeholders. Management would also like you to report when the requirements should be created and when they’re actually created by the project team. What document can help you monitor all the characteristics of each requirement?

A.   Project management plan

B.   Configuration management plan

C.   Requirements traceability matrix

D.   Communications management plan

9.   You are the project manager for the JHN Project. Mike, a project manager you are mentoring, does not know which plan he should reference for guarding the project scope. Which plan does Mike need?

A.   The scope management plan

B.   The scope change control system

C.   The scope validation

D.   The scope charter

10.   You are the project manager for the JKL Project. This project has more than 45 key stakeholders and will span the globe when implemented. Management has deemed that the project’s completion should not cost more than $34 million. This is an example of which of the following?

A.   Internationalization

B.   Budget constraint

C.   Management constraint

D.   Hard logic

11.   You are the project manager for your organization. Your project is to construct a new house for a client. You and the client have agreed to meet at the end of each phase of the project to walk through the house as it’s being built to confirm the quality and accuracy of the build. You need to ensure that the customer formally accepts the deliverables of each project phase. This process is known as _______________.

A.   Earned value management

B.   Scope validation

C.   Quality control

D.   Quality assurance

12.   It’s important to know what each project management process creates. For example, which of the following is an output of scope validation?

A.   WBS template

B.   Rework

C.   Formal acceptance

D.   SOW acceptance

13.   Where can the project manager find work package information such as the code of an account identifier, a statement of work, information on the responsible organization, quality requirements, and information on the required resources? Choose the best answer.

A.   Execution plan

B.   WBS

C.   WBS dictionary

D.   Project management plan

14.   You are a project manager for a large manufacturer. Your current project is to create a new manufacturing assembly line that will enable your organization to create its products with less downtime and faster turnaround time for its clients. A stakeholder has presented a change request for your project, which will likely increase the cost and time needed to complete the project. All the following components are not part of the change control system except for which one?

A.   Adding more team members to the project to get the project work done faster

B.   Outsourcing portions of the project execution to transfer risk

C.   Creating tracking systems for the proposed change

D.   Documenting the project and how the manufacturing assembly should work

15.   A project team member has, on his own initiative, added extra vents to an attic to increase air circulation. The project plan did not call for these extra vents, but the team member decided they were needed based on the geographic location of the house. The project team’s experts concur with this decision. This is an example of which of the following?

A.   Cost control

B.   Ineffective change control

C.   Self-led teams

D.   Value-added change

16.   Which of the following is an output of scope control?

A.   Workarounds

B.   Recommended corrective action

C.   Transference

D.   Risk assessment

17.   You are the project manager for the JHG Project. Your project is to create a new product for your industry. You have recently learned that your competitor is also working on a similar project, but their offering will include a computer-aided program and web-based tools, which your project does not offer. You have implemented a change request to update your project. This is an example of which of the following?

A.   A change due to an error or omission in the initiation phase

B.   A change due to an external event

C.   A change due to an error or omission in the planning phase

D.   A change due to a legal issue

18.   You are the project manager for a pharmaceutical company. A new government regulation will change your project scope. For the project to move forward and be in accordance with the new regulation, what should be your next action?

A.   Prepare a new baseline to reflect the government changes.

B.   Notify management.

C.   Present the change to the CCB.

D.   Create a feasibility study.

19.   Your project is to document all the computer systems in your company. Your project team was required to document the operating systems, the hardware, the network configuration, and the software on each computer. You have finished the project scope according to plan. For the customer to accept the project, what must happen next?

A.   Nothing. The plan is complete, so the project is complete.

B.   Scope validation should be conducted.

C.   Lessons learned should be finalized.

D.   Proof-of-concept should be implemented.

20.   You are the project manager for an airplane manufacturer. Your project concerns the development of lighter, stronger material for commercial jets. As the project moves toward completion, different material composition is considered for the deliverable. This is an example of which of the following?

A.   Program management

B.   Alternatives identification

C.   Quality assurance

D.   Regulatory guidelines

21.   You are the project manager of a large project. Your project sponsor and management have approved your outsourcing portions of the project plan. The _______________ must document project scope management decisions.

A.   Project sponsor

B.   Organization’s management

C.   Vendor(s)

D.   Project management team

22.   A project team member has asked you what project scope management is. Which of the following is a characteristic of project scope management?

A.   It defines the baseline for project acceptance.

B.   It defines the requirements for each project within the organization.

C.   It defines the processes to ensure that the project includes all the work required—and only the work required—to complete the project successfully.

D.   It defines the functional managers assigned to the project.

23.   One of the stakeholders of the project you are working with asks why you consider the scope statement so important in your project management methodology. You answer her question with which of the following?

A.   It is mandatory to consult the plan before authorizing any change.

B.   Project managers must document any changes before approving or declining them.

C.   The project scope statement serves as a reference for all change requests to determine if the change is in or out of scope.

D.   The project plan and EVM work together to assess the risk involved with proposed changes.

24.   The project scope statement is decomposed into the work breakdown structure. The WBS then becomes an important part of the project for planning, execution, and control. A WBS serves as an input to many of the project processes. Of the following, which is not true?

A.   WBS serves as an input to activity sequencing.

B.   WBS serves as an input to activity definition.

C.   WBS serves as an input to risk identification.

D.   WBS serves as an input to cost budgeting.

25.   You are the project manager of the WIFI Project. You would like to meet with a stakeholder for scope validation. Which of the following is typical of scope validation?

A.   Reviewing changes to the project scope with the stakeholders

B.   Reviewing the performance of the project deliverables

C.   Reviewing the performance of the project team to date

D.   Reviewing the EVM results of the project to date

SELF TEST ANSWERS

1.   You are the project manager of the OQH Project and are working with the project stakeholders to determine the project requirements. You and the stakeholders are brainstorming privately to come up with as many solutions to the project as possible. After the brainstorming session, a recorder documents all the solutions on a white board so everyone can see the ideas and how they may be related. After the solutions have been documented, you lead the group through a voting process to discuss and rank each idea and requirement that has been proposed. What is this requirement gathering technique called?

A.   Brainstorming

B.   Nominal group technique

C.   Affinity diagram creations

D.   Mind mapping

2.   You are the project manager for the HGD Project and will need as many inputs to the scope planning as possible. Mary, your project assistant, recommends that you use some of the organizational process assets to help with your project scope planning. Of the following, which one is not an organizational process asset?

A.   Organizational procedures

B.   Organizational policies

C.   WBS

D.   Historical information

3.   You are a project manager for your organization. In your role as the project manager, you are required to cross-train and coach your project team members. Sarah, a project manager in training, wants to know which project documents can stem from templates? What should be your answer?

A.   Risk policies

B.   Organizational policies

C.   Scope management plans

D.   Historical information

4.   You are the project manager for a technical project. The project product is the complete installation of a new operating system on 4500 workstations. You have, in your project cost and schedule estimates, told the customer that the estimates provided will be accurate if the workstations meet the hardware requirements of the new operating system. This is an example of which of the following?

A.   Risk

B.   Assumption

C.   Constraint

D.   Order of magnitude

5.   You are the project manager for the NBG Project. The project is to develop new software that is supported on mobile devices. The project customer has defined a maximum budget, performance metrics, and other quality metrics for the project deliverable to be acceptable. One requirement of the project is that it must be completed within six months; this is an example of which of the following?

A.   Schedule

B.   Assumption

C.   Constraint

D.   Planning process

6.   As a PMP candidate you must be familiar with the project management terms. Sometimes the terms seem confusing, such as project scope statement, scope baseline, or even the scope control process. Which of the following best describes the project scope statement?

A.   The description of the project deliverables

B.   The authorizing document that allows the project manager to move forward with the project and to assign resources to the tasks

C.   A document that defines all the required work—and only the required work—to create the project’s deliverables

D.   The process of planning and executing all the required work to deliver the project to the customer

7.   During the planning phase of your project, your project team has discovered another method to complete a portion of the project scope. This method is safer for the project team, but it may cost more for the customer. This is an example of which of the following?

A.   Risk assessment

B.   Alternative identification

C.   Alternative selection

D.   Product analysis

8.   You are the project manager of a large software development project. Hundreds of requirements need to be documented, annotated, and communicated to the project stakeholders. Management would also like you to report when the requirements should be created and when they’re actually created by the project team. What document can help you monitor all the characteristics of each requirement?

A.   Project management plan

B.   Configuration management plan

C.   Requirements traceability matrix

D.   Project communications management plan

9.   You are the project manager for the JHN Project. Mike, a project manager you are mentoring, does not know which plan he should reference for guarding the project scope. Which plan does Mike need?

A.   The scope management plan

B.   The scope change control system

C.   The scope validation

D.   The scope charter

10.   You are the project manager for the JKL Project. This project has more than 45 key stakeholders and will span the globe when implemented. Management has deemed that the project’s completion should not cost more than $34 million. This is an example of which of the following?

A.   Internationalization

B.   Budget constraint

C.   Management constraint

D.   Hard logic

11.   You are the project manager for your organization. Your project is to construct a new house for a client. You and the client have agreed to meet at the end of each phase of the project to walk through the house as it’s being built to confirm the quality and accuracy of the build. You need to ensure that the customer formally accepts the deliverables of each project phase. This process is known as _______________.

A.   Earned value management

B.   Scope validation

C.   Quality control

D.   Quality assurance

12.   It’s important to know what each project management process creates. For example, which of the following is an output of scope validation?

A.   WBS template

B.   Rework

C.   Formal acceptance

D.   SOW acceptance

13.   Where can the project manager find work package information such as the code of an account identifier, a statement of work, information on the responsible organization, quality requirements, and information on the required resources? Choose the best answer.

A.   Execution plan

B.   WBS

C.   WBS dictionary

D.   Project management plan

14.   You are a project manager for a large manufacturer. Your current project is to create a new manufacturing assembly line that will enable your organization to create its products with less downtime and faster turnaround time for its clients. A stakeholder has presented a change request for your project, which will likely increase the cost and time needed to complete the project. All the following components are not part of the change control system except for which one?

A.   Adding more team members to the project to get the project work done faster

B.   Outsourcing portions of the project execution to transfer risk

C.   Creating tracking systems for the proposed change

D.   Documenting the project and how the manufacturing assembly should work

15.   A project team member has, on his own initiative, added extra vents to an attic to increase air circulation. The project plan did not call for these extra vents, but the team member decided they were needed based on the geographic location of the house. The project team’s experts concur with this decision. This is an example of which of the following?

A.   Cost control

B.   Ineffective change control

C.   Self-led teams

D.   Value-added change

16.   Which of the following is an output of scope control?

A.   Workarounds

B.   Recommended corrective action

C.   Transference

D.   Risk assessment

17.   You are the project manager for the JHG Project. Your project is to create a new product for your industry. You have recently learned that your competitor is also working on a similar project, but their offering will include a computer-aided program and web-based tools, which your project does not offer. You have implemented a change request to update your project. This is an example of which of the following?

A.   A change due to an error or omission in the initiation phase

B.   A change due to an external event

C.   A change due to an error or omission in the planning phase

D.   A change due to a legal issue

18.   You are the project manager for a pharmaceutical company. A new government regulation will change your project scope. For the project to move forward and be in accordance with the new regulation, what should be your next action?

A.   Prepare a new baseline to reflect the government changes.

B.   Notify management.

C.   Present the change to the CCB.

D.   Create a feasibility study.

19.   Your project is to document all the computer systems in your company. Your project team was required to document the operating systems, the hardware, the network configuration, and the software on each computer. You have finished the project scope according to plan. For the customer to accept the project, what must happen next?

A.   Nothing. The plan is complete, so the project is complete.

B.   Scope validation should be conducted.

C.   Lessons learned should be finalized.

D.   Proof-of-concept should be implemented.

20.   You are the project manager for an airplane manufacturer. Your project concerns the development of lighter, stronger material for commercial jets. As the project moves toward completion, different material composition is considered for the deliverable. This is an example of which of the following?

A.   Program management

B.   Alternatives identification

C.   Quality assurance

D.   Regulatory guidelines

21.   You are the project manager of a large project. Your project sponsor and management have approved your outsourcing portions of the project plan. The _______________ must document project scope management decisions.

A.   Project sponsor

B.   Organization’s management

C.   Vendor(s)

D.   Project management team

22.   A project team member has asked you what project scope management is. Which of the following is a characteristic of project scope management?

A.   It defines the baseline for project acceptance.

B.   It defines the requirements for each project within the organization.

C.   It defines the processes to ensure that the project includes all the work required—and only the work required—to complete the project successfully.

D.   It defines the functional managers assigned to the project.

23.   One of the stakeholders of the project you are working with asks why you consider the scope statement so important in your project management methodology. You answer her question with which of the following?

A.   It is mandatory to consult the plan before authorizing any change.

B.   Project managers must document any changes before approving or declining them.

C.   The project scope statement serves as a reference for all change requests to determine if the change is in or out of scope.

D.   The project plan and EVM work together to assess the risk involved with proposed changes.

24.   The project scope statement is decomposed into the work breakdown structure. The WBS then becomes an important part of the project for planning, execution, and control. A WBS serves as an input to many of the project processes. Of the following, which is not true?

A.   WBS serves as an input to activity sequencing.

B.   WBS serves as an input to activity definition.

C.   WBS serves as an input to risk identification.

D.   WBS serves as an input to cost budgeting.

25.   You are the project manager of the WIFI Project. You would like to meet with a stakeholder for scope validation. Which of the following is typical of scope validation?

A.   Reviewing changes to the project scope with the stakeholders

B.   Reviewing the performance of the project deliverables

C.   Reviewing the performance of the project team to date

D.   Reviewing the EVM results of the project to date