FIT426 . Project Management .

Lecture 5

SCOPE MANAGEMENT
What is it?
 Scope is all the work involved in delivering the
project objectives
 Includes the processes used to create them.
 A deliverable is a product produced as part of the
project (includes planning documents, or meeting
minutes)
 Scope management is the processes involved in
defining and controlling “what is” or “is not”
included in a project
Scope Management Process

WBS Verificatio
Planning Definition Control
Creation n
Figure 5-1. Project Scope Management Summary

4
Collect Requirement
 Uses techniques to gather and define requirements to
meet the needs, wants and expectations of the
stakeholders.
Inputs Tool & Techniques Outputs
1 Project charter 1 Interviews 1 Requirements
2 Stakeholder register 2 Focus groups documentation
3 Facilitated workshops 2 Requirements
4 Group creativity techniques management plan
5 Group decision making 3 Requirements traceability
techniques matrix
6 Questionnaires and surveys
7 Observations
8 Prototypes

Adapted from PMBOK® Guide, Fourth Edition

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol
Project Charters
 After deciding what project to work on, it is
important to let the rest of the organization
know
 A project charter is a document that formally
recognizes the existence of a project and
provides direction on the project’s objectives
and management
 Key project stakeholders should sign a project
charter to acknowledge agreement on the need
and intent of the project; a signed charter is a
key output of project integration management
Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

6
 Inputs

1. Project Statement of Work (SOW) 2. Business Case

 Narrative description of project’s products or  Documents why the project is
services needed
 Describes product scope  Provides the project justification
and cost-benefit analysis

3. Contract
4. Enterprise Environmental Factors
 Organizational culture, structure
 Governmental and industry standards, including
regulations
 Existing human resources
 Personnel administration systems and policies
 Company work authorization system
 Project Management Information System (PMIS)
5. Organizational Process Assets
 Standard project life cycles
 Quality policies and procedures
 Financial controls
 Configuration management and
change control processes
 Risk management processes
 Historical information

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

7
Tool & Techniques
 Interview: Sitting down with stakeholders one-on-one to
get them to explain exactly what they need so that you can be
sure your project can meet its goals
 Focus Groups
 Get a group of people to discuss their needs with you
 A Focus Group requires a facilitator to guide the
conversation and to document the results
 Facilitated Workshops
 More structured group conversations where a moderator
leads the group through brainstorming requirements
together
 Group Creativity Techniques
 Brainstorming. A technique used to generate and collect
multiple ideas related to project and product requirements
 Nominal group technique. Allows a group to convert a long
list of ideas into smaller list of ideas with the greatest
potential
 Mind map. A good way to visualize your ideas relate to each
other to reflect commonality and differences in
understanding, and generate new ideas
 Delphi Technique. A way of letting everyone in the group
give their thoughts about what should be in the product
while keeping them anonymous
 Group Decision-Making techniques
 Unanimity. Everyone must agree on the solution
 Majority. More than half of the group must agree on the
solution
 Plurality. The idea that gets the most votes wins
 Dictatorship. One person makes the decision for the whole
group
 Questionnaires and Survey Use a questionnaire and/or
survey to get requirements from a bigger group of users,
customers, or stakeholders
 Observation
 Observes an end user performing the tasks to be analyzed in the end
user’s own environment
 Prototypes
 Prototypes are models of the product that you’re going to
build that let your stakeholders get a better idea to elicit
requirements more effectively
 Outputs

1. Project Charter
 Project’s purpose or justification
 Measurable project objectives
 High-level requirements and description of product
 High-level risks
 Summary schedule of milestones
 Budget summary
 Approval requirements
 Project manager and sponsor responsibility and authority

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

11
Table 4-1. Project Charter for the DNA-Sequencing Instrument Completion Project

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

12
Table 4-1. Charter (continued)

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

13
Documenting Requirements
 A requirements management plan describes how project
requirements will be analyzed, documented, and managed
 A requirements traceability matrix (RTM) is a table that lists
requirements, various attributes of each requirement, and
the status of the requirements to ensure that all
requirements are addressed

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

14
Table 5-1. Sample Requirements Traceability Matrix

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

15
Scope Definition

 Basis for creating “Project Scope Statement”

 Preliminary scope statement
 Project charter
 Organizational process assets
 Approved change requests
 As time progresses, the scope of a project
should become clearer and more specific

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol
 Outputs
1. Project Scope Statement
 Describes the project’s deliverables and the work needed to create those
deliverables
 Components of the Project Scope Statement
 Project objectives
 Product scope description
 Product acceptance criteria
 Project deliverables
 Project boundaries
 Project constraints and assumptions
 …
2. Project Document Updates
 Any change with project requirements documentation need to be noted
and tracked back to the project objectives via the requirements traceability
matrix
Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

17
Scope Statement (cont’d)

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol
Creating the WBS
 WBS is a
 deliverable-oriented grouping of the work (involved in
a project)
 foundation document for planning and managing
project schedules, costs, resources, and changes
 Way to define the total scope of the project
 A scope is therefore a decomposition of the
project goals
 Decomposition is the sub-division of the project
deliverables into smaller pieces
 A work package is a task at the lowest level of the WBS
Pla De WB
S
Ver Co
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol
Figure 5-3. Sample Intranet WBS
Organized by Product

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

20
Figure 5-4. Sample Intranet WBS
Organized by Phase

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

21
Figure 5-5. Intranet WBS and Gantt Chart in
Microsoft Project

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

22
Figure 5-6. Intranet Gantt Chart Organized by
Project Management Process Groups

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

23
Table 5-4. Executing Tasks for JWD Consulting’s
WBS

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

24
WBS Example 1 by Tasks

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol
WBS Example by Process Groups

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol
Approaches to Developing WBSs

 Some organizations provide guidelines for

preparing WBS
 Approaches
 Analogy
 Top-down
 Bottom-up
 Mind-mapping

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol
More about WBS

 Many WBS tasks are vague and need further

elaboration so
 People know what to do
 Can estimate how long the work will take
 What it will cost.
 A WBS dictionary is the document that
elaborates the above
 Scope baseline = Project scope statement +
WBS + WBS dictionary Pla
nn
ing
De
fini
tio
n
WB
S
Cre
atio
n
Ver
ific
ati
on
Co
nt
rol
Advice for Creating a WBS and WBS Dictionary

 A unit of work should appear at only one place in

the WBS
 The work content of a WBS item is the sum of the
WBS items below it
 A WBS item is the responsibility of only one
individual, even though many people may be
working on it
 The WBS must be consistent with the way in which
work is actually going to be performed; it should
serve the project team first and other purposes
only if practical
Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

30
Advice for Creating a WBS and WBS Dictionary (continued)

 Project team members should be involved in

developing the WBS to ensure consistency and buy-
in
 Each WBS item must be documented in a WBS
dictionary to ensure accurate understanding of the
scope of work included and not included in that item
 The WBS must be a flexible tool to accommodate
inevitable changes while properly maintaining
control of the work content in the project according
to the scope statement
Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

31
Scope Verification

 Very difficult to create a good scope

statement and WBS for a project
 Even more difficult to verify project scope and
minimize scope changes
 Many project suffer from
 Scope creep
 Poor scope verification

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol
Improving Verification

 Develop a good project selection process and

insist that sponsors are from the user
organization
 Hold regular meetings with users
 Deliver something on a regular basis
 Always under promise and over deliver
 Co-locate users with developers
Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol
 Outputs
1. Accepted Deliverables
 If the work done right, the stakeholders will formally accept the
deliverables
 Deliverables that are not accepted must be documented with the
reasons. It is a useful component of the lesson learned and audit trail of
the project
2. Change Requests
 When two or more requirements are in conflict, or when a requirement
was incorrectly specified, change requests are required and processed
using a Perform Integrated Change Control
3. Project Document Update
 Verify Scope can result in necessary updates to requirements
documents, quality documents, and scope statements

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

34
Scope Control

 Involves controlling changes to the project

scope
 Goals of scope control are to
 Influence the factors that cause scope changes
 Ensure changes are processed according to
procedures developed as part of integrated change
control
 Manage changes when they occur
 Variance is the difference between planned
Pla
nn
De
fini
WB
S
Cre
Ver
ific
Co
nt
tio ati

and actual performance

atio
ing n n on rol
Reducing Incomplete and Changing
Requirements

 Develop (and follow) a requirements

management process
 Use techniques such as prototyping, use case
modeling, and JAD to get more user
involvement
 Put requirements in writing and keep them
current
De WB Ver Co

 Create a requirements management DB to

Pla S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

document and control requirements

Reducing Incomplete and Changing
Requirements (cont’d)

 Conduct adequate testing throughout lifecycle

 Review changes from a systems perspective
 Emphasize completion dates
 Allocate resources to handle change requests
and enhancements

Pla De WB Ver Co
S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol
Output
 Work Performance Measurements
 Show planned versus actual performance or other scope performance
measurements
 Organizational Process Assets Updates
 Description of the variance causes
 Corrective actions chosen and rational
 Lessons learned
 Change Request
 Variances from the approved scope baseline may generate change requests
 Project Management Plan Updates
 Scope baseline updates
 Other baseline updates
De WB Ver Co
 Project Document Updates
Pla S
fini ific
nn tio
Cre
ati nt
atio
ing n n on rol

 Requirements documents
Summary
 Scope management includes
 Work required to be done
 Processes to do the work (and only those work)
 There are software to assist scope management
 Read accompanying textbook slides