Project Management

Chapter7.HolisticScopePlanning.pptx

Home >Business & Finance homework help >Management homework help >Project Management

Chapter 7

Holistic Scope Planning

Kloppenborg | Anantatmula | Wells, Contemporary Project Management: Plan-Driven and Agile Approaches, 5th Edition. © 2023 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.

‹#›

Key Learnings (Purpose of this slide)

To introduce this chapter.

Presenter Notes

References

n/a

Icebreaker

What are two things you learned from Stakeholder Analysis and Communication Planning?

‹#›

Key Learnings (Purpose of this slide)

To engage participants in the content of this chapter.

Presenter Notes

References

Pressmaster/Shutterstock.com

Holistic Scope Planning (1 of 2)

‹#›

Key Learnings (Purpose of this slide)

To describe the Scope Planning process.

Presenter Notes

References

n/a

Holistic Scope Planning (2 of 2)

Overview of the Book

7.1 Plan Scope Management

7.2 Collect Requirements

7.3 Define Scope

7.4 Work Breakdown Structure (WBS)

7.5 Establish Change Control

7.6 PMBOK Guide 7e

7.7 Agile Projects

7.8 Summary

‹#›

Key Learnings (Purpose of this slide)

To list the components covered in “Holistic Scope Planning” chapter.

Presenter Notes

References

n/a

Core Objectives

7-1 Describe the planning of scope management and collecting requirements.

7-2 Define scope processes.

7-3 Create a requirements traceability matrix, project scope statement, and change request form.

7-4 Describe a work breakdown structure (WBS) and its importance to planning and control.

7-5 Compare different methods of developing a WBS.

7-6 Create a WBS, including work packages and a numbering system both by hand and using MS Project.

‹#›

Key Learnings (Purpose of this slide)

To describe the Core Objectives.

Presenter Notes

References

n/a

Agile Objectives

7-7 Use simplicity and emergent design in developing scope.

7-8 Capture user requirements as stories.

7-9 Create backlogs for a sprint and a release.

‹#›

Key Learnings (Purpose of this slide)

To describe Agile Objectives.

Presenter Notes

References

n/a

7.1 Plan Scope Management (1 of 2)

Plan Scope Management

Scope Planning Flow

‹#›

Key Learnings (Purpose of this slide)

To list the components covered in “Plan Scope Management” section.

Presenter Notes

References

n/a

7.1 Plan Scope Management (2 of 2)

Plan Scope Management is the process of developing a plan that includes the total scope of what needs to be done and what is excluded from the project; implementation and validation of the scope; and how to control deviations from the scope statement.

Total Scope = Product Scope + Project Scope

Product Scope outputs the team will deliver to its customers

Project Scope

the work needed to be performed in order to deliver the project’s outputs

‹#›

Key Learnings (Purpose of this slide)

To define Plan Scope Management and what is meant by “Total” scope.

Presenter Notes

When planning scope, it is also wise to plan for changes.

The project team also needs to determine the project scope, which is the work required to be performed for delivering a product, service, or result with the required features and functions.

Together, the product scope (the outputs the team will deliver to its customers) and the project scope (the work they need to perform to create the project’s outputs) form the total scope of a project.

The project team members determine what they will do to ensure they have identified and organized all the project work, which is the basis of all other planning activities and also the basis for executing and controlling the project work.

References

n/a

Exhibit 7.1

‹#›

Key Learnings (Purpose of this slide)

To illustrate the flow of scope planning.

Presenter Notes

References

Exhibit 7.1: Scope Planning Flow.

7.2 Collect Requirements

7.2a Ensure Clarity of Objectives

7.2b Gather Stakeholder Input and Needs

7.2c Define Needs as Requirements

‹#›

Key Learnings (Purpose of this slide)

To list the components covered in “Collect Requirements” section.

Presenter Notes

A requirement is a condition or capability needed by the client or a user to solve a problem or achieve an objective that satisfies a standard, a specification, or any other formally documented need.

Collecting requirements is a systematic effort to understand and analyze stakeholder needs to define and document these requirements.

This will help in refining and meeting project objectives.

References

n/a

7.2a Clarity of Project Objectives

Collect Requirements to ensure that the project team is clear on the project objectives.

Describe in more depth what the expected project benefits are and/or what problems the project is attempting to overcome.

Understand the project’s objectives helps in revising the project plan later, if necessary.

‹#›

Key Learnings (Purpose of this slide)

To define Collect Requirements and reinforce that the project team must be clear on the project objectives.

Presenter Notes

The project team members may describe in more depth what the expected project benefits are and/or what problems the project is attempting to overcome.

Understanding broad project objectives will help in making more-detailed decisions later.

References

n/a

7.2b Voice of the Customer

Use voice of the customer techniques (VOC).

Ask questions.

Place yourself in the customer’s situation.

State customer desires in operational terms.

‹#›

Key Learnings (Purpose of this slide)

To describe ways to collect requirements.

Presenter Notes

New product development projects, teams often use voice of the customer (VOC) techniques to elicit the benefits and features the customers want from the project outcomes, expressed in the customer’s language.

Collecting requirements is same regardless of type of project.

Generally Agile documentation is less formal, they allowing for progressive elaboration.

Good project managers know that for a project to be successful, its outcomes must be useful to the project’s clients and their customers (end-users).

References

n/a

7.2b Common Methods for Obtaining and Documenting Requirements

Meetings with Stakeholders

Interviews

Focus Groups

Questionnaires

Surveys

Observations

Prototypes

Industry Standards

Reference Documents

Market Analysis

Competitive Analysis

Client Requests

Standard Specifications

‹#›

Key Learnings (Purpose of this slide)

To provide examples of common methods for obtaining and documenting requirements.

Presenter Notes

The methods of developing a deep understanding of customers and their needs vary extensively from one industry to another.

References

n/a

7.2c Guiding Questions to Gather Input

Seek a high-level description:

What do we not understand about the feature?

What is the business reason for the feature?

What is the impact of not providing this feature?

What action items need to be accomplished if we do this?

What impact will this have on other features of the project or elsewhere?

‹#›

Key Learnings (Purpose of this slide)

To provide some guiding questions for how to gather Stakeholder input and needs.

Presenter Notes

Requirements can be classified as functional/technical and nonfunctional.

The first category is usually the focus of needs assessment exercises and is centered on the performance of the deliverable—such as the mechanic’s needs just described.

The second category includes characteristics of requirements such as scalability, reliability, maintainability, and testability.

The Project Manager needs to understand how a project’s success will be determined from the customer’s perspective.

The best way to gain this understanding (and to begin building a strong relationship with customers) is to directly ask customers for clarification.

The project leaders can ask the customer(s) to specify how they will judge the quality of the product or service based on both functional and nonfunctional requirements.

References

n/a

Exhibit 7.2 (1 of 2)

Requirements Traceability Matrix

Id	Requirement	Acceptance Criteria	Type	Status	Stakeholder Group(S)	Priority	Objectives
1	The BA must be able to customize the information collected for requirements.		Stakeholder	Approved	BA	Must	PO#1
1.1	The system shall allow for the renaming of requirement attributes.	BA can rename an existing field. Field displays the new name on input forms. Field displays the new name on reports.	Functional	Approved	BA	Must	PO#1
1.2	The system shall allow new requirement fields to be identified.	BA on adding a new field. BA can set field attributes. BA can indicate field lookup values. Custom field amiable for input. Custom field rabble for reports.	Functional	Approved	BA	Should	PO#1
1.3	The system shall allow new requirement fields to be identified.	BA can enter a custom list of lookup value. Lookup fields can be provided from an external system through data interface.	Functional	Approved	BA	Should	PO#1

‹#›

Key Learnings (Purpose of this slide)

To describe a Traceability Matrix.

Presenter Notes

Gather requirements along with other related information such as acceptance criteria for each requirement, which can be either high level or very detailed using specifications in measurable terms, using a Traceability Matrix.

The requirement type suggests whether the requirement is functional, nonfunctional, or needed by a particular stakeholder.

The traceability matrix also includes the status of the requirement, its priority, and who is responsible for the requirement.

References

Exhibit 7.2: Requirements Traceability Matrix.

Source: Vicki James, PMP, CBAP, PMI-PBA, CSM, author of Leveraging Business Analysis for Project Success. 15734_ch07_rev01_239-275.indd 245 21/03/22 4:18 PM

Exhibit 7.2 (2 of 2)

Requirements Traceability Matrix

2	The BA must be SA to provide different reports for different audiences.		Stakeholder	Approved	BA. Team. Sponsor. Stakeholders	Must	PO#1
2.1	The system shall include a base set of standard reports.	Reports include: Requirements Traceability Matrix Business Requirements Documents	Functional	Approved	BA. Team. Sponsor. Stakeholders	Must	PO#1
2.2	The system shall allow a business analyst to filter reports based on various requirement attributes.	BA can filter a report based on Type Stakeholder Status Priority Objective	Functional	Approved	BA	Should	PO#1
2.3	The system shall provide an option to download data to an Excel-supported file so the BA can customize.	BA can select to extract data to an Excel supported file Extracted data is formatted as a tabular data set with no row breaks	Functional	Proposed	BA	Should	PO#1
2.4	The system shall allow for the customization of reports to include filtering and displayed fields.	BA can select fields to include or exclude in the resulting report. BA can filter reports (see 2.2.1).	Functional	Approved	BA	Should	PO#1

BA — Business Analyst (BA) is a person responsible for defining what will bring value to the business, ensuring requirements are fully vetted and understood, and that the solution meets expectations.1

PO#1 — Project Objective #1: “record, manage, communicate, and update requirements so that requirements can be captured once and then managed and communicated efficiently.”

Priority uses MoSCoW ratings — Must be included in the release (mandatory), Should be included in the release (highly desired), Could be included in the release (nice to have), Won’t be included in the release (out of scope)

Source: Vicki James, PMP, CBAP, PMI-PBA, CSM, author of Leveraging Business Analysis for Project Success.

‹#›

Key Learnings (Purpose of this slide)

To describe a Traceability Matrix.

Presenter Notes

The requirement type suggests whether the requirement is functional, nonfunctional, or needed by a particular stakeholder.

The traceability matrix also includes the status of the requirement, its priority, and who is responsible for the requirement.

References

Exhibit 7.2: Requirements Traceability Matrix.

Source: Vicki James, PMP, CBAP, PMI-PBA, CSM, author of Leveraging Business Analysis for Project Success. 15734_ch07_rev01_239-275.indd 245 21/03/22 4:18 PM

Exhibit 7.3

Requirements Translated into Specifications

Requirements	Specifications
Unambiguous—not subject to interpretation	Unique set—each stated only once
Complete—nothing left out	Normalized—should not overlap
Consistent—no conflicts, which also means no duplication	Linked set—shows relationships
Modifiable—amenable to change	Complete—nothing left out
Traceable—to a customer need	Consistent—no conflicts
Verifiable—means provided to verify the requirement	Bounded—specifies nonnegotiable constraints
	Modifiable—amenable to change
	Configurable—traceable changes
	Granular—right level of abstraction

Adopted from: ISO IEEE IEC (2018)

‹#›

Key Learnings (Purpose of this slide)

To describe how requirements are translated into specifications.

Presenter Notes

References

Exhibit 7.3: Requirements Translated into Specifications.

Source: Adopted from: ISO IEEE IEC (2018).

7.2c Profile of Complete Requirements

Traceable back to its business reason.

Identified with the Stakeholder(s)’ needs.

Unambiguous.

Qualified by measurable conditions.

Validated for its value and completion.

Bounded by constraints.

Prioritized according to value, cost, time, risk, or mandate to make trade-off decisions if needed.

‹#›

Key Learnings (Purpose of this slide)

To describe how requirements are translated into specifications.

Presenter Notes

References

n/a

7.3 Define Scope

7.3a Reasons to Define Scope

7.3b How to Define Scope

‹#›

Key Learnings (Purpose of this slide)

To list the components covered in “Define Scope” section.

Presenter Notes

References

n/a

7.3a Reasons to Define Scope

Define scope is the process of translating Stakeholder needs and requirements into detailed specifications of the project outcomes and products.

The project Scope Statement includes three things:

What to deliver to the project Stakeholders at the end of the project.

What work must be done to create the deliverables.

What will limit or influence the project work.

‹#›

Key Learnings (Purpose of this slide)

To provide reasons to define scope.

Presenter Notes

Scope, or total scope, is the sum of product scope and project scope, considering exclusions, constraints, and assumptions.

While the requirements represent the customers’ statement of what they need, the defined scope is the project team’s response.

References

n/a

7.3a Scope Creep

Scope definition also is vital in preventing scope creep, which happens for two common reasons:

Scope is not clearly defined and agreed upon.

Customer is excited about the process and innocently asks for more.

‹#›

Key Learnings (Purpose of this slide)

To provide explain scope creep.

Presenter Notes

In contemporary business, pleasing the customer is desirable.

However, the best time to gain customer understanding is when the project team is defining the scope—not while executing the project scope work.

References

n/a

7.3b How to Define Scope

List project deliverables

Determine acceptance criteria

Establish project boundaries

In scope versus Out of scope

Understand constraints

Create a Scope Definition

‹#›

Key Learnings (Purpose of this slide)

To list the steps to define scope.

Presenter Notes

Scope definition can vary greatly from one project to another.

For a small, routine construction project, it may be quite simple to determine project outputs and the work involved in creating them.

On other projects, such as one large company acquiring another, it may be difficult to determine the total amount of work.

Regardless of how easy or difficult it may be to define scope and despite industry-specific methods that may help, all project teams must complete each part of this scope planning process.

References

n/a

Exhibit 7.4 (1 of 2)

Scope Statement

Project: Mezquital Valley Project: Socio-Political Dynamics in Northern Mesoamerica. January 2019.

Project Work Statement: To understand the components of the Acahualzingo altepetl (prehispanic socio-political unit) as one of the northern-most political units of the Mesoamerican geopolitical concept, while gaining advancement in the definition of activity areas in said polity through a systematic surface survey, with total coverage and pinpoint explorations.

Key Deliverables	Acceptance Criteria
Report to the Archaeology Council authorities	Reports, registries, and analysis by Project members. Approval from the Archaeology Council, National Anthropology and History Institute, Mexico (INAH)
Next season’s project, delivered to the Archaeology Council	Detailed research for an upcoming project (field season), including resources needed, schedules, etc. Approved by the Archaeology Council
Written report of activities, analyses, inventory, etc. by Students	Written report presented before project’s director and approved
Publication(s)	Approved draft for publication (article, book chapter, etc.)

‹#›

Key Learnings (Purpose of this slide)

To provide an example of a Scope Statement.

Presenter Notes

A project scope statement guides the project team during subsequent planning and execution.

For some very small projects, a well-developed project Charter could also serve as a Scope Statement.

On most projects, a scope statement needs to be developed before the development of the WBS.

References

Exhibit 7.4: Scope Statement.

Exhibit 7.4 (2 of 2)

Exclusions: This has been an ongoing project site for over 34 years, so currently the only possible exclusions considered would be denial from the local authorities and population to carry on the proposed surveys and research. In that case, a secondary research area would have to be proposed.

Constraints: The main logistical constraints for the project are the relatively “reduced” number of students allowed to participate. Although this is to guarantee a close follow-up and mentorship of the students, focused on them developing the necessary skills to carry on proper surface survey abilities, it also means taking a hit on the number of areas and overall reach of the season’s field work.

Assumptions: All students participating are assumed of legal age and administratively in order with the College programs. (At this point the field trip was carried out just days before the pandemic declaration and nationwide lockdowns due to COVID-19.)

Source: Rodrigo Villanova, PhD, author of Project Management for Archeology.

‹#›

Key Learnings (Purpose of this slide)

To provide an example of a Scope Statement.

Presenter Notes

A project scope statement guides the project team during subsequent planning and execution.

For some very small projects, a well-developed project Charter could also serve as a Scope Statement.

On most projects, a scope statement needs to be developed before the development of the WBS.

References

Exhibit 7.4: Scope Statement.

7.4 Work Breakdown Structure (WBS)

7.4a What Is the WBS?

7.4b Why Use a WBS?

7.4c WBS Formats

7.4d Work Packages

7.4e How to Construct a WBS

‹#›

Key Learnings (Purpose of this slide)

To list the components covered in “Work Breakdown Structure (WBS)” section.

Presenter Notes

After scope definition is complete, the Project Manager will have greater clarity about project work and milestones as compared to the high-level understanding of the project when the project Charter is defined.

The milestones defined in the project charter are not necessarily accurate due to a lack of complete understanding of the total project work at the time it was created.

It is important to note that the project Charter must be seen as an authorization document with an accuracy of estimates (cost and time) in the range of  50% or more.

With the definition of scope, more details about the project are available to develop the WBS and new milestones, and then time and cost estimate accuracy levels increase considerably.

A detailed understanding of the project scope and work to be performed must be simplified for execution, and it is essential to divide the total work into smaller, manageable elements.

A tool that is used on virtually all traditional projects is the WBS.

To understand this tool, we will first define it, tell why it is important, show common formats, and then demonstrate the steps required to construct a WBS.

References

n/a

7.4a What Is the WBS?

A project planning tool defined as the hierarchical decomposition of the project scope into deliverable work elements at the lowest level.

Helps develop an optimum project schedule and cost estimates at the work element level.

Define activity is a project-planning process that identifies and determines specific actions to develop and deliver the project outcomes, such as products, services, or results.

‹#›

Key Learnings (Purpose of this slide)

To define the Work Breakdown Structure.

Presenter Notes

The WBS is a framework that is used as a basis for further planning, execution, and control.

Typically, the WBS is created after the scope is defined on large projects.

In contemporary project management, particularly on small- and middle-sized projects, the WBS may be created concurrently with the scope statement.

To clearly distinguish between the work processes of WBS development and activity development, WBS development is covered in this chapter, and activity development is covered as part of project scheduling.

References

n/a

7.4b Why Use a WBS?

Ensures all parts of project are considered.

Adds discipline and visibility to project planning.

Basis for planning schedule, resources, cost, quality, and risk.

Useful in determining where and why problems occur.

Helpful in project communications.

‹#›

Key Learnings (Purpose of this slide)

To describe why you use a Work Breakdown Structure.

Presenter Notes

If a problem occurs during project execution, the WBS is helpful in understanding exactly where and why the problem occurred.

This helps to diagnose problems, manage the quality of the project deliverables, and keep all the other facets of the project on schedule while the isolated problem is fixed.

References

n/a

7.4c WBS Formats

A WBS usually has one or more intermediate levels (frequently called interim deliverables).

All levels of the WBS with at least one level below are considered summary levels.

The completion of summary-level elements is based upon the completion of all levels underneath.

‹#›

Key Learnings (Purpose of this slide)

To explain Work Breakdown Structure formats.

Presenter Notes

References

n/a

Exhibit 7.5

House WBS in Indented Outline Format

House

Project Management

Framed House

Foundation

Custom Framing Design

Wood

Assembled Frame

Wired House

Wiring Design

Wiring

Installed Wiring

Drywalled House

Drywall Drawing

Drywall

Hung Drywall

‹#›

Key Learnings (Purpose of this slide)

To provide an example of a WBS in the Indented Outline Format.

Presenter Notes

The WBS is useful when typing WBS into scheduling software.

References

Exhibit 7.5: House WBS in Indented Outline Format.

Exhibit 7.6

‹#›

Key Learnings (Purpose of this slide)

To provide an example of a WBS in the Free Format.

Presenter Notes

References

Exhibit 7.6: WBS in Free Format.

7.4d Work Packages (1 of 2)

Work Packages are the lowest level of the WBS for which cost and duration can be estimated and managed. They are the basis for subsequent planning and control.

The Work Package is the point from which:

Work activities are defined.

Schedule is formed.

Resources are aligned.

Control features are developed.

‹#›

Key Learnings (Purpose of this slide)

To define Work Packages.

Presenter Notes

The lowest level is known as a work package, which is usually the work component at the lowest level of the WBS, for which cost and duration can be estimated and managed.

Work packages are detailed enough to facilitate further planning and control.

For ease of communication and comprehension, work packages and other components of a WBS are usually stated in one to three words; one should avoid verbs and instead use adjectives to describe WBS elements at all levels.

References

n/a

Exhibit 7.7

Source: Kevin P. Grant, UTSA.

‹#›

Key Learnings (Purpose of this slide)

To provide an illustration of a WBS with Work Package.

Presenter Notes

References

Exhibit 7.7: WBS Depicting Work Packages.

Source: Kevin P. Grant, UTSA.

7.4d Work Packages (2 of 2)

WBS Component is “an entry in the WBS that can be at any level.”

-PMBOK® Guide

WBS Dictionary is a document that provides detailed information about every work package, including deliverable details; activity; scheduling information; predecessor and successor activities; person responsible; resources required; and risks.

State Work Packages succinctly in very few words (use adjectives, not verbs!)

‹#›

Key Learnings (Purpose of this slide)

To define a WBS component and WBS Dictionary.

Presenter Notes

References

n/a

Exhibit 7.8

Work Package Detail

Project: Expansion to Full Scale Production	Work Package: Assembly Hardware Test
Description: Plan, conduct, evaluate, and report results of tests to ensure proper function of the assembly hardware.	Deliverable(s): Test results summary. Input(s): Assembly hardware prototype

Activities	Resource	Expected Duration	Cost
Prepare test plan	Production Analyst	8h	$ 720
Conduct test	Production Analyst	16h	1,440
Evaluate test results	Production Analyst	6h	540
Prepare test results summary	Production Analyst	8h	720
	Production Analyst		$3,420

Source: Kevin P. Grant, UTSA.

‹#›

Key Learnings (Purpose of this slide)

To provide an example of Work Package detail.

Presenter Notes

References

Exhibit 7.8: Work Package Detail.

Source: Kevin P. Grant, UTSA.

7.4e How to Construct a WBS

Include appropriate subject matter experts (SMEs).

Use a top-down approach.

Consider WBS from a previous project as a starting point.

Use brainstorming.

‹#›

Key Learnings (Purpose of this slide)

To describe the steps to begin constructing a WBS.

Presenter Notes

References

n/a

7.4e Steps in WBS Construction

Identify major deliverables.

Decompose deliverables.

Continue until deliverables are the right size.

Review.

‹#›

Key Learnings (Purpose of this slide)

To list the steps in constructing a WBS.

Presenter Notes

References

n/a

7.4e Identify Major Deliverables

Begin with Scope Statement.

Organize in systematic manner such as by project phase.

Facilitates rolling wave planning—planning near-term work in detail and future work at a higher level.

Rolling wave planning → quick start.

Helps avoid:

Analysis paralysis—never starting anything because the plan is not complete.

Ready, fire, aim—not planning at all.

‹#›

Key Learnings (Purpose of this slide)

To describe how to identify major deliverables.

Presenter Notes

References

n/a

Exhibit 7.9

WBS Organization Examples

Project Phase	Design Components/ Deliverables	Work Function/ Department
Project Management Contract Foundation Framed House	Project Management Kitchen Bedrooms Bathrooms	Project Management Carpentry Plumbing Electrical
…	…	…

‹#›

Key Learnings (Purpose of this slide)

To provide examples of WBS organization.

Presenter Notes

References

Exhibit 7.9: WBS Organization Examples.

7.4e Decompose Deliverables

Decomposition is breaking down into smaller and smaller pieces.

Brainstorm list of interim and final deliverables (use Post It® Notes).

Assemble deliverables on large workspace.

Organize deliverables into related groups.

‹#›

Key Learnings (Purpose of this slide)

To describe how to decompose deliverables.

Presenter Notes

The team members can use the top-down approach, asking what all the components of each major deliverable are.

Alternatively, the team members may use a bottom-up approach by brainstorming a list of both interim and final deliverables that need to be created.

References

n/a

Exhibit 7.10 (1 of 2)

Partial WBS of an Archeological Project

Code	Deliverable
1.0	Project Management
2.0	Budget
3.0	Surface Survey
3.1	GIS/cartographic research
3.2	Previous data recompilation
3.3	Survey logistics
3.4	Data collection (Students: each student will be responsible for all data collected in their assigned routes as the correct gathering and updating of daily team data.)
4.0	Dig
4.1	Selection of dig areas
4.2	Stratigraphic registry
4.3	Dig and material handling
4.4	Photographic records

‹#›

Key Learnings (Purpose of this slide)

To provide an example of deliverables—broken down to the “right” size.

Presenter Notes

Once it is determined to be complete, the team can ask if the deliverables at the lowest level need to be divided further for planning and control.

References

Exhibit 7.10: Partial WBS of an Archeological Project.

Source: Rodrigo Villanova, PhD, author of Project Management for Archeology.

Exhibit 7.10 (2 of 2)

Partial WBS of an Archeological Project

Code	Deliverable
5.0	Special Data Collection (Surface survey and drone handling)
5.1	Sample proposal
5.2	Sample collecting
5.3	Special analysis
6.0	Archaeological materials handling and storage
6.1	Inventory
6.2	Conservation efforts and storage
6.3	Lab analysis

Source: Rodrigo Villanova, PhD, author of Project Management for Archeology.

‹#›

Key Learnings (Purpose of this slide)

To provide an example of deliverables—broken down to the “right” size.

Presenter Notes

Once it is determined to be complete, the team can ask if the deliverables at the lowest level need to be divided further for planning and control.

References

Exhibit 7.10: Partial WBS of an Archeological Project.

Source: Rodrigo Villanova, PhD, author of Project Management for Archeology.

7.4e Review

Ensure completeness

Consider parent-child concept

Have between three and nine child elements for each parent

Assign a unique name and number to each component

‹#›

Key Learnings (Purpose of this slide)

To describe reviewing process.

Presenter Notes

References

n/a

Exhibit 7.11 (1 of 2)

Library Project WBS with Components Numbered

Library Project

Project Management

Facility Needs

2.1 VISION STATEMENT

2.2 STAKEHOLDER INPUT

2.3 OPTIONS

Building Proposal

3.1 RECOMMENDED SIZE AND SCOPE

3.2 SITING

3.3 COST RATIONALE

Building Approval

4.1 VP OF FINANCE APPROVAL

4.2 PRESIDENT APPROVAL

4.3 BOARD APPROVAL

Staff Education

5.1 LITERATURE REVIEW

5.2 LIBRARY VISITS

5.3 SUPPLIER INPUT, PROCESS, OUTPUT, CUSTOMER ANALYSIS

5.4 TRAINING

‹#›

Key Learnings (Purpose of this slide)

To provide an example of a WBS with components numbered.

Presenter Notes

The team also assigns a unique number to each component. In one common numbering system, the number for a child item starts with the number assigned to its parent and an additional digit.

References

Exhibit 7.11: Library Project WBS with Components Numbered.

Exhibit 7.11 (2 of 2)

Fundraising

6.1 POTENTIAL DONOR LIST

6.2 RELATIONSHIP BUILDING WITH POTENTIAL DONORS

6.3 EDUCATION OF POTENTIAL DONORS

6.4 DONATIONS

6.5 FOLLOW-UP WITH DONORS

Building Documents

7.1 FACILITY AND SITE SPECIFICATIONS

7.2 SCHEMATIC DESIGNS

7.3 DEVELOPMENT PLANS

7.4 CONTRACT DOCUMENTS

Building Construction

8.1 ARCHITECT

8.2 CONTRACTORS

8.3 CONSTRUCTION

8.4 FURNISHINGS

Building Acceptance

9.1 BUILDING AND GROUNDS ACCEPTANCE

9.2 BUILDING OCCUPANCY

9.3 BUILDING DEDICATION

9.4 WARRANTY CORRECTIONS

‹#›

Key Learnings (Purpose of this slide)

To provide an example of a WBS with components numbered.

Presenter Notes

The team also assigns a unique number to each component. In one common numbering system, the number for a child item starts with the number assigned to its parent and an additional digit.

References

Exhibit 7.11: Library Project WBS with Components Numbered.

Exhibit 7.12

Stakeholder Analysis and WBS at the CIA

At the CIA, where I created and run our agency-wide project management training and certification program, I come in contact with large numbers of dedicated project managers. With enrollment averaging about 2,500 students per year, I encounter a workforce with a broad spectrum of experiences, skills, and expectations. One of the more prevalent expectations is associated with stakeholder analysis and communication; employees invariably feel that they pretty much know most or all they need to know in this area and may even begrudge somewhat the three days associated with our Project Communications Management course. What they discover are the shortcomings in their appreciation for and knowledge about project communications. Using a five-point Likert scale, we have every student perform a self-assessment of their communications proficiency prior to and after the class. To the students’ surprise, proficiency increases average a full point; student feedback virtually always includes statements to the effect that they didn’t realize just how much more effective they can be in project management by investing more in the project communications area.

The organizational chart plays a central role in how the CIA approaches the analysis of stakeholders. Employees learn through classroom exercises to use the organizational chart as a roadmap for identifying the stakeholders. As they march through the branches in this chart, they make conscious decisions about whether the function represented by the title or box on the chart or whether the individual performing that function is a stakeholder. Once they have identified the stakeholders and performed the associated stakeholder analysis, they then turn to the WBS to help with the planning and implementation of the communications tasks that follow. In fact, communications for the types of projects undertaken at the CIA have taken on such importance that we advocate it be placed at the first level of WBS decomposition alongside equally important components such as project management. For projects of sufficient size, a full-time leader is often assigned to the communications component; the scope of their duties includes communications within the project as well as communications outside the project.

Source: Michael O’Brochta, PMP, director, PPMC Program, CIA.

‹#›

Key Learnings (Purpose of this slide)

To provide an example of a Stakeholder analysis and the WBS.

Presenter Notes

Different organizations develop their own unique variations of project planning and control techniques (as shown in this example), which combines Stakeholder analysis and the WBS.

References

Exhibit 7.12: Stakeholder Analysis and WBS at the CIA.

Source: Michael O’Brochta, PMP, director, PPMC Program, CIA.

7.5 Establish Change Control (1 of 2)

Change Control System/Baseline

Change Request/Change Request Form

‹#›

Key Learnings (Purpose of this slide)

To list the components covered in “Establish Change Control” section.

Presenter Notes

References

n/a

7.5 Establish Change Control (2 of 2)

Projects are conducted in an atmosphere of uncertainty.

Plans must be made to ensure all potential changes are considered, accepted, or rejected, and that their impact is factored into revised plans.

Change Control System is a system of managing and controlling changes and modifications to the project plan and project deliverables.

Baseline is the approved project plan, mostly consisting of scope, schedule, and cost; should not be altered without going through integrated change control system.

‹#›

Key Learnings (Purpose of this slide)

To describe how to establish change control.

Presenter Notes

References

n/a

7.5 Change Request

Change Request is a written request or formal proposal to change any project planning component, such as a document, project deliverable, or the baseline (scope, cost, and time).

‹#›

Key Learnings (Purpose of this slide)

To define a Change Request.

Presenter Notes

Document potential changes to a project with a Change Request.

Every change to a project must be formally proposed.

References

n/a

Exhibit 7.13

Change Request Form

	Originator:	Project #:
Date
Description of change:
Why needed:
Impact on project scope:
Impact on deadline dates:
Impact on budget:
Impact on quality:
Impact on risk:
Impact on team:
Date approved:
Project manager	Sponsor	Customer
_______________	_______________	_______________

‹#›

Key Learnings (Purpose of this slide)

To provide a Change Request Form template.

Presenter Notes

Change Request forms typically include several sections.

The top section lists basic information to track the change request to the project and to the person who submitted it.

The second section contains two simple statements describing the change and the justification for the proposed change.

The third section details the anticipated impact on the project baseline from the potential change and this requires time and effort to assess these impacts.

This can vary in length from a simple check and comment section.

References

Exhibit 7.13: Change Request Form.

7.6 PMBOK Guide 7e

7.6a Team

7.6b Development Approach

7.6c Planning

7.6d Delivery

7.6e Measurement

7.6f Uncertainty

‹#›

Key Learnings (Purpose of this slide)

To list the components covered in “PMBOK Guide 7e” section.

Presenter Notes

References

n/a

7.6a Team

Teams must work productively with Stakeholders in spite of diversity and irrespective of virtual means of communication.

Within the team, it is desirable to have a safe, non-judgmental environment that provides transparency, integrity, respect, positive dialogue, support, and courage while working on scope planning.

‹#›

Key Learnings (Purpose of this slide)

To describe teams.

Presenter Notes

To develop an effective scope plan, it is essential that the project team work together with key stakeholders by establishing a culture of collaboration.

References

n/a

7.6b Development Approach

The key factor that differentiates predictive and adaptive development approaches is the uncertainty associated with requirements.

When uncertainty and risks are associated with defining requirements or volatility exists in requirements, an adaptive (incremental or iterative) development approach is preferred.

‹#›

Key Learnings (Purpose of this slide)

To describe development approach.

Presenter Notes

In a predictive approach, scope can be defined with less ambiguity at the start of the project.

References

n/a

7.6c Planning

In a predictive planning approach, it is possible to define high-level deliverables and then decompose them via a WBS down to an activity level.

When requirements are unclear, an adaptive approach is used for planning, and high-level themes or epics are used to develop features that are further decomposed into stories and backlog items.

‹#›

Key Learnings (Purpose of this slide)

To describe planning.

Presenter Notes

Deliverables influence scope planning.

This approach would reduce waste.

References

n/a

7.6d Delivery

WBS is used in a predictive plan approach to define details in definite terms.

Themes are developed, When requirements are associated with uncertainty.

Epics may be decomposed into features that are sets of requirements.

User Story(ies) is a brief description of an outcome for a specific user.

‹#›

Key Learnings (Purpose of this slide)

To describe delivery.

Presenter Notes

Scope is the sum of all deliverables and work needed to produce them.

References

n/a

7.6e Measurement

Baseline parameters are used in a predictive development approach for measurement.

Promised business value and benefits are measured in an adaptive approach (and these are becoming relevant for even the predictive approach).

‹#›

Key Learnings (Purpose of this slide)

To describe measurement.

Presenter Notes

If scope planning identifies requirements unambiguously, completion of requirements can be assessed using acceptance criteria, technical performance measures, and “definition of done.”

References

n/a

7.6f Uncertainty

Ambiguity, volatility, complexity, and risk are some of the factors which, if associated with requirements, would compel the project team to employ an adaptive approach.

In a predictive approach, aim to minimize uncertainty further with a detailed project plan and Risk Management plan.

‹#›

Key Learnings (Purpose of this slide)

To describe measurement.

Presenter Notes

Uncertainty is associated with requirements can be a hindrance to developing an effective scope plan.

References

n/a

7.7 Agile Projects (1 of 2)

Plan-Driven vs. Agile Methods

7.7a Agile Terms Used in Holistic Scope Planning

Set Up a WBS in MS Project

‹#›

Key Learnings (Purpose of this slide)

To list the components covered in “Agile Projects” section.

Presenter Notes

References

n/a

7.7 Agile Projects (2 of 2)

The Agile team starts with the project Vision and then develops an understanding of customers and their desires.

Various Stakeholders may identify anything they want, and those items are added to a wish-list called a Product Backlog.

‹#›

Key Learnings (Purpose of this slide)

To describe Agile Projects.

Presenter Notes

With Agile projects, the Project Manager is focused on providing value to customers quickly, maintaining flexibility to meet changing business needs, and adding new requirements identified by Stakeholders rather than on finalizing scope definition quickly.

Scope is not initially clear to either the project team or the client.

References

n/a

Exhibit 7.14

Plan-Driven vs Agile Methods for Holistic Scope Planning

Holistic Scope Planning Questions	Plan-Driven	Agile
How are requirements defined?	Extensive requirements early	Emergent design using progressive elaboration
Who leads scoping?	Project manager	Product owner
How is work organized?	Work breakdown structure	Release and sprint backlogs
What is the most detailed output?	Work package	User stories based upon personas
How are changes handled?	Baseline and change-control system	Sprints after which a pivot or cancellation may occur

‹#›

Key Learnings (Purpose of this slide)

To illustrate the plan-driven vs. Agile methods for holistic scope planning.

Presenter Notes

References

Exhibit 7.14: Plan-driven vs. Agile Methods for Holistic Scope Planning.

7.7a Agile Terms Used in Holistic Scope Planning

Term	Description
Simplicity	Do what is needed and no more, take small simple steps, use the sheerest possible design to meet today’s requirement..
Extra Features	Extras not used by the customer add cost and failure possibility.
Extra Processes	Steps such as extra documentation or planning that add no value.
Progressive Elaboration	First defining simply, then adding detail as needed.
Savage Summary	The briefest description of an idea or tool to help people understand it.
Story Map	Visual with product features on top and supporting detail below.
Release Backlog	The work that is planned to be completed in the current release.
Sprint Backlog	The work that is committed to be completed in the current sprint.
MoSCoW	Prioritization technique of must, should, could, and will not have.
Persona	Fictional username and description of expected user of deliverables.
User Story	Need to be described by who wants it, how they will use it and why.
Definition of Ready	Agreement that team understands a story enough to bring into a sprint.
Pivot	Changing direction on next sprint based upon customer desires.

‹#›

Key Learnings (Purpose of this slide)

To list Agile terms used in holistic scope planning.

Presenter Notes

References

Source: Anantatmula, V., and T. Kloppenborg, Be Agile Do Agile (New York, NY: Business Expert Press: 2021).

Set Up a WBS in MS Project

Setting up a WBS in MS Project has five basic steps:

1. Understand the WBS definitions and displays.

2. Enter project deliverable and work package elements.

3. Create the outline of your WBS.

4. Insert a WBS code identification column.

5. Hide (or show) the desired amount of detail in the WBS.

‹#›

Key Learnings (Purpose of this slide)

To list the five basic steps in setting up a WBS in MS Project.

Presenter Notes

The WBS is one of the most important and powerful project planning tools available to the Project Manager.

It is one of the key building blocks on which all further project activities are based.

By creating a WBS in MS Project, the Project Manager lays the foundation for automating many other planning and communication tools the software has to offer.

References

n/a

Step 1: Understand the WBS Definitions and Displays

Summary tasks are the main or interim WBS deliverables and are displayed in bold font.

Subtasks are all the tasks that make up the deliverables (work packages) and are indented below their parent summary task.

WBS tasks can also be viewed in Gantt views with different graphical shapes:

For instance, a summary task might also be a milestone that you would want to denote graphically in your Gantt chart (typically a diamond in MS Project).

‹#›

Key Learnings (Purpose of this slide)

To understand the WBS definitions and displays.

Presenter Notes

You will see these graphical representations in future tutorials.

References

n/a

Exhibit 7.16

Source: Microsoft product screenshots reprinted with permission from Microsoft Corporation.

‹#›

Key Learnings (Purpose of this slide)

To understand the WBS definitions and displays.

Presenter Notes

MS Project refers to WBS task elements as summary tasks, tasks, and subtasks and displays them in an indented outline table format.

References

Exhibit 7.16: Enter Summaries (Deliverables).

Source: Microsoft product screenshots reprinted with permission from Microsoft Corporation.

Step 2: Enter WBS Elements (Tasks)

In the Task Name field, select the row below where you want the new row to be (after making your selection, holding the SHIFT key and selecting a different row will highlight all rows between the two selections and result in that number of blank rows being inserted in the next step).

Click Task Tab>>Insert Group>>Task. a. Alternatively, you can Right-Click>>Insert Task.

You will see a new row (or rows if you added multiple) with the words in the Task Name field. Click on and enter the name of the desired WBS element (you may have to delete before typing in your new task name).

Repeat these processes as needed to enter additional tasks between the Suburban Park Homes milestones until your WBS looks like Exhibit 7.16.

‹#›

Key Learnings (Purpose of this slide)

To describe how to enter WBS elements (tasks).

Presenter Notes

References

n/a

Exhibit 7.17

Source: Microsoft product screenshots reprinted with permission from Microsoft Corporation.

‹#›

Key Learnings (Purpose of this slide)

To illustrate features WBS task elements added from Suburban Homes project milestone list.

Presenter Notes

In this WBS example, the existing milestones will double as the main deliverables (summary tasks).

References

Exhibit 7.17: Indent and Outdent Controls on the Task Tab.

Source: Microsoft product screenshots reprinted with permission from Microsoft Corporation.

Step 3: Create the Outline for Your WBS

Click the Task Name field of the row to be indented.

Task Tab>>Schedule Group>>Indent Task (right Green Arrow). a. The task element above the indented task(s) becomes a summary row as indicated by bold font. b. Indenting a summary row will also indent its lower-level items. c. Multiple rows under a summary row can be indented (or outdented) at the same time by Shift-Click selecting all of them before clicking the Indent control.

Clicking Task Tab>>Schedule Group>>Outdent Task (left Green Arrow) will similarly decrease the indentation of the selected row(s) or summary task.

Indent to create deliverables, interim deliverables, and work packages until your WBS resembles the outline shown in Exhibit 7.16.

‹#›

Key Learnings (Purpose of this slide)

To describe how to create the outline for your WBS.

Presenter Notes

You now need to set up the outline structure of the WBS to show summary tasks and subtasks (deliverables, interim deliverables, and work packages). To do this, use the Indent and Outdent controls shown in Exhibit 7.18 (Task Tab>>Schedule Group>>Green Arrows).

References

n/a

Exhibit 7.18

Source: Microsoft Corporation.

‹#›

Key Learnings (Purpose of this slide)

To illustrate how to insert selected WBS column.

Presenter Notes

References

Exhibit 7.18: Ready to Insert Selected WBS Column.

Source: Microsoft product screenshots reprinted with permission from Microsoft Corporation.

Step 4: Insert WBS Code Identifier Column

Right-click the Task Name column heading and click Insert Column.

A drop-down list appears in a new column.

From the drop-down list, choose WBS, as shown in Exhibit 7.19.

A WBS code column is now in place.

Resize the column to conserve space.

Right-click the Task Mode column heading and click Hide Column.

Your result should look like Exhibit 7.20.

‹#›

Key Learnings (Purpose of this slide)

To describe how to insert WBS code identifier column.

Presenter Notes

MS Project can automatically assign identifier codes to all your WBS tasks.

WBS codes allow the Project Team to easily categorize and communicate information about project tasks in the WBS.

In this example, WBS codes will be assigned in a new column to the left of the Task Name column.

References

n/a

Exhibit 7.19

Source: Microsoft product screenshots reprinted with permission from Microsoft Corporation.

‹#›

Key Learnings (Purpose of this slide)

To illustrate how to insert a WBS column.

Presenter Notes

References

Exhibit 7.19: WBS Column Inserted.

Source: Microsoft product screenshots reprinted with permission from Microsoft Corporation.

Step 5: Hide (or Show) Subtasks Detail

Click the tiny triangle before the task name of any summary task to hide underlying detail (all details will be “rolled-up” under the summary task).

Click the tiny triangle again to show underlying detail (all details “un-roll” under the summary task and are again visible).

‹#›

Key Learnings (Purpose of this slide)

To describe how to hide or show subtasks detail.

Presenter Notes

Some Stakeholders will not want or need to see the lower levels of WBS detail (particularly in large, complex projects with lots of WBS detail).

You can easily “roll-up” (or “un-roll”) subtasks underneath their parent summary task to hide (or show) detail.

References

n/a

Exhibit 7.20

Source: Microsoft Corporation.

‹#›

Key Learnings (Purpose of this slide)

To illustrate how to hide or show underlying detail.

Presenter Notes

In Exhibit 7.20, the underlying detail for the “Land preparation, landscape, and foundation” deliverable and the “Framing” interim deliverable summaries has been hidden.

References

Exhibit 7.20: Hide or Show Underlying Detail.

Source: Microsoft product screenshots reprinted with permission from Microsoft Corporation.

Summary

Use scope planning to determine deliverables and acceptance criteria.

Organize scope into a work breakdown structure (WBS).

Decompose the project into smaller and smaller pieces.

Assign WBS components.

Create WBS by hand or use MS Project to create WBS.

‹#›

Key Learnings (Purpose of this slide)

To provide a high-level summary of this chapter.

Presenter Notes

References

n/a

Project Management

image2.png

image1.png

image4.png

image5.png

image6.png

image7.png

image8.png

image9.png

image10.png

image11.png

image12.png

image13.png

image14.png

image15.png

image3.png