Project Management

Week 3:
Project Scope Management
- WBS

Tran Van Ly
Industrial and Systems Engineering
International University
21/10/08 1
Email: [email protected]
 Recall previous week
• Knowledge Area

2
 Recall previous week

Project deliverables can be:

 A document  Equipment

 A product  Software

 A result ©® An approval
3
 Recall previous week
2. Project Charter

4
Learning Objectives

• Scope
• Work Breakout Structure

5
 INTRODUCTION

• Project Scope Management

includes the processes
required to ensure that the
project includes all the work
required, and only the work
required, to complete the
project successfully.
• Managing the project scope
is primarily concerned with
defining and controlling
what is and is not included
in the project.
Example of your study program

Your study in IU

Planning 1 2 3 4

Course Course Course Course

Finance Living Thesis
s s s s

Art & Sport Networking Accommodation Transportation

 INTRODUCTION

• In the project context, the term scope can refer to:

– Product scope: The features and functions that
characterize a product, service, or result.
– Project scope: The work that needs to be accomplished
to deliver a product, service, or result with the specified
features and functions.
• The approved detailed project scope statement
and its associated WBS and WBS dictionary are the
scope baseline for the project.
 COLLECT REQUIREMENTS
• Collect Requirements is the process of defining and documenting
stakeholders’ needs to meet the project objectives.
• Requirements include the quantified and documented needs and
expectations of the sponsor, customer, and other stakeholders.
• Requirements can be categorized into:
– Project requirements: business requirements, project management
requirements, delivery requirements, etc.
– Product requirements: information on technical requirements, security
requirements, performance requirements etc.
COLLECT REQUIREMENTS
 COLLECT REQUIREMENTS:
INPUTS
• Project Charter:
– provide the high-level project requirements and high-level product
description of the project so that detailed product requirements can be
developed.
• Stakeholder Register:
– used to identify stakeholders that can provide information on detailed
project and product requirements.
– contains all details related to the identified stakeholders including:
• Identification information: Name, organizational position, location, role in the
project, contact information;
• Assessment information: Major requirements, main expectations, potential
influence in the project, phase in the life cycle with the most interest;
• Stakeholder classification: Internal/external, supporter/neutral/resistor, etc.
 COLLECT REQUIREMENTS:
TOOLS & TECHNIQUES
• Interviews
– a formal or informal approach to discover information from stakeholders
by talking to them directly.
– typically performed by asking prepared and spontaneous questions and
recording the responses.
– Interviewing experienced project participants, stakeholders, and subject
matter experts can aid in identifying and defining the features and
functions of the desired project deliverables.
• Focus groups
– bring together prequalified stakeholders and subject matter experts to
learn about their expectations and attitudes about a proposed product,
service, or result.
– interactive discussion, designed to be more conversational than a one-
on-one interview.
 COLLECT REQUIREMENTS:
TOOLS & TECHNIQUES
• Facilitated Workshops
– focused sessions that bring key cross-functional stakeholders together to
define product requirements.
– well-facilitated sessions can build trust, foster relationships, and improve
communication among the participants which can lead to increased
stakeholder consensus.
– issues can be discovered and resolved more quickly than in individual
sessions.
 COLLECT REQUIREMENTS:
TOOLS & TECHNIQUES
• Group Creativity Techniques:
– Brainstorming: generate and collect multiple ideas related to project and
product requirements.
– Nominal group technique: enhances brainstorming with a voting process
used to rank the most useful ideas for further brainstorming or for
prioritization.
– The Delphi Technique: A selected group of experts answers questionnaires
and provides feedback regarding the responses from each round of
requirements gathering. The responses are only available to the facilitator
to maintain anonymity.
– Idea/mind mapping: Ideas created through individual brainstorming are
consolidated into a single map to reflect commonality and differences in
understanding, and generate new ideas.
– Affinity diagram: allows large numbers of ideas to be sorted into groups for
review and analysis.
 COLLECT REQUIREMENTS:
TOOLS & TECHNIQUES
• Group Decision Making Techniques
– an assessment process of multiple alternatives with an expected
outcome in the form of future actions resolution.
– used to generate, classify, and prioritize product requirements.
• Unanimity: Everyone agrees on a single course of action.
• Majority: Support from more than 50% of the members of the group.
• Plurality: The largest block in a group decides even if a majority is not
achieved.
• Dictatorship: One individual makes the decision for the group.
 COLLECT REQUIREMENTS:
TOOLS & TECHNIQUES
• Questionnaires and Surveys
– written sets of questions designed to quickly accumulate information
from a wide number of respondents.
– most appropriate with broad audiences, when quick turnaround is
needed, and where statistical analysis is appropriate.
• Observations
– a direct way of viewing individuals in their environment and how they
perform their jobs or tasks and carry out processes.
– particularly helpful for detailed processes when the people that use
the product have difficulty or are reluctant to articulate their
requirements.
 COLLECT REQUIREMENTS:
TOOLS & TECHNIQUES
• Prototypes
– a method of obtaining early feedback on requirements by providing a
working model of the expected product before actually building it.
– allows stakeholders to experiment with a model of their final product
rather than only discussing abstract representations of their requirements.
– progressive elaboration with iterative cycles.
 COLLECT REQUIREMENTS:
OUTPUTS
• Requirements Documentation
– Describes how individual requirements meet the business need for the
project.
– Requirements must be measurable, testable, traceable, complete,
consistent, and acceptable to key stakeholders.
– The format of a requirements document may range from a simple
document listing all the requirements categorized by stakeholder
and priority, to more elaborate forms containing executive summary,
detailed descriptions, and attachments.
 COLLECT REQUIREMENTS:
OUTPUTS
• Requirements Management Plan
– The requirements management plan documents how requirements
will be analyzed, documented, and managed throughout the project.
• How requirements activities will be planned, tracked, and reported;
• Configuration management activities such as how changes to the product,
service, or result requirements will be initiated, how impacts will be
analyzed, how they will be traced, tracked, and reported, as well as the
authorization levels required to approve these changes;
• Requirements prioritization process;
• Product metrics that will be used and the rationale for using them;
• Traceability structure, that is, which requirements attributes will be
captured on the traceability matrix and to which other project documents
requirements will be traced.
 COLLECT REQUIREMENTS:
OUTPUTS
• Requirements Traceability Matrix
– a table that links requirements to their origin and traces them throughout
the project life cycle.
– help to ensure that each requirement adds business value by linking it to
the business and project objectives.
– help to ensure that requirements approved in the requirements
documentation are delivered at the end of the project.
– Attributes associated with each requirement can be recorded in the
requirements traceability matrix to define key information about the
requirements.
 DEFINE SCOPE

• Define Scope is the process of developing a detailed description

of the project and product.
• The preparation of a detailed project scope statement is critical
to project success and builds upon the major deliverables,
assumptions, and constraints that are documented during
project initiation.
DEFINE SCOPE
 DEFINE SCOPE: INPUTS

• Project Charter:
– provides the high-level project description and product characteristics
– contains project approval requirements
• Requirements Documentation
• Organizational Process Assets
– Policies, procedures, and templates for a project scope statement
– Project files from previous projects
– Lessons learned from previous phases or projects
 DEFINE SCOPE:
TOOLS & TECHNIQUES
• Expert judgment
– Often used to analyze the information needed to develop the project
scope statement.
– Applied to any technical details.
– Provided by any group or individual with specialized knowledge or
training, and is available from many sources.
• Product Analysis
– For projects that have a product as a deliverable, product analysis can
be an effective tool.
– Translating high-level product descriptions into tangible deliverables.
– Product analysis includes techniques such as product breakdown,
systems analysis, requirements analysis, systems engineering, value
engineering, and value analysis.
 DEFINE SCOPE:
TOOLS & TECHNIQUES
• Alternatives Identification
– A technique used to generate different approaches to execute and
perform the work of the project.
– Brainstorming, lateral thinking, pair wise comparisons…
• Facilitated Workshops
 DEFINE SCOPE: OUTPUTS

• Project Scope Statement

– Describes, in detail, the project’s deliverables and the work
required to create those deliverables.
– Provides a common understanding of the project scope
among project stakeholders.
– Enables the project team to perform more detailed planning
– Guides the project team’s work during execution
– Provides the baseline for evaluating whether requests for
changes or additional work are contained within or outside
the project’s boundaries.
 DEFINE SCOPE: OUTPUTS

• Project Scope Statement (cont.)

– The detailed project scope statement includes, either directly, or by
reference to other documents, the following:
• Product scope description.
• Product acceptance criteria.
• Project deliverables.
• Project exclusions.
• Project constraints.
• Project assumptions.
• Project Document Updates
– Stakeholder register
– Requirements documentation
– Requirements traceability matrix
 CREATE WORK BREAKDOWN
STRUCTURE
• The work breakdown structure (WBS) is
– A deliverable-oriented hierarchical decomposition of the work
– Create the required deliverables
– Each descending level of the WBS representing an increasingly detailed
definition of the project work.
• The WBS organizes and defines the total scope of the project,
and represents the work specified in the current approved
project scope statement.
 CREATE WBS – Why?
• WBS can take a wide variety of forms and serve a wide variety of
purposes:
– Illustrate how each piece of the project contributes to the whole in terms
of performance, responsibility, budget, and schedule.
– If the PM wishes, list the vendors or subcontractors associated with
specific tasks.
– Be used to document that all parties have signed off on their various
commitments to the project.
– Note detailed specifications for any work package, establish account
numbers, specify hardware/software to be used, and identify resource
needs.
– Serve as the basis for making cost estimates or estimates of task duration.
 CREATE WBS – How?

• The WBS structure can be created in a number of

forms, such as:
– Using phases of the project life cycle as the first level of
decomposition, with the product and project deliverables
inserted at the second level
– Using major deliverables as the first level of decomposition
– Using subprojects which may be developed by organizations
outside the project team, such as contracted work. The
seller then develops the supporting contract work
breakdown structure as part of the contracted work.
 CREATE WBS:
INPUTS
• Create WBS is the process
of subdividing project
deliverables and project
works into smaller, more
manageable components.
• Inputs:
– Project Scope
Statement
– Requirements
Documentation
– Organizational
Process Assets
 CREATE WBS:
TOOLS & TECHNIQUES
• Decomposition:
– Decomposition is the subdivision of project deliverables
into smaller, more manageable components until the work
and deliverable are defined to the work package level.
– The work package level is the lowest level in the WBS, and
is the point at which the cost and the activity durations for
the work can be reliably estimated and managed.
– Decomposition may not be possible for a deliverable or
subproject that will be accomplished far into the future.
WBS by phases of the project
 CREATE WBS:
TOOLS & TECHNIQUES
• Decomposition: (cont.)
– Decomposition of the total project work into work packages
generally involves the following activities:
• Identifying and analyzing the deliverables and related work,
• Structuring and organizing the WBS,
• Decomposing the upper WBS levels into lower level detailed
components,
• Developing and assigning identification codes to the WBS
components,
• Verifying that the degree of decomposition of the work is
necessary and sufficient.
 CREATE WBS: OUTPUTS

• Work breakdown structure.

• WBS dictionary:
– A document generated by the Create WBS process to support WBS.
– Provides more detailed descriptions of the components in the WBS,
including work packages and control accounts.
• Scope baseline: a component of the project management plan.
Components of the scope baseline include: Project scope statement, WBS,
and WBS dictionary.
• Project document updates:
– Project documents that may be updated include, but are not limited to
requirements documentation.
– If approved change requests result from the Create WBS process, then
the requirements documentation may need to be updated to include
approved changes.
SOW – WBS - Dictionary
 Notes

• The 100% Rule: the WBS:

– Includes 100% of the work defined by the project scope.
– Captures all deliverables – internal, external, interim – in terms of the
work to be completed, including project management.
• Mutually exclusive:
– It is important that there is no overlap in scope definition between
two elements of a WBS.
• Level of detail.
– The "80 hour rule“: no single activity or group of activities to produce
a single deliverable should be more than 80 hours of effort.
– No activity or series of activities should be longer than a single
reporting period.
Work Breakdown Structure (WBS)

• A basic tool in project management

• A framework for defining all project work
elements and their relationships, collecting
and organizing information, developing
relevant cost and revenue data, and
management activities.
• Each level of a WBS divides the work
elements into increasing detail.
 A WBS has other characteristics

• Both functional and physical work elements

are included.
• The content and resource requirements for
a work element are the sum of the
activities and resources of related sub-
elements below it.
• A project WBS usually includes recurring
and nonrecurring work elements.
 Integrated Approach for
Developing the Cash Flows for
Alternatives
Accuracy of Cost and Revenue Estimates
versus the Cost of Making Them
TABLE P3-27 Work Breakdown
Structure for Problem 3-27
 TABLE P3-27 (continued) Work
Breakdown Structure for Problem
WBS for Commercial Building
 Review/Home work: WBS-Thesis

51
Create WBS and WBS dictionary