This chapter looks at the processes focused on how to plan, define, manage, and control changes to the project requirements, scope, and work breakdown structure (WBS).
The Project Scope Management knowledge area includes six processes. Four of the six processes are planning processes; the other two are monitoring and controlling processes. Properly defining the project scope statement is critical in order to complete other planning activities such as planning the project cost, project time, quality, communications, human resources, and procurement. Without
properly defined requirements, scope, and WBS, you simply cannot complete these other activities well.
The PMBOK® Guide Processes
Project Scope Management Knowledge Area
The six processes
in the Project Scope Management knowledge area are as follows:
- Plan Scope Management (planning process)
- Collect Requirements (planning process)
- Define Scope (planning process)
- Create WBS (planning process)
- Validate Scope (monitoring and controlling process)
- Control Scope (monitoring and controlling process)
Defining and documenting
the project scope is about documenting all the work to be completed and the work not to be completed, as part of the project and the product. It is important to note that the product scope is a subset of the project scope. Figure 3-1 shows the product scope as a subset of the project scope.
Figure 3-1.
Product scope as a subset of project scope
Exam Tip
Many people are used to focusing on defining the product scope as part of their scope management work. It is important to realize that there is more to the scope of the project than just the scope of delivering the product and its technical requirements. The project scope includes all the planning work, executing work, monitoring and control work, and closing work that has to be done in addition to the delivery of the product.
What Is Project Scope Management?
Project scope management is focused on defining and managing the scope of work to be completed as part of the project. It is a highly iterative process that begins with the initiation of the project and the statement of work contained in the project charter. The project charter is then used as an input into gathering the requirements, which results in requirements documentation; it may also result in a preliminary scope statement. After you have performed these next iterations of defining the scope statement, you arrive at a project scope statement, which in itself may only define and detail the work to be done in the short term and may leave some of the work to be done in the longer term relatively undefined.
REAL WORLD
Most people focus on the three pillars of project management: the scope, the time, and the cost of the project. This is for good reason, because these three foundational elements are most often used as the primary metrics of success in a project, and they also feed into the other areas of the profession of project management. Therefore, you should pay extra attention to the time and effort committed to defining the scope of a project: of the three pillars, it is the most crucial because it allows you to complete cost and time estimates.
Distinct terms are used to describe successive iterations of the work to be done on a project. Figure 3-2 shows a hierarchical view of the different terms used to describe successive and progressively more detailed iterations of the scope.
Figure 3-2.
Descriptions of project work reflecting the level of detail contained in the
description
REAL WORLD
When working on a project, I have found that most people want to spend a lot of time and energy defining the product without giving much thought to planning and defining all the other work that must be done on a project Not only does the lack of wider project work information create problems with your project as you proceed, but it also creates a false impression that all of your work as a project manager is focused on delivery of the product.
Exam Tip
Make sure when reading a question on the exam that you are careful to look out for the words project and product ” This is particularly important in questions relating to the project scope or the product scope. It is also important in the Project Quality Management knowledge area, where there are separate quality processes for the project and the product.
Plan Scope Management
More Info
Plan Scope Management You can read more about the Plan Scope Management process in the PMBOK Guide, 5th edition, in Chapter 5, section 5.1. Table 3-1 identifies the process inputs
, tools and techniques, and outputs.
Table 3-1.
Plan Scope Management Process
Inputs ➪ | Tools and Techniques ➪ | Outputs |
|---|---|---|
• Project management plan • Project charter • Enterprise environmental factors • Organizational process assets | • Expert judgment • Meetings | • Scope management plan • Requirements management plan |
The Plan Scope Management process is a planning process with two major outputs: the scope management plan and the requirements management plan.
The Plan Scope Management process addresses the following planning domain task:
- Task 2: Develop a scope management plan, based on the approved project scope and using scope management techniques, in order to define, maintain, and manage the scope of the project.
The Plan Scope Management process, like most of the other planning processes, sets out and defines your particular approach for further definition of the project and product scope, and the way in which you are going to validate scope and control any changes to the scope. All of these elements are captured in the scope management plan.
Exam Tip
You may begin to notice that the key output from the initial planning processes in any knowledge area is some form of plan. For example, a key output from the Plan Scope Management process is the scope management plan.
Inputs
The Plan Scope Management process uses some or all of the following inputs as part of the development of the scope management plan for the project.
Project Management Plan
The project management plan, at whatever stage of its development, is used as an input here into planning your approach to managing your scope. Keep in mind that early on in the project, the project management plan and its subsidiary plans will be relatively ill defined. As the project progresses and more details are known about the project and the subsidiary elements of the project, the project management plan itself will become more fleshed out. This clearly demonstrates the highly iterative nature of planning how you will manage your project and product scope. The project management plan is the key output from the Develop Project Management Plan process.
Exam Tip
Keep in mind that the project management plan is the collection of all the other subsidiary plans and baselines.
Project Charter
The project charter
is used here as an input into the Plan Scope Management process because it contains the description of the project scope that is known at that point. If the project charter contains a statement of work, this will need to be further developed and defined into a full scope statement. If the project charter is built on the results of a negotiated contract, it may include a fully defined scope of work. The project charter is the sole output from the Develop Project Charter process.
Enterprise Environmental Factors
The types of enterprise environmental factors
that can play a role in how you manage scope can include things such as the culture of the organization and its attention to detail, risk, and quality; and any external marketplace conditions that the project is being initiated to take advantage of.
Exam Tip
Enterprise environmental factors are one of the most widely used inputs throughout the PMBOK Guide. The term covers a lot of different factors that can influence a project. Take time to understand the variety of factors that are enterprise environmental factors and be able to differentiate them from organizational process assets.
Organizational Process Assets
Once again, organizational process assets
play an important role as an input into a planning process. The types of organizational process assets that are most useful in this section are any blank templates, defined policies and procedures, any historical information, lessons learned, and any project management methodology already in place.
Tools and Techniques
The following tools and techniques
are available to be used to develop the inputs into this process in order to produce the scope management plan.
Expert Judgment
Expert judgment
is one of the key tools used throughout the entire PMBOK guide. In relation to the Plan Scope Management process, the experts you will call on include your own expert judgment, the expert judgment of team members, and any other experts you want to consult to help you define your particular approach to scope management.
Meetings
Meetings in which you gather project team members and relevant stakeholders together are an important tool and technique in defining your approach to scope management. Attendees at such meetings should include anyone with responsibility for any part of the scope management process.
Exam Tip
The way in which your run your meetings determines how effective they are. Meetings are both an important way to gather technical information and an important means of distributing information and building a high-performing team. These latter attributes of a meeting are more fully discussed in the Project Communications Management knowledge area and the Project Human Resource Management knowledge area.
Outputs
After applying the appropriate tools and techniques to the selected inputs, the Plan Scope Management process has the following outputs.
Scope Management Plan
The scope management plan is one of the more important subsidiary plans contained in the project management plan. It outlines your particular process for iteratively defining the detail of the project and product scope, the process of decomposition for the creation of your work breakdown structure (a process that uses the scope statement that has been developed to execute project work), and the process by which any requested changes are considered and either approved or declined. In addition to these elements, it also sets out the process of validating the project scope and deliverables, and how signoff for closure will be obtained. Again, the detail in the scope management plan reflects the detail of the project scope. A highly defined scope results in a well-defined scope management plan, and a loosely defined scope results in a more flexible scope management plan, allowing for further iterations.
The scope management plan is used as an input into the following processes:
- 5.2 Collect Requirements
- 5.3 Define Scope
- 5.4 Create WBS
- 5.5 Validate Scope
REAL WORLD
As a general rule of thumb, I like to make sure about one-third of the content of the scope statement refers to what is not included in both the project and product scope of work. If you don't specifically list the exclusions, stakeholders will make assumptions about what is, and what isn’t, included in the scope of work, and it is these assumptions that lead to disagreements.
Requirements Management Plan
The
requirements management plan
is a specific plan that addresses how the product requirements are documented, defined, tracked, and reported against. It is also in the requirements management plan that detail of the configuration management activities are defined. The requirements management plan also contains methods for prioritizing the requirements, and any defined metrics to define the product. The requirements management plan is used as an input into the Collect Requirements process.
Quick Check
1.
What is the main focus of the Plan Scope Management process?
2.
What is the difference between the project scope and the product scope?
3.
What are the key differences between the scope management plan and the requirements management plan?
Quick Check Answers
1.
The main focus of the Plan Scope Management process is to develop a scope management plan that will guide your activities in defining the project requirements, scope, and work breakdown structure.
2.
The project scope includes a definition of all the work required in the project, whereas the product scope focuses on defining the technical requirements of the expected deliverable.
3.
The scope management plan can be seen as the broader of the two management plans because it focuses on the entire project and product scope and how it will be defined, documented, and controlled. The requirements management plan focuses solely on further iterations and definition of the requirements of the project deliverable.
Collect Requirements
More Info
Collect Requirements You can read more about the Collect Requirements process in the PMBOK Guide, 5th edition, in Chapter 5, section 5.2. Table 3-2 identifies the process inputs, tools and techniques, and outputs.
Table 3-2.
Collect Requirements Process
Inputs ➪ | Tools and Techniques ➪ | Outputs |
|---|---|---|
• Scope management plan • Requirements management plan • Stakeholder management plan • Project charter • Stakeholder register | • Interviews • Focus groups • Facilitated workshops • Group creativity techniques • Group decision-making techniques • Questionnaires and surveys • Observations • Prototypes • Benchmarking • Context diagrams • Document analysis | • Requirements documentation • Requirements traceability matrix |
The Collect Requirements process
addresses the following planning domain task:
- Task 1: Review and assess detailed project requirements, constraints, and assumptions with stakeholders based on the project charter and lessons learned, and by using requirements-gathering techniques, in order to establish detailed project deliverables.
Requirements can best be defined as a definition of the stakeholders’ needs to meet the project’s objectives. They can include technical requirements or known constraints. Therefore, the process of collecting requirements involves stakeholders and documentation of what they believe the project objectives are. It is important to note that the project requirements can be much more than the product requirements.
Exam Tip
On the exam, you should assume that unless otherwise explicitly stated, you must go through a requirements-gathering process prior to completing the scope statement.
REAL WORLD
I have often found that broader project requirements can be captured and documented as key performance indicators for determining the success or otherwise of the project, beyond the strict technical requirements of the product. For example, you could have customer satisfaction, health and safety compliance, environmental management requirements, or any other factors set as key performance indicators of project success, and these factors would be gathered in the requirements documentation.
Inputs
The following inputs are used in the Collect Requirements process.
Scope Management Plan
Obviously, in order to collect and define the project requirements, it is important that you act according to your scope management plan, because the requirements are a subset of the project scope. The scope management plan is a key output from the Plan Scope Management process.
Requirements Management Plan
The requirements management plan is an important input into this process because it guides you as you seek to further define and document the requirements of the project and product. The requirements management plan is an output from the Plan Scope Management process.
Stakeholder Management Plan
The
stakeholder management plan
is an important input into this process because you will be approaching stakeholders and asking what the requirements are for the project and the product. Thus, the stakeholder management plan and the information it contains about how you identify and manage stakeholder expectations is a critical part of and input into this process. The stakeholder management plan is a key output from the Plan Stakeholder Management process.
Project Charter
The project charter
authorizes the project and contains any high-level information about the product and project deliverable that can be used to assist the process of collecting more detailed requirements. The project charter is the sole output from the Develop Project Charter process.
Stakeholder Register
The
stakeholder register
identifies the known stakeholders, their power and interest in the project, an assessment of their expectations, and an analysis of their communication needs. You can use this information to effectively interact with the stakeholders to ensure that you have gathered all the project and product requirements. The stakeholder register is an output from the Identify Stakeholders process.
Tools and Techniques
The following tools and techniques can be used to produce the outputs from the Collect Requirements process.
Interviews
When dealing with stakeholders, one of the most effective ways of soliciting information from them is by using interviews. Interviews can be formal or informal, and they can be conducted in person or via email or surveys.
Focus Groups
Focus groups
are a very effective means of bringing together relevant stakeholders and subject matter experts and gathering information from them in a structured way.
Facilitated Workshops
Facilitated workshops provide a forum to solicit information from various stakeholders in a controlled manner. They are focused and interactive by their nature and are often facilitated by an independent party. Examples of specific types of facilitated workshops include the joint application design/development sessions (JAD) and the quality function deployment (QFD) facilitated workshops used in new product development.
Group Creativity Techniques
Several types of
group creativity techniques
can be used as tools in this process to further define and document project and product requirements. Brainstorming is a particularly popular one, in which you bring together relevant stakeholders with the experience and skills needed and run a free-flowing session where all ideas are considered good ideas and are further refined by the group.
The nominal group technique is a group creativity technique that uses a variety of voting methods by which group members rank the most useful ideas for further brainstorming. Examples include the fist-of-fives, where group members display their support for an idea by raising a number of fingers on their hands; weighted voting systems, where each member is given a certain number of votes to allocate between different ideas; and a simple, straightforward voting system to rank different ideas in terms of validity and prioritization.
Group Decision-Making Techniques
The goal of
group decision-making techniques
is to generate either a consensus among group members or a decision to abide by majority opinion. Obviously, there will be dissenting and differing views on which ideas should have greatest priority. An important part of running any group decision-making process is to establish early on how decisions will be made so that all participants are aware of the process for decision-making. You can agree on any one of the following group decision-making techniques to aid your decision-making process:
- Unanimity or consensus is where everybody agrees on a single course of action.
- The Delphi technique, which gathers information anonymously from experts to avoid peer pressure, can be used if you want to allow experts to provide anonymous feedback.
- You can decide to use a simple majority for any decisions made. If a majority (more than 50% of the members of the group) cannot be obtained, you may decide to use plurality, in which the largest bloc in a group decides.
- A final method of obtaining a group decision in the face of dissenting opinions is to agree to allow one individual in the group to make the decision for the group. This is commonly referred to as a dictatorship group decision-making technique.
Questionnaires and Surveys
A key element of the Collect Requirements process is the gathering of information that can then be used to further define the requirements for the project and the product. Questionnaires and surveys present a very effective means of gathering this information from identified stakeholders. Depending on the development of the questionnaires and surveys, the information gathered may be able to have some statistical analysis applied to it to aid in your requirements-gathering process.
Observations
Observations
are a very accurate way of determining how a potential project or product scope will be implemented or used in real life. If the project scope includes certain processes, observing who will use these processes, how they will be used, and any other aspects in the real world will help define the process. If part of the project scope includes any product, observing the users of the product in the real world will also help define the product further.
Prototypes
Prototypes
are a great way to get fast feedback on any element of the product by producing drafts and seeking feedback from stakeholders as to whether this is what they wanted. The practice of prototyping is quickly gaining support with the rise of technology that allows rapid prototyping. In addition to physical prototypes, storyboarding can be used to show the sequence of processes or product development to solicit feedback from stakeholders, particularly in the production of web pages or user interfaces.
Benchmarking
Benchmarking
is a tool used in several processes. It involves comparing what you planned to do against other projects or organizations to determining whether you are better or worse than them. You can gather this important information from competitors, trade and industry associations, and the Project Management Institute.
Context Diagrams
A
context diagram
is a simple tool showing visually how a business system and users interact. Figure 3-3 shows an example of a context diagram.
Figure 3-3.
A context diagram showing the relationship between supplier, ordering software, accounts department, and warehouse
Document Analysis
As part of refining the requirements, you may want to carry out a document analysis and examine any relevant documents such as business plans, data models, software documentation, and issues logs to help you summarize the requirements.
Outputs
The following outputs are generated from the Collect Requirements process.
Requirements Documentation
The
requirements documentation
is highly iterative; you may be able to fully define certain requirements and not yet define other requirements. When requirements are fully defined and documented, they include a description of how the requirement meets the identified business need, objectives, or stakeholder requirements. They also include a traceability matrix identifying which stakeholders requested each requirement, defining acceptance criteria, and providing a link back to the business objective that the requirement is intended to meet.
Exam Tip
You can view the requirements documentation as a subsidiary of the scope statement. Rather than referring to the entire project and product scope, the requirements documentation focuses on individual requirements of parts of the project.
The requirements documentation
as an output goes on to be used as an input into the following processes:
- 5.3 Define Scope
- 5.4 Create WBS
- 5.5 Validate Scope
- 5.6 Control Scope
- 8.1 Plan Quality Management
- 12.1 Plan Procurement Management
Requirements Traceability Matrix
The
requirements traceability matrix
is a valuable tool for ensuring that the documented requirements are mapped directly back to business objectives. A requirements traceability matrix is a table that links the origins of individual product requirements to the expected deliverable that meets those requirements so that you can track requirements throughout the project life cycle. This is particularly important if you want to either change a requirement and assess the impact it will have on deliverables or check that a deliverable still meets the original requirement.
The requirements traceability matrix
is used as an input into the following two processes:
- 5.5 Validate Scope
- 5.6 Control Scope
Quick Check
1.
What is the main focus of the Collect Requirements process?
2.
How is the requirements documentation different from the project scope statement?
3.
Why is consultation with stakeholders critical to successfully documenting project requirements?
Quick Check Answers
1.
The main focus of the Collect Requirements process is to use a variety of means to gather from stakeholders their technical requirements, which are then used to define the scope of work.
2.
The requirements documentation is a subset of the total project scope statement and relates specifically to how requirements of the project and product align with and deliver project objectives. The project scope statement describes and defines the total work to be done in delivering the project and product.
3.
Consultation with stakeholders is critical to successfully documenting and defining project requirements, because the wishes of stakeholders are driving the project, and by consulting them you can ensure that you meet their expectations by delivering the requirements.
Define Scope
More Info
Define Scope You can read more about the Define Scope process in the PMBOK Guide, 5th edition, in Chapter 5, section 5.3. Table 3-3 identifies the process inputs, tools and techniques, and outputs.
Table 3-3.
Define Scope Process
Inputs ➪ | Tools and Techniques ➪ | Outputs |
|---|---|---|
• Scope management plan • Project charter • Requirements documentation • Organizational process assets | • Expert judgment • Product analysis • Alternatives generation • Facilitated workshops | • Project scope statement • Project document updates |
The Define Scope process
is one of four planning processes in the Project Scope Management knowledge area. The Define Scope process covers the following planning domain task:
- Task 2: Develop a scope management plan, based on the approved project scope and using scope management techniques, in order to define, maintain, and manage the scope of the project.
REAL WORLD
It is very rare that you will ever begin a project with a complete and detailed description of the scope. Often this occurs only as a result of lengthy contractual negotiations. In almost every other situation, you will begin a project with enough of the scope defined to allow you to start, and then you will undertake successive iterations of definition and documentation as you go. You may also decide to commit time and energy to defining the scope for the immediate timeframe, and leave definition of the remainder of the scope until you get closer to the time of delivery.
Inputs
The following inputs can be used in the Define Scope process.
Scope Management Plan
Obviously, in order to define the scope, you are going to have to work according to your scope management plan, which sets out the process you will use to iteratively define and document the scope of both your project and the product. The project scope management plan is the key output from the Plan Scope Management process.
Project Charter
The project charter
can be used as a key input into the Define Scope process because it contains the project approvals and any known description of the project and product scope. The project charter is the sole output from the Develop Project Charter process.
Requirements Documentation
The requirements documentation is an output from the Collect Requirements process and contains the defined and documented project and product requirements. These requirements form an important part of both the project and product scope.
Organizational Process Assets
Organizational process assets
that can be used to define the scope include any project management methodology, policies, and blank templates that the organization has. There is also a high probability that the organization has completed a project with a similar scope in the past, and thus any lessons learned or historical information from previous projects or phases are important organizational process assets that can be used when defining the scope. These resources can also include important internal stakeholders such as the project sponsor.
Tools and Techniques
The following tools and techniques can be used on the inputs to generate the process outputs.
Expert Judgment
Again we can see expert judgment as an effective tool; expert experience and skill can help you refine process inputs and develop them into the expected outputs. In this instance, you as project manager are one of the more important experts, as are your project team members, who are responsible for completing the project work, and any other stakeholders with relevant experience and skill in defining the scope.
Product Analysis
Product analysis
is best used when a project is delivering a product, instead of a service or result, as its major deliverable. Breaking down the product into its component parts and ensuring that each part meets the requirements and technical specifications assists with documenting the product scope. Product analysis can also include value-engineering processes in which you try to use innovation to deliver the product as efficiently as possible.
Alternatives Generation
The process of
alternatives generation
considers all the potential ways in which the project and product work can be performed in order to determine whether you are using the most efficient way of delivering the project and product scope.
Facilitated Workshops
Facilitated workshops involve bringing experts together in a workshop setting and having an independent facilitator guide the group to produce successive iterations of the project and product scope. The role of the independent facilitator is to stay neutral, set and enforce rules about how participants contribute, keep the workshop focused and on track, and make sure expectations are clearly understood.
Outputs
The following outputs are produced by the Define Scope process.
Project Scope Statement
The major output from the Define Scope process is the
project scope statement
, which describes in increasing detail the deliverables, assumptions, and constraints of the project. The project scope statement defines all the work to be done on the project, and only the work to be done on the project. It includes a detailed description of the exclusions and the work that will not be done as part of the project. The project scope statement also includes a full description of the work to be done to deliver the scope of the product.
Note
Scope creep and gold plating One of the primary reasons to conduct scope management planning exercises and produce a clear definition of the scope statement with a documented change-control process is to ensure that your project is not subject to scope creep. Scope creep happens because of undocumented scope change. At all times, you must deliver only what is documented for your project and product scope. This does not mean that change will not occur on your project; in fact, quite the opposite—you can expect change at all points in your project. What it means is that you consider all changes, no matter how small or large, and if the change is accepted, you document this and incorporate it into your scope statement, thereby stopping scope creep. The other element to watch for with undocumented scope is gold plating. Gold plating occurs when you see the opportunity to deliver greater quality for less cost and in less time to the client and decide to proceed with this without documenting it. There is nothing wrong with delivering greater quality and exceeding expectations, but once again, at all times you must only be producing what is documented.
The project scope statement
as an output goes on to be used as an input into the following processes:
- 5.4 Create WBS
- 6.3 Sequence Activities
- 6.5 Estimate Activity Durations
- 6.6 Develop Schedule
Project Document Updates
The process of defining the scope will probably result in the requirement to update other project documents such as the stakeholder register, to identify any changes to stakeholder expectations; the requirements documentation, to account for any iterative development of the scope that affects requirements; and, dissociated from the requirements documentation, the requirements traceability matrix.
Quick Check
1.
How do the Collect Requirements and Define Scope processes interact with each other?
2.
Why is it important to define exclusions in the project scope statement?
3.
How is the information about the project and product scope statement contained in the project charter different from the information contained in the project scope statement?
Quick Check Answers
1.
The Collect Requirements process takes the statement of work and project charter and seeks to gather requirements from stakeholders that are then used as an input into the Define Scope process to help define the scope statement.
2.
It is important to define the known project and product exclusions as part of the project scope statement in order to avoid ambiguity and assumptions about what is, and what is not, included in the work to be done.
3.
The project charter contains a description of the project and product work to be done that is known at the time of initiating the project. As such, it may be at a much higher level than the information contained in the project scope statement. Additionally, the project charter contains other information such as the project’s purpose, justification, and any required approvals.
Create WBS
More Info
Create WBS
You can read more about the Create WBS process in the PMBOK Guide, 5th edition, in Chapter 5, section 5.4. Table 3-4 identifies the process inputs, tools and techniques, and outputs.
Table 3-4.
Create WBS Process
Inputs ➪ | Tools and Techniques ➪ | Outputs |
|---|---|---|
• Scope management plan • Project scope statement • Requirements documentation • Enterprise environmental factors • Organizational process assets | • Decomposition • Expert judgment | • Scope baseline • Project document updates |
The Create WBS process
is the last of the planning processes in the Project Scope Management knowledge area and relies on the Collect Requirements and Define Scope processes to be complete. The Create WBS process covers the following planning domain task:
- Task 2: Develop a scope management plan, based on the approved project scope and using scope management techniques, in order to define, maintain, and manage the scope of the project.
Exam Tip
On the exam, unless it is otherwise stated, you should assume that the processes of collecting requirements and defining the scope have occurred before beginning the process of creating the WBS.
Inputs
The following inputs
can be used to generate the outputs of the Create WBS process.
Scope Management Plan
The scope management plan is a key input because in this plan you have detailed how you will approach the process of decomposing the project scope statement and creating the work breakdown structure (WBS). The scope management plan is a key output from the Plan Scope Management process.
Project Scope Statement
The WBS is a breakdown of the entire project scope statement
into its component parts; therefore, the project scope statement is a key input into the Create WBS process. The project scope statement is the key output from the Defined Scope process.
Requirements Documentation
The requirements documentation is a key output from the Collect Requirements process. In addition to the project scope statement, having access to the requirements documentation and the requirements traceability matrix enables you to ensure that your process of decomposition to create the WBS captures all of the project and product scope and the associated requirements.
Enterprise Environmental Factors
There are some industry-wide enterprise environmental factors
that can be useful as an input into the Create WBS process. For example, the ISO/IEC 15288 standard on systems engineering-system life cycle processes could be used for engineering projects.
Organizational Process Assets
The most useful organizational process assets
to be used as an input into the Create WBS process include any project management methodology, policies, or blank templates for the creation of a WBS, and any historical information or lessons learned from previous projects.
Tools and Techniques
Two techniques are used in the Create WBS process.
Decomposition
The process of
decomposition
involves taking a high-level description of the work to be done for the project and product, and successively breaking it down into deliverables, sub-deliverables, and finally work packages. The work package is the lowest level to which you should break down the WBS. A work package is defined as a package of work that can reliably be estimated for time and cost. This means you can easily allocate the work to one person and that it doesn’t make sense to decompose it any further, because at that level you can develop an accurate estimate of the time it will take and the amount of money it will cost to complete the work package. Below the level of work packages are individual activities, which are used in the Project Time Management knowledge area to assist in building a project schedule.
The WBS is a graphical representation
of the total project scope; therefore, work that is not included in the WBS is not part of the project. If the project scope is being developed iteratively, this is represented in the development of the WBS, and it too develops iteratively.
REAL WORLD
I always use my project team members who are responsible for completing the work to help complete the WBS. Not only does this give me the right technical input from the people responsible for completing the work, but it also creates commitment to the process of completing the work, because people feel they have made a significant and personal contribution.
Note
Decomposition
is used in any of the breakdown structures used in project management. It simply describes a process of breaking down a larger concept into its component parts. It is used to create the WBS, the organizational breakdown structure (OBS), the risk breakdown structure (RBS), and another RBS, the resource breakdown structure (RBS).
Expert Judgment
Expert judgment
is a key tool in the Create WBS process because the creation of the WBS is best done by those experts with knowledge about the work to be done and how it can best be decomposed into its component parts.
Outputs
The following outputs are generated by the Create WBS process.
Scope Baseline
The
scope baseline
is used to measure what is actually being produced against what is expected to be produced in relation to the project and product scope. It is made up of three key, distinct elements: the project scope statement, the WBS, and the WBS dictionary.
Exam Tip
The scope baseline is what you use to measure progress against in the project. Any baselines in project management can only be changed through the formal change-control process. After an approved change is integrated into a baseline, the baseline itself is changed; thus the easiest way to think of a baseline is that it is what you originally started with plus any approved changes.
The WBS is often called the backbone of a project. This is because it acts as an input into many other planning processes. Without a complete and accurate WBS, your efforts in cost estimating, budget estimating, activity definition, risk identification, scope validation, and all the subsequent processes they provide inputs into would be extremely difficult. Creation of the WBS is done by decomposing the top-level descriptions of project work into their component parts. The highest level is broken down into deliverables, then into sub-deliverables, and then into individual work packages. A work package is an amount of work that can reliably be estimated for time and cost and can generally be performed by one person. Below work packages are activities, which are used in developing a project schedule, as described in the next chapter.
Figure 3-4 shows a WBS for a new house project, with the breakdown of different work streams to work package level. Note that all nodes in the WBS have a unique identifying number that allows you to track work being done and also to allocate costs to specific work packages for better cost reporting. The numbering system
should clearly identify each node and relate to the node above so you can easily see related nodes and the way they are decomposed. This numbering system is an example of a configuration management system.
Figure 3-4.
A work breakdown structure (WBS)
showing the total project, deliverables, sub-deliverables, and work packages
Note
WBS dictionary
When you are representing a WBS graphically, each node in the WBS can contain only summary information, such as the configuration management details; the name of the deliverable, sub-deliverable, or work package; and summary information about the time, cost, and resources allocated to each node. The WBS dictionary is a text-based document that provides additional information about the summary information contained in each WBS node.
The WBS becomes an input into the following processes:
- 5.5 Validate Scope
- 6.2 Define Activities
- 7.2 Estimate Costs
- 7.3 Determine Budget
- 11.2 Identify Risks
- 11.3 Perform Qualitative Risk Analysis
Exam Tip
Many exam questions pose a scenario where something is missing and ask what you should do. In most instances, it is acceptable to continue with the project and develop something in the interim to help tide you over. The only exception to this is if it is the WBS that is missing. If is you are working on a project and do not have the WBS, you must stop and create the WBS, because without it you cannot complete the planning processes of your project.
Project Document updates
As a result of creating the WBS, information may be gathered that requires other project documents to be updated, such as the project scope statement and the requirements documentation.
Quick Check
1.
To what level of detail do you decompose the project scope when creating the WBS?
2.
How would you define the key elements of a work package?
3.
What elements make up the scope baseline?
Quick Check Answers
1.
The project scope statement is decomposed to major deliverables, to sub-deliverables, down to the work package level.
2.
A work package can best be defined as an amount of work that can reliably be estimated for time and cost. Going any further in the decomposition process delivers little benefit for the time taken to do the work.
3.
The three key elements of the scope baseline are the project scope statement, the WBS, and the WBS dictionary.
Validate Scope
More Info
Validate Scope
You can read more about the Validate Scope process in the PMBOK Guide, 5th edition, in Chapter 5, section 5.5. Table 3-5 identifies the process inputs, tools and techniques, and outputs.
Table 3-5.
Validate Scope Process
Inputs ➪ | Tools and Techniques ➪ | Outputs |
|---|---|---|
• Project management plan • Requirements documentation • Requirements traceability matrix • Verified deliverables • Work performance data | • Inspection • Group decision-making techniques | • Accepted deliverables • Change requests • Work performance information • Project document updates |
The Validate Scope process is a monitoring and control process, one of two monitoring and control processes in the Project Scope Management knowledge area.
The Validate Scope process covers the following domain monitoring and controlling task:
- Task 1: Measure project performance using appropriate tools and techniques, in order to identify and quantify any variances and corrective actions.
Note
Validation compared to verification The process of validation is important to understand, as is the difference between it and the process of verification. Verification is about confirmation that the product, service, or result produced complies with agreed specifications or requirements. It is primarily an internal process that the delivering organization performs prior to submitting the product, service, or result for validation, which involves the customer as well. Validation also involves a check that the product, service, or result meets stakeholder requirements. Verification occurs before validation.
Inputs
The Validate Scope process uses some or all of the following inputs
.
Project Management Plan
The project management plan
guides how you execute and monitor your project, and, as such, it contains plans and baselines useful for validating the project scope. The particular parts of the project management plan that are most useful as inputs into the Validate Scope process are the scope management plan and the scope baseline. The scope management plan is used as an input because it details how you plan to manage your scope in its entirety, including validation. The scope baseline, which includes the scope statement, the WBS, and the WBS dictionary, is absolutely necessary in validating the scope because it represents the baseline against which you are comparing the actual work performed. The project management plan
is an output from the Develop Project Management Plan process; the scope management plan is a key output from the Plan Scope Management process; and the scope baseline is the key output from the Create WBS process.
Requirements Documentation
The requirements documentation
lists the project objectives and the requirements that will deliver those objectives, and as such it is an essential input into validating the scope. Requirements documentation is the key output from the Collect Requirements process.
Requirements Traceability Matrix
The requirements traceability matrix provides an additional measure of rigor when validating the scope, because you are able to link specific requirements back to identified business objectives. The requirements traceability matrix is an output from the Collect Requirements process.
Verified Deliverables
The
verified deliverables
are deliverables that have already been completed and checked for correctness against the required specifications through the control quality process and, as such, now need to be validated in order to become accepted deliverables and used in the Close Project or Phase process. Verified deliverables are a key output from the Control Quality process.
Note
Deliverables Project deliverables must go through the process of first being verified and then being accepted. Verification is an internal process that ensures correctness against predetermined quality standards, whereas validation is an external acceptance process completed by the project sponsor or customer.
Work Performance Data
The work performance data
indicates whether there is compliance with the documented requirements. Work performance data is an output from the Direct and Manage Project Work process.
Tools and Techniques
The following two tools and techniques can be used to deliver the process outputs.
Inspection
Inspection as a technique literally means inspecting the deliverables to ascertain whether they meet the documented requirements and acceptance criteria.
Group Decision-Making Techniques
Group decision-making techniques are any techniques used to allow a group of people to reach a decision. It is best if the decision-making technique is outlined to the group prior to the decision-making process being undertaken, to be sure that all group members understand how the decision will be made.
Outputs
The Validate Scope process has the following outputs.
Accepted Deliverables
Accepted deliverables
meet the acceptance criteria and are signed off and accepted by either the customer or the project sponsor. Accepted deliverables are used as the key input into the Close Project or Phase process.
Exam Tip
A key role of the project sponsor is to act as the person internal to the performing organization who formally accepts the product. The customer is usually a person external to the organization who accepts the product.
Change Requests
If a deliverable is not accepted due to some areas of noncompliance or noncorrectness, a change request
for defect repair may be generated. Change requests are a key input into the Perform Integrated Change Control process.
Work Performance Information
Work performance information takes the work performance data and presents it in such a way that project progress can easily be determined and identified. This information is communicated to stakeholders as appropriate. Work performance information is used as an input into the Monitor and Control Project Work process.
Note
Work performance Work performance data is the raw data gathered in any process. Work performance information is the data after it has been interpreted into something meaningful. Work performance data becomes work performance information, which in turn is used in work performance reports.
Project Document Updates
The types of project documents
that may be updated include requirements documentation, the scope statement, and quality control documents.
Quick Check
1.
What is the main focus of the Validate Scope process?
2.
What is the difference between validation and verification?
3.
Who formally accepts the project deliverables?
Quick Check Answers
1.
The main focus of the Validate Scope process is to formally accept the completed project deliverables.
2.
Verification is an internal process completed by the performing organization measuring the product, service, or result against defined requirements and specifications. It is completed prior to validation. Validation involves taking the verified product, service, or result and, in conjunction with key stakeholders, confirming that it meets stakeholder requirements.
3.
The project sponsor formally accepts the project deliverables on behalf of the performing organization. The customer formally accepts the project deliverables on behalf of the external organization requesting the work to be done.
Control Scope
More Info
Control Scope You can read more about the Control Scope process in the PMBOK Guide, 5th edition, in Chapter 5, section 5.6. Table 3-6 identifies the process inputs, tools and techniques, and outputs.
Table 3-6.
Control Scope Process
Inputs ➪ | Tools and Techniques ➪ | Outputs |
|---|---|---|
• Project management plan • Requirements documentation • Requirements traceability matrix • Work performance data • Organizational process assets | • Variance analysis | • Work performance information • Change requests • Project management plan updates • Project document updates • Organizational process assets updates |
The Control Scope process is a monitoring and control process, one of two monitoring and control processes in the Project Scope Management knowledge area.
The Control Scope process covers the following monitoring and controlling domain
task:
- Task 1: Measure project performance using appropriate tools and techniques, in order to identify and quantify any variances and corrective actions.
Inputs
The following inputs can be used in the Control Scope process.
Project Management Plan
The project management plan
, or, more correctly, some of the subsidiary plans of the project management plan, are used as inputs to enable you to control the scope. By using a description of what you planned to do and comparing that to what you are actually doing, you can spot any variances. The project management plan is a key output from the Develop Project Management Plan process.
Exam Tip
Whenever you see the project management plan listed as an input into a process, it indicates that more than one subsidiary plan is used in this process. In this instance, elements of the scope management plan, change management plan, configuration management plan, and requirements management plan are used as inputs to control the scope.
Requirements Documentation
The clearly defined requirements documentation
for the project and product can be used to detect any deviation in the scope during the Control Scope process. The requirements documentation is a key output from the Collect Requirements process.
Requirements Traceability Matrix
Using the requirements traceability matrix
as an input helps bring an additional level of rigor into the Control Scope process by enabling you to map requirements back to project objectives. The requirements traceability matrix is a key output from the Collect Requirements process.
Work Performance Data
Work performance data
in this instance refers to information about change requests received or the number and type of deliverables completed. Work performance data is the key output from the Direct and Manage Project Work process.
Organizational Process Assets
Key organizational process assets
that can be useful as inputs into the Control Scope process include any change control–related or scope control–related guidelines, policies, or templates, and any documented monitoring and reporting methods.
Tools and Techniques
There is a single technique used in the Control Scope process.
Variance Analysis
Any
variance analysis
is simply an examination of what is actually occurring against what was planned to occur, looking for any variances, positive or negative, and acting on them accordingly. If you discover any variance, you can decide to undertake corrective or preventive actions or initiate changes.
Exam Tip
Variance analysis is a key tool in all the monitoring and controlling processes. Wherever you see variance analysis as a tool in a process, you should also look for some sort of baseline that is being checked for variance.
Outputs
The following outputs are produced by the Control Scope process.
Work Performance Information
Work performance information
as an output from this process includes information relating to the type and category of change requests received and how they may potentially affect other areas of the project. Work performance information goes on to be used as an input in the Monitor and Control Project Work process.
Change Requests
Change requests are a result of variances detected. All change requests must be processed according to the predefined change management process. Change requests go on to be used in the Perform Integrated Change Control process.
Project Management Plan Updates
Elements of the project management plan that may be updated as a result of the work done during the Control Scope process include the project scope statement, WBS, and WBS dictionary.
Project Document Updates
As a result of performing the Control Scope process, you may choose to update the requirements documentation to reflect new or changed information.
Organizational Process Assets Updates
Organizational process assets
that may be updated as a result of the Control Scope process include any elements of the project scope management plan, change management plan, or lessons learned that have been gathered.
Quick Check
1.
What is the main focus of the Control Scope process?
2.
Why is variance analysis important to the Control Scope process?
3.
What is the relationship between work performance data and work performance information?
Quick Check Answers
1.
The main focus of the Control Scope process is to check the progress of the project against planned baselines, looking for variances and acting on any that are discovered.
2.
Variance analysis is the process of checking what you planned to do against what you are actually doing. If you discover a variance between the two, then you must act.
3.
Work performance data is the raw data collected while observing work being performed; it is turned into work performance information by applying metrics, formulas, and other ways of interpreting the data in order for it to make sense and be usable for measuring project progress.
Chapter Summary
- The Project Scope Management knowledge area is focused on the processes of planning, defining, documenting, and managing change to the project requirements, scope, and work breakdown structure (WBS).
- Like other knowledge areas, the Project Scope Management knowledge area begins with a process of planning how you will manage the project scope. The key output from this is the scope management plan, which becomes a subsidiary plan of the project management plan.
- The first step in a linear process of defining the full project scope is to collect project requirements from stakeholders and develop both the requirements documentation and requirements traceability matrix.
- The process of defining the project scope is highly iterative and may be subject to rolling-wave planning throughout the life of the project. After it is defined, the project scope is captured in the project scope statement. The scope of the product is a subset of the total project scope.
- The WBS is a graphical representation of the project scope statement; thus any work not included in the WBS is not included as part of the project. The WBS forms one of three key elements of the scope baseline. The scope baseline is made up of the project scope statement, the WBS, and the WBS dictionary.
- The WBS, after it is completed, serves as a valuable input into several other processes, including Project Cost Management, Project Time Management, and Project Risk Management.
- The process of validating the project scope involves internal and external stakeholders checking that the deliverables conform to stakeholder requirements and expectations. It is performed after scope verification.
- All changes to the project scope or requirements must go through the documented change control process. Any approved changes are incorporated into the scope baseline.
Exercises
The answers for these exercises are located in the “Answers” section at the end of this chapter.
1.
Create a WBS.
You are working on a project, Project BlueTalk, to develop a new piece of software. As part of the development of the scope, you have identified that the four major deliverables are the software design, the testing of the software, the user training of the software, and the implementation of the software. At this early stage in the project, you are only able to further define the software design process and have broken that down into the sub-deliverables for module 1 and module 2. Using your project team members responsible for the software design, you have broken module 1 down into three work packages: database, user interface, and backup.
Use this information to complete a WBS for the project.
2.
Map each of the following terms on the left to the definition that best fits it on the right:
a) Project charter | i. An early iteration of the project scope statement |
b) Statement of work | ii. A description of all the work to be done on a project |
c) Requirements | iii. A description of the product, service, or result to be delivered as part of the project work |
d) Preliminary scope statement | iv. A narrative description of the work to be completed; used as an input into the project charter |
e) Project scope statement | v. The documented list of expectations and specifications from project stakeholders |
f) Product scope | vi. The foundational document for a project, which contains a high-level description of the work to be completed |
Review Questions
Test your knowledge of the information in Chapter 3 by answering these questions. The answers to these questions, and the explanation of why each answer choice is correct or incorrect, are located in the “Answers” section at the end of this chapter.
1.
What is the correct order of activities in the Project Scope Management knowledge area?
A.
Define Scope, Collect Requirements, Plan Scope Management, Create WBS
B.
Plan Scope Management, Define Scope, Collect Requirements, Create WBS
C.
Plan Scope Management, Collect Requirements, Define Scope, Create WBS
D.
Collect Requirements, Define Scope, Create WBS, Plan Scope Management
2.
What are the elements of the scope baseline?
A.
The project scope management plan and requirements documentation
B.
The project scope management plan and project scope statement
C.
The scope statement, the WBS, and the WBS dictionary
D.
The project scope statement, the product scope statement, and the WBS
3.
What is the correct term for the component of the project management plan that describes how project requirements will be analyzed, documented, and managed?
A.
The requirements management plan
B.
The scope management plan
C.
The project scope statement
D.
The scope baseline
4.
Brainstorming is an example of what sort of process tool or technique?
A.
Group decision-making techniques
B.
Observations
C.
Facilitated workshops
D.
Group creativity techniques
5.
What is the main purpose of the requirements traceability matrix?
A.
To hold people accountable for work delivery
B.
To let stakeholders know when the project will be delivered
C.
To map individual requirements back to specific business needs and objectives
D.
To describe the work to be completed in the project
6.
Which of the following best describes the relationship between the scope of the project and the scope of the product?
A.
The scope of the project includes all the planning work to be done, whereas the scope of the product documents the technical requirements of the deliverable.
B.
The product scope is a subset of the project scope.
C.
The project scope is delivered as part of the delivery of the product scope.
D.
There is no difference between the two terms.
7.
What is the lowest level of WBS decomposition?
A.
The deliverable
B.
Project activities
C.
The work package
D.
The scope statement
8.
What is the name of the document that provides additional information about each node of the WBS?
A.
The scope management plan
B.
The WBS dictionary
C.
The project scope statement
D.
The requirements documentation
9.
What is the key purpose of the Validate Scope process?
A.
It is an internal process to determine whether the product meets strict technical requirements.
B.
It is the process of checking whether the deliverable conforms to requirements.
C.
It is the process of managing changes to the project scope statement.
D.
It is a process that involves internal and external stakeholders checking that the deliverable meets project requirements and stakeholder expectations.
10.
Change requests that are generated as part of the Control Scope process are used as inputs into which process?
A.
The Validate Scope process
B.
The Perform Integrated Change Control process
C.
The Control Quality process
D.
The Plan Scope Management process
Answers
This section contains the answers for the Exercises and Review Questions in this chapter.
Exercises
1.
Create a WBS.
Your completed WBS should look like the diagram shown in Figure 3-5. Did you remember to include the unique number identifiers in each node?
Figure 3-5.
A completed work breakdown structure for Project BlueTalk
2.
Map each of the following terms on the left to the definition that best fits it on the right:
a) Project charter | vi. The foundational document for a project, which contains a high-level description of the work to be completed |
b) Statement of work | iv. A narrative description of the work to be completed; used as an input into the project charter |
c) Requirements | v. The documented list of expectations and specifications from project stakeholders |
d) Preliminary scope statement | i. An early iteration of the project scope statement |
e) Project scope statement | ii. A description of all the work to be done on a project |
f) Product scope | iii. A description of the product, service, or result to be delivered as part of the project work |
Review Questions
1.
Correct Answer: C
A.
Incorrect: Plan Scope Management is the first process to be completed so that you have a guide to completing the others.
B.
Incorrect: Define Scope comes after Collect Requirements.
C.
Correct: The sequence of Plan Scope Management, Collect Requirements, Define Scope, Create WBS describes the iterative development of Project Scope Management processes.
D.
Incorrect: Plan Scope Management is the first process to be completed so that you have a guide to completing the others.
2.
Correct Answer: C
A.
Incorrect: The project scope management plan and requirements documentation are not part of the scope baseline.
B.
Incorrect: The project scope management plan is not part of the scope baseline.
C.
Correct: The scope statement, the WBS, and the WBS dictionary are the three elements of the scope baseline.
D.
Incorrect: The project scope statement and the product scope statement are a part of but not all of the scope baseline.
3.
Correct Answer: A
A.
Correct: The requirements management plan describes how project requirements will be analyzed, documented, and managed.
B.
Incorrect: The scope management plan describes how the project scope will be defined, documented, and managed.
C.
Incorrect: The project scope statement describes the scope of work to be done as part of the project.
D.
Incorrect: The scope baseline is made up of the scope statement, WBS, and WBS dictionary.
4.
Correct Answer: D
A.
Incorrect: Group decision-making techniques are techniques to assist groups of people in making decisions in the face of differing, and often dissenting, opinions.
B.
Incorrect: Observations do not require brainstorming.
C.
Incorrect: Facilitated workshops describe focused workshops.
D.
Correct: Brainstorming is an example of a group creativity technique.
5.
Correct Answer: C
A.
Incorrect: The requirements traceability matrix does not hold people accountable for work delivery.
B.
Incorrect: Letting stakeholders know when the project will be delivered would be part of your time management plan and communications management plan.
C.
Correct: The main purpose of the requirements traceability matrix is to map individual requirements back to specific business needs and objectives.
D.
Incorrect: The project scope statement is used to describe the work to be completed in the project.
6.
Correct Answer: B
A.
Incorrect: The project scope includes all the work and only the work to be done, including a description of the product.
B.
Correct: The product scope is a subset of the project scope that focuses specifically on the product or deliverable of the project.
C.
Incorrect: The project scope is not delivered as part of the delivery of the product scope; it is the other way around.
D.
Incorrect: There is a difference between the two terms, because they describe different things.
7.
Correct Answer: C
A.
Incorrect: The deliverable is a high-level description of the work to be done.
B.
Incorrect: Project activities are work packages that are further defined and used in developing a project schedule.
C.
Correct: The work package is the lowest level of WBS decomposition.
D.
Incorrect: The scope statement describes all the work to be done on the project.
8.
Correct Answer: B
A.
Incorrect: The scope management plan describes how the project scope will be defined, documented, and managed.
B.
Correct: The WBS dictionary provides additional information to expand on the summary information contained in each node of the WBS.
C.
Incorrect: The project scope statement describes all the work to be done on the project.
D.
Incorrect: The requirements documentation describes individual requirements for the project.
9.
Correct Answer: D
A.
Incorrect: The Validate Scope process is not simply an internal process.
B.
Incorrect: The process of checking whether the deliverable conforms to requirements is a Control Quality process.
C.
Incorrect: The Change Management process describes the process of managing changes to the project scope statement.
D.
Correct: The Validate Scope process is a process that involves internal and external stakeholders checking that the deliverable meets project requirements and stakeholder expectations.
10.
Correct Answer: B
A.
Incorrect: Change requests are an output from the Validate Scope process.
B.
Correct: Change requests are used as an input into the Perform Integrated Change Control process.
C.
Incorrect: Approved change requests, which are change request that have been through the Perform Integrated Change Control process, are used as an input into the Control Quality process.
D.
Incorrect: Change requests are not an input into the Plan Scope Management process.