WBS & Risk Management

Shamsul Arefeen
Planning, Estimating, Scheduling
 What’s the difference?
 Plan: Identify activities. No specific
start and end dates.
 Estimating: Determining the size &
duration of activities.
 Schedule: Adds specific start and
end dates, relationships, and
resources.
Project Planning: A 12 Step
Program
 Set goal and scope  Identify tasks
 Select lifecycle  Estimate size
 Set org./team  Estimate effort
form  Identify task
 Start team dependencies
selection  Assign resources
 Determine risks  Schedule work
 Create WBS
 How To Schedule
 1. Identify “what” needs to be done
 Work Breakdown Structure (WBS)
 2. Identify “how much” (the size)
 Size estimation techniques
 3. Identify the dependency between
tasks
 Dependency graph, network diagram
 4. Estimate total duration of the work
to be done
 The actual schedule
 WBS & Estimation
 How did you feel when I asked
 “How long will your project take?”
 Not an easy answer to give right?
 At least not if I were a real customer
on a real project
 How can you manage that issue?
 Partitioning Your Project
 You need to decompose your project
into manageable chunks
 ALL projects need this step
 Divide & Conquer
 Two main causes of project failure
 Forgetting something critical
 Ballpark estimates become targets
 How does partitioning help this?
Project Elements
 Work Breakdown Structure:
WBS
 Hierarchical list of project’s work
activities
 2 Formats
 Outline (indented format)
 Graphical Tree (Organizational Chart)
 Uses a decimal numbering system
 Ex: 3.1.5
 0 is typically top level
 Work Breakdown Structure:
WBS
 Includes
 Development, Mgmt., and project
support tasks
 Shows “is contained in” relationships
 Does not show dependencies or
durations
 A Full WBS Structure
 Up to six levels (3-6 usually) such as

 Different level can be applied to

different uses
 Ex: Level 1: authorizations; 2: budgets;
3: schedules
WBS Chart Example
 WBS Outline Example
 0.0 Retail Web Site
 1.0 Project Management
 2.0 Requirements Gathering
 3.0 Analysis & Design
 4.0 Site Software Development
 4.1 HTML Design and Creation
 4.2 Backend Software
 4.2.1 Database Implementation
 4.2.2 Middleware Development
 4.2.3 Security Subsystems
 4.2.4 Catalog Engine
 4.2.5 Transaction Processing
 4.3 Graphics and Interface
 4.4 Content Creation
 5.0 Testing and Production
 WBS Types
 Process WBS
 a.k.a Activity-oriented
 Ex: Requirements, Analysis, Design,
Testing
 Typically used by PM
 Product WBS
 a.k.a. Entity-oriented
 Ex: Financial engine, Interface system, DB
 Typically used by engineering manager
Product WBS
Process WBS
Outline WBS w/Gantt
WBS by PMI Process Groups
 WBS Types
 Less frequently used alternatives
 Organizational WBS
 Research, Product Design, Engineering,
Operations
 Can be useful for highly cross-functional
projects
 Geographical WBS
 Can be useful with distributed teams
 NYC team, San Jose team, Off-shore team
 WBS
 List of Activities, not Things
 List of items can come from many sources
 SOW, Proposal, brainstorming, stakeholders,
team
 Describe activities using “bullet language”
 Meaningful but terse labels

 All WBS paths do not have to go to the same

level
 Do not plan more detail than you can
manage
 WBS Techniques
 Top-Down
 Bottom-Up
 Analogy
 WBS Techniques
 Top-down
 Start at highest level
 Systematically develop increasing level of detail
 Best if
 The problem is well understood
 Technology and methodology are not new
 This is similar to an earlier project or problem
 But is also applied in majority of situations
 WBS Techniques
 Bottom-up
 Start at lowest level tasks
 Aggregate into summaries and higher
levels
 Cons
 Time consuming
 Needs more requirements complete
 Pros
 Detailed
 WBS Techniques
 Analogy
 Base WBS upon that of a “similar”
project
 Use a template
 Analogy also can be estimation basis
 Pros
 Based on past actual experience
 Cons
 Needs comparable project
WBS Techniques

Mind Mapping
 Software Risk Management

“If you don’t actively attack the risks,

they will actively attack you.”

-Tom Gilb
 What is Risk?

1. “Risk is the potential for realization

of unwanted negative consequences
of an event.”
2. “Risk is the possibility of suffering
loss.”
3. “Risk is the measure of the
probability and severity of adverse
effects.”
 What do you think….Risk
Management?

“When a project is successful, it is not

because there were no problems, but
because the problems were
overcome.”
-- Paul Rook
Risk and Risk Management
 Risk analysis and management are a series of
steps that help a software team to understand
and manage uncertainty.
 Many problems can plague a software project.
 A risk is a potential problem-it might happen, it
might not.
 But, regardless of the outcome, it’s really a
good idea to identify it, assess its probability of
occurrence, estimate its impact, and establish
a contingency plan should the problem actually
occur.
 Boy Scout

Boy Scout Motto:

“Be Prepared”
 What are the steps?
1. Recognizing what can go wrong….risk
identification.
2. Each risk is analyzed to determine the
likelihood that it will occur.
3. Each risk is analyzed to determine the
damage it will do if it occurs.
4. Once this information is established, risks
are ranked, by probability and impact.
5. Finally, a plan is developed to manage
those risks with high probability and high
impact.
 Risk Management

In fact, all areas in systems

development are potential sources of
software risks since it involves
technology, hardware, software,
people, cost, and schedule.
Risks Within a System Context
Risk Management
 Risk Management
 What is a Risk?
 What is Risk Management?
 A Method for Dealing with Project Risks
 Identification and Handling of Risks
 Can be simple or complex
 On-Going Activity
 Risk Management

The goal of project risk management

can be viewed as minimizing potential
risks while maximizing potential
opportunities or payoffs.

Software Risk Management: Principles and Practices, B.W. Boehm,

IEEE Software, Jan., 1991, pg. 32-41
 Risk Management:
Basic Approach
 Analysis of Project
 Identification of Risks
 For Each Risk:
 Impact and Probability Analysis
 What is the Nature of the Risk?
 Avoidance/Mitigation Plans
 How Can We Minimize the Risk?
 Contingency Plans
 What Do We Do if it Occurs?
 Risk Management:
Basic Approach
 Avoidance / Risk Mitigation Plan

 Contingency plan

 Fallback Plan
Risk Management:
Basic Approach
 Risk

 Issue
Risk Management: Top 10 Risks
 Personnel Shortfalls
 Staffing with Top Talent
 Job Matching
 Team Building
 Morale Building
 Cross-Training
 Pre-scheduling Key People
Software Risk Management: Principles and Practices, B.W. Boehm,
IEEE Software, Jan., 1991, pg. 32-41
Risk Management: Top 10 Risks
 Unrealistic Schedules and Budgets
and/or Underestimating Problem
Complexity
 Detailed multisource cost and schedule
estimation
 Design to Cost
 Incremental Development
 Software Reuse
 Requirements Scrubbing
Software Risk Management: Principles and Practices, B.W. Boehm,
IEEE Software, Jan., 1991, pg. 32-41
Risk Management: Top 10 Risks
 Developing the Wrong Software
Functions
 Domain Analysis
 (Organizational Analysis/Mission Analysis)
 Operational Concept Formulation
 User Surveys
 Prototyping
 Early User Manuals

Software Risk Management: Principles and Practices, B.W. Boehm,

IEEE Software, Jan., 1991, pg. 32-41
Risk Management: Top 10 Risks
 Developing the Wrong User
Interface
 Prototyping
 Scenerios
 Task Analysis
 Gold Plating
 Requirements Scrubbing
 Prototyping
 Cost-Benefit Analysis
 Design to Cost
Software Risk Management: Principles and Practices, B.W. Boehm,
IEEE Software, Jan., 1991, pg. 32-41
Risk Management: Top 10 Risks
 Continuing Stream of
Requirements
 High Change Threshold
 Information Hiding
 Incremental Development
(defer changes to later increments)

Software Risk Management: Principles and Practices, B.W. Boehm,

IEEE Software, Jan., 1991, pg. 32-41
Risk Management: Top 10 Risks
 Shortfalls in Externally Performed
Tasks
 Reference Checking
 Pre-award Audits
 Competitive design or prototyping
 Team Building

Software Risk Management: Principles and Practices, B.W. Boehm,

IEEE Software, Jan., 1991, pg. 32-41
Risk Management: Top 10 Risks
 Shortfalls in Externally Furnished
Components
 Benchmarking
 Inspections
 Reference Checking
 Compatability Analysis
 Examples:
 Compilers

 Development Environments

 Target Hardware

Software Risk Management: Principles and Practices, B.W. Boehm,

IEEE Software, Jan., 1991, pg. 32-41
Risk Management: Top 10 Risks
 Real-Time Performance Shortfalls
 Simulation
 Prototyping
 Instrumentation
 Tuning
 Performance Parameter Allocations

Software Risk Management: Principles and Practices, B.W. Boehm,

IEEE Software, Jan., 1991, pg. 32-41
Risk Management: Top 10 Risks
 Straining Computer Science Capabilities
or Introduction of New Technology to an
Organization
 Technical Analysis

 Cost-Benefit Analysis

 Prototyping

 Reference Checking

 Staff Training

 Example:
 Use of a new language, tool, or method

Software Risk Management: Principles and Practices, B.W. Boehm,

IEEE Software, Jan., 1991, pg. 32-41
 PMI Risk Model
Project Risk Management

Qualitative
Analysis
Risk
Identification
Quantitative
Analysis

Response
Planning Monitoring
and Control
 Risk Management
There are six major processes
involved in risk management:
1. Risk Management Planning
2. Risk Identification
3. Qualitative Risk Analysis
4. Quantitative Risk Analysis
5. Risk Response Planning
6. Risk Monitoring and Control
 Risk Management
1. Risk Management Planning
This involves deciding how to approach and
plan the risk management activities for the
project.
Project team can formulate a risk
management plan by reviewing the Project
Charter, WBS, Roles & Responsibilities,
Stakeholder risk tolerances, Organization’s
risk management policies.
 Risk Management
2. Risk Identification
This involves determining which risks
are likely to affect a project and
documenting the characteristics of
each risk.
 Risk Identification
 Risk Identification
 What are the risks?
 Risk Identification: Classifications
 Schedule/Cost Risks
 Requirement/Expectation Risks
 Technology Risks
 Market Risk
 Financial Risk
Risk Management: How to Identify
Risks
 Start with a typical list of software
risks
 Review development plan
 Critical Paths
 Critical Staff Members
 Critical Vendor Deliveries
 Critical Milestones
 Review Requirements
 Review Technical Design
 Review Past Projects
Risk Management: How to Identify
Risks (Continued)
 Conduct Risk Brainstorming Sessions
with Staff, Users, Vendors,
Customers, and Management
 Try to assess the direction of thinking by
third parties as they may give an
indication of future requirements,
expectations, or vendor changes.
 If you are dependent on vendors, try to
understand their business situation.
 Get as much input as possible!
Risk Management: How to Identify
Risks (Continued)
 Interview
 Use of Checklist
 Use of diagrams
 Risk Management
3. Qualitative Risk Analysis:
This involves characterizing and
analyzing risks and prioritizing their
effects on project objectives.
4. Quantitative Risk Analysis:
This involves measuring the
probability and consequences of risks
and estimating their effects on
project objectives.
 Risk Management

After identifying the risks the project

teams can use various tools and
techniques to develop an overall risk
ranking for the project. The project
team can prioritize the quantified
risks and estimate probabilities of
achieving project objectives.
 Risk Management
5. Risk Response Planning:
This involves taking steps to enhance opportunities
and reduce threats to meeting project objectives.
Project team develops a risk response plan.

6. Risk monitoring and Control:

This involves monitoring known risks, identifying new
risks, reducing risks, and evaluating the effectiveness
of risk reduction throughout the life of the project.
The main outputs of this process include corrective
actions in response to risks and updates to the risk
response plan.
 Risk Management
R is k I d e n t if ic a t io n
R is k A n a ly s is

R is k A s s e s s m e n t R is k E x p o s u r e
R is k P r io r it iz a t io n

R is k M a n a g e m e n t
R is k R e d u c t io n
C o n t in g e n c y P la n n in g
R is k C o n tr o l
R is k M o n it o r in g
C o n tin u o u s R e a s s e s s m e n t
 Analysis, Exposure, &
Prioritization
 For Each Risk:
 Determine Probability of Occurrence
 What is the likelyhood of occurrence?
 Determine Impact
 What is the impact if it occurres?
 Determine Exposure
 What will we lose if the risk occurs?
 For All Risks:
 Prioritize
 Where should we put our limited resources?
 Analysis, Exposure, &
Prioritization
 Various Techniques Available But Key
is Experience
 Individual
 Organizational
 Don’t Rely on Just Yourself - Get lots
of Inputs
 Risk Assessment: A Simple
Classification & Tracking Method
 Probability of
Occurrence vs
R is k # 1

Impact

Higher Impact
R is k # 4

Priorities

Impact
 R is k # 3 R is k # 2

 Red - High

Lower Impact
 Yellow - Med
 Green - Low R is k # 5

 Review/Present
Chart Periodically
L o w e r P r o b a b ility H ig h e r P r o b a b ility

P r o b a b ilit y o f O c c u r r a n c e
Example Risk Assessment Using
Probability Method
RISK
EXPOSURE COMBINED
RISK
Find Critical Fault
P(O) = 0.75
L(O) = $0.5M $0.375M EXPOSURE

Don't Find Critical Fault

Yes P(O) = 0.05 L(O) = $30M $1.5M $1.975M

No Critical Fault
P(O) = 0.20
L(O) = $0.5M $0.10M
Do
Regression
Testing?

Find Critical Fault

P(O) = 0.25
L(O) = $0.5M $0.125M
No
Don't Find Critical Fault
P(O) = 0.55
L(O) = $30M $16.50M $16.75M

No Critical Fault
P(O) = 0.20
L(O) = $0.5M $0.10M

RISK LEVERAGE -> $14.775M

 Risk Control
 Risk Reduction
 Contingency Planning
 Monitoring
 Continuous Reassessment
 Risk Reduction
 Avoiding Risk
 Modifying project requirements
 Transferring the Risk
 By allocation to other systems
 Buying Insurance to cover financial loses
 Mitigating the Risk
 Pre-Event Actions to:
 Reduce Likelihood of Occurrence
and/or
 Minimize Impact
 Contingency Planning
 Some risks cannot be reduced
 Plan for risk occurrence
 Why?
 Reduces “Crisis” atmosphere
 Reduces chance of mistakes
 Reduces time to correct
Risk Management: Monitoring
and Continuous Reassessment
 Periodic Review of Risk Status
 Changes in Probabilities or Impacts

 Changes in
Avoidance/Mitigation/Contingency Plans
 Periodic Review of Project to Identify New
Risks
 Implementation of Risk Avoidance or
Mitigation Plans
 Keep Management and Customers
Informed!!!
 Frequent Risk Reviews
Risk Management: Monitoring and
Continuous Reassessment
 Risk Probability
For each risk a probability of 0-10 is assigned (only
integers are used).
 Risk Impact
For each risk an impact of 0-10 is assigned (only
integers are used).
 Risk Exposure
The exposure is a computed figure, which is derived
by multiplying the probability into impact. For
example, if the probability is 4 and the impact is 6,
then the exposure is 4* 6 = 24. The risk exposure
figure will vary from 0 to 100.
 Escalation thresholds and
levels
Condition Escalation
Exposure for any risk >= 50 Group Manager will be
informed immediately and
every week thereafter on the
status of this risk, till the
exposure is reduce below 50.
Total risk exposure for the Group Manager and CTO will be
project >= 100 informed immediately and every week
thereafter on the status of all risks (the
risk summary and risk tracking sheets
are sent to them) put together till it
falls below 100.
 Risk Categories
Risk Categories
Risk categories classification is used to
understand to key potential impacts due to
the risk. Few categories are:
 Schedule Overrun
 Effort Overrun
 Quality Issues
 Unwanted Product
 Staff Attrition
 Poor communication with customer
 Possible disruption of operations