Effective Project Management:

Traditional, Agile, Extreme, Hybrid

8th Edition

Ch06: How to Scope a TPM Project

Presented by
(facilitator name)
 Ch06: How to Scope a TPM Project

Summary of Chapter 6

 Using tools, templates, and processes to scope a TPM

project
 Managing client expectations
 Project scoping process
 Project scoping meeting & deliverables
 Requirements breakdown structure (RBS)
 Project classification
 Choosing the best fit PMLC Model
 Project Overview Statement
 Ch06: How to Scope a TPM Project

Tools, Templates & Processes used to Scope a Project

 Conditions of Satisfaction
 Project Scoping Meting
 Requirements Elicitation
 Brainstorming
 Facilitated Group Sessions
 Interviews
 Prototyping
 Requirements Workshops
 Project Overview Statement
 Approval to Plan the Project
 Ch06: How to Scope a TPM Project

Client Wants vs. Client Needs Dilemma

NEEDS

WANTS

What your client wants may not be what your client needs.
Your job is to make sure that what they want is what they
need and that you will deliver what they need.
 Ch06: How to Scope a TPM Project

Tips to Managing Client Expectations During Scoping

 Make sure you understand what your client
wants/needs/expects
 Make sure the client understands what you will do
 Assure yourself that what your client wants is what
your client needs
 Actively include your client in scoping the project
 Put yourself in the shoes of your client
 Meaningfully involve your client wherever possible
 Keep your client informed of project status
 Ch06: How to Scope a TPM Project

Project Scoping Process

 Ch06: How to Scope a TPM Project

Establishing Conditions of Satisfaction

Clarify
Request

Request Response

Agree on
Response

Negotiate agreement and

write Project Overview Statement
 Ch06: How to Scope a TPM Project

Planning and Conducting the Project Scoping Meeting

 Purpose
 Document requirements
 Project Overview Statement

 Attendees
 Project Manager
 Client Group
 Core Team Members
 The Facilitator & Technographer
 Ch06: How to Scope a TPM Project

Planning and Conducting the Project Scoping Meeting

 Agenda
 Introductions
 Purpose of the Meeting (led by Facilitator)
 COS (conduct or review if done earlier)
 Description of current state (led by client representative)
 Description of problem or business opportunity (led by client
representative)
 Description of end state (led by client representative)
 Requirements definition and documentation (led by facilitator)
 Discussion of the gap between current and end state (led by project
manager)
 Choose best fit project management approach to close the gap (led by
project manager)
 Draft and approve the POS (whole scope planning group)
 Adjourn
 Ch06: How to Scope a TPM Project

Planning and Conducting the Project Scoping Meeting

 Deliverables
 RBS creation
 Assessment of completeness of RBS
 Project classification
 Determination of best fit PMLC Model
 The POS
 Ch06: How to Scope a TPM Project

What Are Requirements?

A requirement is something the product/project should

do/produce or a quality that it must have.
 Ch06: How to Scope a TPM Project

Requirement – A Business Value Perspective

Requirement
A requirement is a desired end-state whose successful
integration into the solution meets one or more needs and
delivers specific, measurable, and incremental business value
to the organization.

Furthermore the set of high-level requirements forms a

necessary and sufficient set for the attainment of incremental
business value.
 Ch06: How to Scope a TPM Project

Building the Requirements Breakdown Structure

NOTE:
 Requirements #1 through #n form
a necessary & sufficient set for
attaining expected business value
 Not all levels are required.
 Ch06: How to Scope a TPM Project

Building the Requirements Breakdown Structure

Project goal
and solution

Requirement 1 Requirement n

Function Function Function Function Function Function

1.1 1.2 1.3 n.1 n.2 n.3

Sub-function Sub-function Sub-function

1.2.1 1.2.2 1.2.3

Feature Feature Feature Feature Feature Feature Feature Feature

1.2.1.1 1.2.1.2 1.2.1.3 1.2.1.4 n.3.1 n.3.2 n.3.3 n.3.4
 Ch06: How to Scope a TPM Project

Stakeholder Interaction in Requirements

 Ch06: How to Scope a TPM Project

Approaches to Requirements Gathering

 Brainstorming
 Facilitated Group Sessions
 Interviews
 Prototyping
 Requirements Workshop

NOTE: These approaches can be used for decomposition too:

 The RBS is most meaningful to the client
 The RBS is deliverables-based
 The RBS is consistent with the PMBOK
 The RBS is client-facing
 The RBS is the higher order part of the WBS
 Ch06: How to Scope a TPM Project

Brainstorming

Strengths
1. Reduces social inhibitions
2. Stimulates idea generation
3. Increases overall creativity of the group

Risks
1. Can be dominated by a strong individual
2. Individual fear of being criticized
3. Evaluation of ideas
 Ch06: How to Scope a TPM Project

Facilitated Group Session Method

Strengths
1. Excellent for cross-functional processes
2. Detailed requirements are documented and verified
immediately
3. Resolves issues with an impartial facilitator

Risks
1. Untrained facilitators can lead to negative responses
2. Time and cost of planning and executing can be high
 Ch06: How to Scope a TPM Project

Interview Method

Strengths
1. End-user participation
2. High-level description of functions and processes provided

Risks
1. Descriptions may differ from actual detailed activities
2. Without structure, stakeholders may not know what information
to provide
3. Real needs ignored if analyst is prejudiced
 Ch06: How to Scope a TPM Project

Prototyping

Strengths
1. Innovative ideas can be generated
2. Users clarify what they want
3. Users identify requirements that may be missed
4. Client –focused
5. Early proof of concept
6. Stimulates thought process

Risks
1. Client may want to implement prototype
2. Difficult to know when to stop
3. Specialized skills required
4. Absence of documentation
 Ch06: How to Scope a TPM Project

Requirements Workshop

Strengths
1. Good way for first-time use

Risks
1. May overwhelm customer
 Ch06: How to Scope a TPM Project

Categories of Requirements

 Functional
 Non-functional
 Global
 Product/project constraints
 Ch06: How to Scope a TPM Project

Definition: Functional Requirement

Functional requirements specify what the product or

service must do.

Give an example of a functional requirement.

 Ch06: How to Scope a TPM Project

Definition: Non-Functional Requirement

Non-functional requirements demonstrate properties

that the product or service should have in order to do
what must be done.

Give an example of a non-functional requirement.

 Ch06: How to Scope a TPM Project

Definition: Global Requirement

Global requirements describe the highest level of

requirements within the system or product. They can be
thought of as general requirements.

Give an example of a global requirement.

 Ch06: How to Scope a TPM Project

Definition: Product/Project Constraints

Product/project constraints are those requirements that,

on the surface, resemble design constraints or project
constraints.

Give an example of a product/project constraint.

 Ch06: How to Scope a TPM Project

RBS – The Reality

Project goal
and solution

Requirement 1 Requirement n

Functional
Function Function Function Function Requireme Function
Function
1.1 1.2 1.3 n.1 n.2nt n n.3

Sub-function Sub-function Sub-function

1.2.1 1.2.2 1.2.3

Feature Feature Feature Feature Feature Feature Feature Feature

1.2.1.1 1.2.1.2 1.2.1.3 1.2.1.4 n.3.1 n.3.2 n.3.3 n.3.4
 Ch06: How to Scope a TPM Project

Characteristics of the RBS

 The RBS is intuitive and most meaningful to the

client
 The RBS is a deliverables based approach
 The RBS is consistent with the PMI PMBOK
 The RBS remains client facing as long as possible
into the planning exercise
 Ch06: How to Scope a TPM Project

Advantages of using the RBS

 Does not require a trained facilitator
 Does not require learning one of the contemporary approaches
to requirements gathering
 Presents an intuitive approach to gathering requirements
 Allows the client to work with the project team in an
environment familiar to them, i.e., to stay in their own comfort
zone
 Paints a clear picture of the degree to which the solution is
clearly defined
 Provides the input needed to choose the best fit PMLC Model
 Ch06: How to Scope a TPM Project

The Challenge of Requirements Management

 Many different types of requirements at different levels

of detail
 Requirements are not independent of one another and
may create conflict situations
 Many interested and responsible parties with different
needs
 Change as a result of changing business conditions
 Can be time-sensitive
 Shuttle diplomacy to resolve differences
 Assess completeness of requirement decomposition
 Ch06: How to Scope a TPM Project

Hints in Deciding which PMLC Model to Use

 The degree to which the RBS is complete is the major

factor in deciding which PMLC Model to use.
 Consider using the highest level of decomposition in
the Objective section of the POS and leaving creation
of the RBS and WBS for the Planning Phase.
 The highest level requirements could be those that
deliver business value. Senior managers might prefer
this.
 Ch06: How to Scope a TPM Project

When to use each PMLC Model

PMLC Model Type When to Use It
Linear The solution and requirements are clearly defined.
You do not expect too many scope change requests.
The project is routine and repetitive.
You can use established templates.
Same conditions as the Linear approach, but the client wants to deploy
Incremental
business value incrementally.
There may be some likelihood of scope change requests.
Iterative You feel that requirements are not complete or may change.
You will learn about remaining requirements in the course of doing the project.
Some features of the solution are not yet identified.
Adaptive The solution and requirements are only partially known.
There may be functionality that is not yet identified.
There will be a number of scope changes from the client.
The project is oriented to new product development or process improvement.

The development schedule is tight and you can’t afford rework or re-planning.
Extreme The goal and solution are not clearly known.
The project is an R & D type project.
 Ch06: How to Scope a TPM Project

Purpose of the Project Overview Statement

A one-page description that is:

 A general statement of the project

 A reference for the planning team
 A decision aid for the project
 To get management approval to plan the project

Ss
PO
 Ch06: How to Scope a TPM Project

Contents of the Project Overview Statement

 Ch06: How to Scope a TPM Project
Project Name Project No. Project Manager
PROJECT
OVERVIEW Office Supply Cost Reduction PAUL BEARER
STATEMENT

Example POS
Problem/Opportunity

Our cost reduction task force reports that office supply expenses have exceeded budget by an
average of 4% for each of the last three fiscal years. In addition an across the board budget cut of
2% has been announced and there is an inflation rate of 3% estimated for the year.

Goal

To implement a cost containment program that will result in office supply expenses being within
budget by the end of the next fiscal year.

Objectives

1. Establish a departmental office supply budgeting and control system.

2. Implement a central stores for office and copying supplies.
3. Standardize the types and brands of office supplies used by the company.
4. Increase employee awareness of copying practices that can reduce the cost of
meeting their copying needs.

Success Criteria

1. The total project cost is less than 4% of the current year office supply budget.
2. At least 98% of office supply requests are filled on demand.
3. At least 90% of the departments have office supply expenses within budget.
4. No department office supply expense exceeds budget by more than 4%.

Assumptions, Risks, Obstacles

1. Central stores can be operated at or below the breakeven point.

2. Users will be sensitive to and supportive of the cost containment initiatives.
3. Equitable office supply budgets can be established.
4. Management will be supportive and consistent.
5. The existing inventory control system can support the central stores operation.

Prepared By Date Approved By Date

Olive Branch 9/2/04 Del E. Lama 9/3/04

 Ch06: How to Scope a TPM Project

POS Problem/Opportunity

A problem needing resolution or an

untapped business opportunity.

A statement of fact that everyone

would agree to. It stands on its own.

This is the foundation on which the

proposed project will be based.
 Ch06: How to Scope a TPM Project

POS Project Goal

A one or two sentence statement of

how you intend to address the stated
problem/opportunity.

A scoping statement that bounds the

project you are proposing.
 Ch06: How to Scope a TPM Project

POS Project Objectives

 5 or 6 brief statements that further bound your project goal.

 From these statements it is clear what is inthe proposed project.

 These statements might identify major project deliverables.

 These statements form a necessary and sufficient set of objectives.

Under what conditions might you consider using the

high-level requirements as the project objectives?
 Ch06: How to Scope a TPM Project

POS Project Success Criteria

IRACIS
IR Increasing Revenue
AC Avoiding Cost
IS Improving Service

Use quantitative metrics only!

How much and by when?
 Ch06: How to Scope a TPM Project

POS Assumptions, Risks and Obstacles

 Technological
 New to the company
 Obsolescence
 Environmental
 Management change
 Staff turnover
 Interpersonal
 Working relationships
 Cultural
 Fit to the company
 Causal Relationships
 Will the solution solve the problem
 Ch06: How to Scope a TPM Project

POS Attachments
 Risk Analysis
 Financial Analyses
 Feasibility studies
 Cost/benefit analysis
 Breakeven analysis
 Return on inverstment
 Ch06: How to Scope a TPM Project

Gaining Approval to Plan the Project

 Expected Review Questions from Management
 How important is the problem or opportunity to the organization?
 How is the project related to our CSFs?
 Does the goal statement related directly to the problem or opportunity?
 Are the objectives clear representations of the goal statement?
 Is there sufficient business value as measured by the success criteria to warrant further expenditures on this
project?
 Is the relationship between the project objectives and the success criteria clearly established?
 Are the risks too high and the business value too low?
 Can senior management mitigate the identified risks?
 Ch06: How to Scope a TPM Project

Participants in the Approval Process

 Core project team
 Project team
 Project manager
 Resource managers
 Function/process managers
 Client
 Senior management