Chapter 6

Project Activity
and
Risk Planning
 Part II

Project Planning
Textbook’s Organization
Project Management
Ch. 1: Projects in
Contemporary Organizations

Project Initiation Project Planning Project Execution

Ch. 2: Strategic Management Ch. 6: Project Activity Ch. 10: Monitoring and
and Project Selection and Risk Planning Information Systems

Ch. 7: Budgeting, Estimating

Ch. 3: The Project Manager Ch. 11: Project Control
Costs and Risks

Ch. 4: Managing Conflict

Ch. 8: Scheduling Ch. 12: Project Auditing
and the Art of Negotiation

Ch. 5: The Project in the

Ch. 9: Resource Allocation Ch. 13: Project Termination
Organizational Structure

2-3
Overview

 This chapter introduces the process of project

planning, which involves identifying the specific
goals of the project and breaking them down
into achievable tasks.

 The concepts of Work Breakdown Structure

(WBS) and Linear Responsibility Chart (LRC)
are also introduced.

6-4
Initial Project Coordination and the
Project Charter

 The project launch meeting is an excellent way

to begin the planning process.

 At this meeting the team is gathered for the first

time to allow them to develop a general idea
about the requirements of the project.

6-5
Initial Project Coordination and the
Project Charter

 The intent is to present the project in general

– The team members can develop detailed plans and schedules
and present them at subsequent meetings.

 After the planning process is complete it is useful to

have a post planning review chaired by an experienced
project manager not involved with this project
previously.

6-6
Initial Project Coordination and the
Project Charter
continued

 Early meetings are used to decide on

participating in the project
 Used to “flesh out” the nature of the project
 Outcomes include:
– Technical scope
– Areas of responsibility
– Delivery dates or budgets
– Risk management group

6-7
Outside Clients

 For outside clients, specifications cannot be

changed without the client’s permission

 Client may place budget constraints on the

project

 May be competing against other firms

6-8
Project Charter Elements
Project plans have the following elements:
 Purpose: A short summary of objectives and project scope

 Objectives: A more detailed statement of the general goals of

the project that includes profit and competitive aims from the
Business Case as well as technical goals based on the Statement
of Work (SOW).

 Overview: A description of both the managerial and the

technical approaches to the work.

 Schedules: An outline of various schedules and list of all

milestone events and/or phase-gates.
continued
6-9
Project Charter Elements (continued)
 Resources: Contains budgets by task as well as cost control
and monitoring plans.

 Personnel: Contains a time phased plan for the people (or at

least the skills) required for the project.

 Risk management plans: Covers potential problems as well

as potential lucky breaks that could affect the project.

 Evaluation methods: Describes the methods used to

monitor, evaluate, and collect the history of the project.

6-10
Starting the Project Plan:
The WBS

 What is to be done?
 When it is to be started and finished?
 Who is going to do it?

6-11
Work Breakdown Structure (WBS)
 WBS, sometime referred to as the project breakdown structure
(PBS), is a hierarchical family tree of project elements.

 It is a delivery-oriented grouping of project sub-systems and task

elements.

 These task elements define the various hardware, software, and

service components of a specified project or program.

 WBS is the backbone of the project plan.

 It represents the hierarchical decomposition of the project into

subsystems and tasks.

 Each component contains at least the “triple constraints”

information of delivery, schedule, and budget.
Starting the Project Plan: The WBS
Continued

 Some activities must be done sequentially

 Some activities may be done simultaneously
 Many things must happen when and how they
are supposed to happen
 Each detail is uncertain and subjected to risk

6-13
More on WBS
The work breakdown structure (WBS) is a tool used to capture the
decomposition of activities and the assignment of personnel. The WBS is not
one thing. It can take a wide variety of forms that, in turn, serve a wide variety
of purposes. The text suggests the following steps for WBS development:
1. Break the tasks down into sufficient detail so that they can be individually
planned, budgeted, scheduled, monitored, and controlled. The tasks at the
bottom of the structure are typically called work packages.
2. Identify the relevant supporting information needed for each work package
and the people who will work them.
3. The work packages must be reviewed with the people involved to ensure
their accuracy and adequacy in describing the tasks to be accomplished.
4. The WBS can be used to capture the direct costs estimated or budgeted for
each task.
5. The summary of the schedule information associated with each work
package can be summarized into a project master schedule.
Both the planned schedule and budget for each work package can be used as
the baseline to measure performance as the project is executed.
6-14
A Form to Assist Hierarchical Planning

Figure 6-2 A form to assist hierarchical planning

Additional info. about each element of the project will be added to the
form later when budgeting and scheduling are discussed

6-15
Hierarchical Planning

 Major tasks are listed

 Each major task is broken down into
detail
 This continues until all the activities to be
completed are listed
 Need to know which activities “depend
on” other activities

6-16
A Visual WBS
Levels

Figure 6-3 Work breakdown structure (account numbers shown)

For example: The “Food” group in the “Facilities” staff has the responsibilities
for meals, drinks, including coffer breaks and water pitchers in the conference
rooms
6-17
 Career Day

Figure 6-4 Partial WBS for college “Career Day.” 6-18

Work Breakdown Structure (WBS)
• Why use a Work Breakdown Structure (WBS) at all?
• The WBS approach:
• Allows to visually see the work that is needed in order to
complete a project
• Reduces the number of surprises and improves the ability to
better estimate future projects
• Can be used to effectively decompose the project scope, to
improve estimating, to better control the project execution and
to more accurately verify project completion.
• Summarizes project information to improve the opportunity for
use of historical information, which, can aid in both speed and
accuracy of future projects.
• Is a repeatable process that can be used as a template for
future projects.

6-19
Work Breakdown Structure (WBS) Constructing a Work: 100%
House Budget: $215,500

Work: 24% Work: 45.60% Work: 30.40%

1. Foundation Budget: $46,000 2. Internal Budget: $86,000
3. External Budget: $83,500

Work: 18.20% Work: 11.80% 3. 1 Masonry Work: 16.20%

1. 1 Excavate 2. 1 Electrical
Budget: $37,000 Budget: $25,000 Work Budget: $62,000

1. 1.1 Pour Work: 7.90% 2. 1.1 Rough-in Work: 2.80% 3. 1.1 Lay Work: 9.00%
Concrete Budget: $30,000 Electrical Masonry Budget: $35,000
Budget: $5,000

1. 1.2 Cure and Work: 10.30% 2. 1.2 Install and Work: 1.90% 3. 1.2 Install Roof Work: 3.10%
Strip Forms Budget: $7,000 Test Budget: $5,000 Drains Budget: $2,000

2. 1.3 Install HVAC Work: 7.10% 3. 1.3 Install Tile in Work: 1.30%
1. 2 Erect Work: 5.80% Toilet Rooms Budget: $10,000
Equipment Budget: $15,000
Steel Frame Budget: $9,000

3. 1.4 Install Work: 2.80%

1. 2.1 Erect Steel Work: 2.80% Work:33.80% Roofing Budget: $15,000
Columns 2. 2 Plumbing Budget: $61,000
Budget: $5,000

1. 2.2 Install Steel Work: 1.90% 2. 2.1 Rough-in Work: 11.30%

3. 2 Building Work: 14.20%
Beams Budget: $2,000 Plumbing Finishes Budget: $21,500
Budget: $22,000

Work: 1.20% 2. 2.2 Set Plumbing Work: 13.20% Work: 4.00%

1. 2.3 Install Joist 3. 2.1 Paint Walls
Budget: $2,000 Fixtures and Trim Budget: $31,000 Budget: $8,000

2. 2.3 Test and Work: 9.30% Work: 3.60%

3. 2.2 Ceiling Tile
Clean up Budget: $8,000 Budget: $4,000

Level 1 Deliverables = 100% 3. 2.3 Hang Work: 2.30%

Level 2 = 100% Wallpaper Budget: $1,500
Level 3 Work Packages = 100%
3. 2.4 Install Work: 1.80%
Carpet Budget: $6,000

Source: http://www.workbreakdownstructure.com/work-breakdown-structure-according-to-pmbok.php 3. 2.5 Finish Work: 2.50%

Hardware Budget: $2,000
6-20
WBS in Summary

 A hierarchical planning process

 Breaks tasks down into successively finer
levels of detail
 Continues until all meaningful tasks or work
packages have been identified
 These make tracking the work easier
 Need separate budget/schedule for each task
or work package
6-21
Steps to Create a WBS

1. List the task breakdown in successive levels

2. Identify data for each work package
3. Review work package information
4. Cost the work packages
5. Schedule the work packages
6. Continually examine actual resource use
7. Continually examine schedule

6-22
Human Resources

 Useful to create a table that shows staff needed

to execute WBS tasks
 One approach is an organizational
breakdown structure (OBS)
– Organizational units responsible for each WBS
element
– Who must approve changes of scope
– Who must be notified of progress

 WBS and OBS may not be identical

6-23
The Responsibility (RACI) Matrix

 Another approach is the Responsible,

Accountable, Consult, Inform (RACI) matrix
– Also known as a responsibility matrix, a linear
responsibility chart, an assignment matrix, a
responsibility assignment matrix

 Shows critical interfaces

 Keeps track of who must approve what and
who must be notified

6-24
 Sample RACI Matrix

Figure 6-7 RACI matrix 6-25

Agile Project Planning and Management

If an organization finds it difficult to define the project

adequately in the shortest possible time, traditional
methods are insufficient.

In situations like these agile project management (APM)

may be effective.

APM requires close and continual contact between the

project team and the clients.

Project requirements are a result of client/developer

interaction, and the requirements change as the
interaction leads to a better understanding on both sides
of the project requirements, priorities, and limitations.
6-26
Agile Project Planning and Management
continued

 When scope cannot be determined in advance,

traditional planning does not work

 Agile project management was developed to deal with

this problem in IT

 Small teams are located at a single site

 Entire team collaborates

 Team deals with one requirement at-a-time with the

scope frozen

6-27
Integration Management

 Coordinating the work and timing of

different groups
 Interface coordination is the process of
managing this work across multiple groups
 Using multidisciplinary teams to plan the project
– Requires structure

6-28
Interface Coordination Through
Integration Management

 Managing a project requires a great deal of

coordination
 Projects typically draw from many parts of the
organization as well as outsiders
 All of these must be coordinated
 The RACI matrix helps the project manager
accomplish this

6-29
Managing Projects by Phases and
Phase-Gates

One way to facilitate interdisciplinary cooperation is to:

 Break objectives into shorter term sub-objectives
 Project life cycle is used for breaking a project up into
component phases
 Focus on specific, short-term output
 Lots of feedback between disciplines

An oversight process can then evaluate the deliverables

and decide whether the project is ready to pass onto the
next phase. This technique is applied in addition to the
normal cost and schedule control techniques associated
with projects.
6-30
Project Risk Management:
A PMBOK Knowledge Area

 Projects are risky, uncertainty is high

 Project manager must manage this risk
 This is called “risk management”
 Risk varies widely between projects
 Risk also varies widely between organizations
 Risk management should be built on the results of prior
projects

6-31
 What Is A Risk?

 A Risk is a Potential Event with Negative Consequences that

Has Not Happened Yet.
 However a Risk could also be defined as the event with
unforeseen positive consequences.
 A Possibility of Loss — Not the Loss Itself!
 A source of problem during a project
– Avoid labeling the cost of a risk as a risk (e.g., schedule
slippage). Find the sources!
– Strike at the root of the problem, not the leaves!

 Something that Makes the Project Special

– In the broadest sense everything is a risk
– There are better ways of handling recurrent problems

32
 Research Indicate the Need to
Improve Project Risk Management
 Ibbs and Kwak1 in a study show risk has the lowest
maturity rating of all knowledge areas

 Similarly, in a survey conducted with software

development companies in South Africa in 2003, risk
management had the lowest maturity

 KLCI Research Group2 in a study shows the benefits

of good software risk management practices

1. Ibbs, C. William and Young Hoon Kwak. “Assessing Project Management Maturity,”
Project Management Journal, March 2000.

2. Kulik, Peter and Catherine Weber, “Software Risk Management Practices – 2001,”
KLCI Research Group, August 2001.

33
Project Management Maturity by Industry
Group and Knowledge Area1

Engineering/ Telecommunications Informatio Hi-Tech

Knowledge Construction n Systems Manufacturing
Area
Scope 3.52 3.45 3.25 3.37
Time 3.55 3.41 3.03 3.50
Cost 3.74 3.22 3.20 3.97
Quality 2.91 3.22 2.88 3.26
Human 3.18 3.20 2.93 3.18
Resources

Communications 3.53 3.53 3.21 3.48

Risk 2.93 2.87 2.75 2.76
Procurement 3.33 3.01 2.91 3.33
KEY:
1 = Lowest maturity rating
5 = Highest maturity rating

1. Ibbs, C. William and Young Hoon Kwak. “Assessing Project Management

Maturity,”
Project Management Journal, March 2000. 34
Benefits from Software Risk Management
Practices1

1. Kulik, Peter and Catherine Weber, “Software Risk Management Practices – 2001,”
KLCI Research Group, August 2001.
35
Parts to Risk Management
 Risk management planning
 Risk identification
 Qualitative risk analysis
 Quantitative risk analysis:
– Failure Mode and Effect Analysis
– Decision Tree Analysis
– Monte Carlo Simulation
– Dealing with Project Disasters
 Risk response planning
 Risk monitoring and control
 The risk management register
6-36
Risk Management Planning

 Need to know the risk involved before selecting a

project

 Risk management plan must be carried out before the

project can be formally selected

 At first, focus is on externalities

– Track and estimate project survival

 Project risks take shape during planning

 Often handled by project office

6-37
Risk Identification
 Risk is dependent on technology and environmental
factors
 Delphi method is useful for identifying project risks
 Other methods include brainstorming, nominal
group techniques, checklists, and attribute
listing
 May also use cause-effect diagrams, flow charts,
influence charts, SWOT analysis

6-38
Qualitative Risk Analysis

 Purpose is to prioritize risks

 A sense of the impact is also needed
 Each objective should be scaled and weighted
 Construct a risk matrix
 Same approach can be used for opportunities

6-39
 Risk Matrix

Figure 6-12 Risk Matrix 6-40

Quantitative Risk Analysis
1. List ways a project can fail
2. Evaluate severity (S)
3. Estimate likelihood (L) (for each cause of failure)
4. Estimate the inability to detect (D)
5. Find the risk priority number (RPN)
RPN = S  L  D
6. Consider ways to reduce the S, L, and D for each
cause of failure

6-41
 A FMEA Example

Estimate the inability to detect (D) a failure associated with each cause:
Using a 10-point scale:
1 = detectability is almost certain using normal monitoring/control system
10 = it is practically certain that failure will not be detected in time to avoid or mitigate it

Table 6-1 A Failure Mode and Effect Analysis (FMEA) example

6-42
 Decision Tree Analysis
EMV =  probability x value

Figure 6-13 Decision tree based on expected monetary value (EMV) 6-43
Risk Response Planning

Threats Opportunities
– Avoid – Exploit
– Transfer – Share
– Mitigate – Enhance
– Accept – Accept

6-44
Risk Monitoring and Control

 Monitoring covered in detail in Chapter 10

 Control covered in Chapter 11

6-45
The Risk Management Register
 Environments that may impact projects
 Assumptions made
 Risks identified
 List of categories and key words
 Estimates on risk, states of project’s environment, or on
project assumptions
 Minutes
 Actual outcomes

6-46
The Risk Management Register
 If the risk management system has no memory, the
task of risk identification will be horrendous.
 But system can have a memory – at least the
individuals in the system can remember.
 Relying on the reallocations of individuals, however, is
“risky.”
 To ensure against this particular risk, the risk
management system should maintain an up-to-date
data register.

6-47
The Risk Management Register
continued

This risk register includes, but not restricted to, the following:
 Identification of all environments that may impact the project
 Identification of all assumptions made in the preliminary project plan that
may be a source of risk for the project
 A list of risks identified by the risk management group, complete with their
impacts and estimates of their probability of occurring
 A complete list of all “categories” and “key words” used to categorize risks,
assumptions, and environments so that all risk management groups can
access past work done on risk environment
 The details of all qualitative and quantitative estimates made on risks, on
states of the project’s environment, or on project assumptions, complete
with a brief description of the methods used to make such estimates
 Minutes of all group meetings including all actions the group developed to
deal with or mitigate each specific risk, including the decision to ignore a
risk
 The actual outcome of identified risks and, if a risk came to occur, the
results of actions taken to mitigate the risk or transfer the risk or invoke the
contingency plan
6-48