Download - WBS and Risk
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 Select lifecycle Set org./team form Start team
selection Determine risks Create WBS
Identify tasks Estimate size Estimate effort Identify task
dependencies Assign resources Schedule work
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
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
WBS Techniques
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.”
“When a project is successful, it is not because there were no problems, but
because the problems were overcome.”
-- Paul Rook
What do you think….Risk Management?
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
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
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
Risk Identification
Qualitative Analysis
Quantitative Analysis
Response Planning Monitoring
and Control
Risk Management
There are six major processes involved in risk management:
1. Risk Management Planning2. Risk Identification3. Qualitative Risk Analysis4. Quantitative Risk Analysis5. Risk Response Planning6. Risk Monitoring and Control
Risk Management
1. Risk Management PlanningThis 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 IdentificationThis involves determining which risks are likely to affect a project and documenting the characteristics of each risk.
Risk Identification What are the risks?
Risk Identification: Classifications Schedule/Cost Risks Requirement/Expectation Risks Technology Risks Market Risk Financial Risk
Risk Identification
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 Management5. 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 isk M anagem ent
R isk A ssessm ent
R isk C ontro l
R isk Identifica tion
R isk A na lysis
R isk E xposure
R isk R eduction
C ontingency P lann ing
R isk M onito ring
C ontinuous R eassessm ent
R isk P rio ritiza tion
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
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
R isk #1
R isk #4
R isk #2R isk #3
R isk #5
Probability o f O ccurrance
Imp
act
H igher P robab ilityLow er P robab ility
Hig
he
r Im
pa
ctL
ow
er
Imp
act
Probability of Occurrence vs Impact
Priorities Red - High Yellow - Med Green - Low
Review/Present Chart Periodically
DoRegression
Testing?
NoDon't Find Critical Fault
P(O) = 0.55
Find Critical FaultP(O) = 0.25
No Critical FaultP(O) = 0.20
L(O) = $0.5M
L(O) = $30M
L(O) = $0.5M
$0.125M
$16.50M
$0.10M
$16.75M
Don't Find Critical FaultP(O) = 0.05
Find Critical FaultP(O) = 0.75
No Critical FaultP(O) = 0.20
L(O) = $0.5M
L(O) = $30M
L(O) = $0.5M
$0.375M
$1.5M
$0.10M
$1.975MYes
RISKEXPOSURE COMBINED
RISKEXPOSURE
RISK LEVERAGE -> $14.775M
Example Risk Assessment Using Probability Method
Risk Reduction Contingency Planning Monitoring Continuous Reassessment
Risk Control
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
Risk Reduction
Contingency Planning
Some risks cannot be reduced Plan for risk occurrence Why?
Reduces “Crisis” atmosphere Reduces chance of mistakes Reduces time to correct
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 Management: Monitoring and Continuous Reassessment Risk Probability
For each risk a probability of 0-10 is assigned (only integers are used).
Risk ImpactFor each risk an impact of 0-10 is assigned (only integers are used).
Risk ExposureThe 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 project >= 100
Group Manager and CTO will be 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 CategoriesRisk 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