Risk Management

Anne Banks Pidduck

Adapted from John Musser

1
 Risk Management
• Problems that haven’t happened yet
• Why is it hard?
• Some are wary of bearing bad news
– No one wants to be the messenger
– Or seen as “a worrier”
• Define a strategy early in your project

2
 Risk Management
• Identification, Analysis, Control
• Goal: avoid a crisis
• Thayer: Risk Mgmt versus Project Mgmt
– For a specific project versus all projects
– Proactive versus reactive

3
 Project Risk
• Characterized by:
– Uncertainty (0 < probability < 1)
– An associated loss (money, life, reputation, etc)
– Manageable – some action can control it
• Risk Exposure
– Product of probability and potential loss
• Problem
– A risk that has materialized
4
 Types of Risks
• Schedule Risks
• Schedule compression (customer, marketing, etc.)
• Cost Risks
• Unreasonable budgets
• Requirements Risks
• Incorrect
• Incomplete
• Unclear or inconsistent
• Volatile

5
 Types of Risks
• Quality Risks
• Operational Risks
• Most of the “Classic Mistakes”
– Classic mistakes are made more often

6
 Risk Management Process

Risk Identification

Risk Assesment Risk Analysis

Risk Prioritization

Risk Management
Risk Management Planning

Risk Control Risk Resolution

Risk Monitoring

“Software Risk Management”, Boehm, 1989

7
 Risk Identification
• Get your team involved in this process
– Don’t go it alone
• Produces a list of risks with potential to
disrupt your project’s schedule
• Use a checklist or similar source to
brainstorm possible risks

8
 Risk Analysis
• Determine impact of each risk
• Risk Exposure (RE) or Impact
– RE = Probability of loss * size of loss
– Example: Risk is “Facilities not ready on time”
• Probability is 25%, size is 4 weeks, RE is 1 week
– Ex: Risk is “Inadequate design. Redesign required.”
• Probability is 15%, size is 10 weeks, RE is 1.5 weeks
– Statistically are “expected values”
– Sum all RE’s to get total expected overrun

9
 Risk Analysis ..2
• Estimating size of loss
– Loss is easier to see than probability
• You can break this down into “chunks” (like WBS)
• Estimating probability of loss
– Use team member estimates and a risk-estimate review
– Use Delphi or group-consensus techniques
– Use gambling analogy “How much would you bet?”
– Use “adjective calibration”: highly likely, probably,
improbable, unlikely, highly unlikely

10
 Risk Prioritization
• Remember the 80-20 rule
• Often want larger-loss risks higher
– Or higher probability items
• Possibly group ‘related risks’
• Helps identify which risks to ignore
– Those at the bottom

11
 Types of Unknowns
• Known Unknowns
– Information you know someone else has
• Unknown Unknowns
– Information that does not yet exist

12
 Risk Control
• Risk Management Plan
– Can be one paragraph per risk
– McConnell’s example

13
 Risk Resolution
• Risk Avoidance
– Don’t do it
– Scrub from system
– Off-load to another party
• Risk Assumption
– Don’t do anything about it
– Accept that it might occur
– But still watch for it
14
 Risk Resolution
• Problem control
– Develop contingency plans
– Allocate extra test resources
• Risk Transfer
– To another part of the project (or team)
– Move off the critical path at least
• Knowledge Acquisition
– Investigate, maybe with a prototype
– Buy information or expertise about it
– Do research
15
 Risk Monitoring
• Top 10 Risk List
• Rank
• Previous Rank
• Weeks on List
• Risk Name
• Risk Resolution Status
• A low-overhead best practice
• Interim project post-mortems
– After various major milestones

16
 Risk Communication
• Don’t be afraid to convey the risks
• Use your judgment to balance

17
 Miniature Milestones
• A risk-reduction technique
• Use of small goals within project schedule
– One of McConnell’s Best Practices (Ch. 27)
• Fine-grained approach to plan & track
• Reduces risk of undetected project slippage
• Pros
– Enhances status visibility
– Good for project recovery
• Cons
– Increases project tracking effort
18
 Miniature Milestones ..2
• Can be used throughout the development cycle
• Works well with hard-to-manage project activities
or methods such as with evolutionary prototyping
• Reduces unpleasant surprises
• Success factors
– Overcoming resistance from those managed
– Staying true to ‘miniature’ nature
• Can improve motivation through achievements

19
 Miniature Milestones ..3
• Requires a detailed schedule
• Have early milestones
– 1 to 2 days to 1 to 2 weeks
• Encourages iterative development
• Use binary milestones
– Done or not done (100%)

20
 Feature-Set Control
• Class mistake avoidance
• Early Stages
– 1. Minimal Specification
– 2. Requirements Scrubbing
– 3. Versioned Development
• Mid-Project
– Effective change control
• Late-Project
– Feature cuts
21
 Traditional Specifications
• Drive for “traditional” specifications
– Necessity
– Downstream cost avoidance
– Full control over all aspects
• As McConnell notes:
• “But the goal is not to build exactly what you said
you would at the beginning. It is to build the best
possible software within the available time.”
• Idealistic but worth remembering
22
 Minimal Specification
• This is not XP (extreme programming)
• Traditional specification issues
– Wasted effort because too much detail
– Obsolescence
– Details do not guarantee success
– Overly constrained design
– User assumption that costs are equal

23
 Minimal Specification ..2
Costs and Risks
– Omission of key requirements
– Unclear or impossible goals
– Gold plating
– Used for the wrong reasons
• Lazy substitute for doing good requirements

24
 Minimal Specification ..3
Benefits
– Improved morale and motivation
– Opportunistic efficiency
– Shorter requirements phase
Success Factors
– Used only when requirements are flexible
– Capture most important items
– Involve key users
25
 Requirements Scrubbing
• Removing a feature from the product
– Eliminates all effort: specification, design,
development, test, documentation
– The earlier the better
– Typically done during or right after
Requirements

26
 Requirements Scrubbing ..2
• Less risky than minimal specification
• Aims
– Eliminate all but absolutely necessary
requirements
– Simplify all complicated requirements
– Substitute cheaper items

27
 Versioned Development
• Eliminate work from the current version
• “Let’s put it in release 1.1”
– You’re still saying “Yes”, not “No”
• By next revision, the list has changed
anyway

28
 Mid-Project Feature-Creep
• Average project has 25% change in
requirements during development
• Sources of change
– Marketing: want to meet customer’s check-list
– Developers: want to perfect deficiencies
– Users: want more functionality or now ‘know’
what they want
• They will all try to insert these mid-project
29
 Mid-Project Feature-Creep ..2
• The devil is in the details
• Trivial feature can have weeks of
impact
• Developers can insert things when
you’re not looking
• No specification can cover all details;
you must.
30
 Change Control Board (CCB)
• Representatives from each stakeholder party
– Development, QA, Marketing, Management,
Customer Support
• Perform “change analysis”
– Importance, priority, cost, benefit
• Triage
– Allocating scare resources
– Some will not receive treatment
– Life-critical to the project
31
 Change Control

Change CM
Control System
System
CM Tool

“Quality Software Project Management”, Futrell, Shafer, Shafer

32
 Configuration Control
• A management support function
• Includes
– Program code changes
– Requirements and design changes
– Version release changes
• Essential for developed items
– Code, documentation, and so on

33
 Configuration Control Terminology

• Software Configuration Control Item (SCCI)

– a.k.a. Source Item (SI)
– Anything suitable for configuration control
– Source code, documents, diagrams, and so on
• Change Control: process of controlling changes
– Proposal, evaluation, approval, scheduling,
implementation, tracking

34
 Configuration Control Terminology ..2

• Version Control
– Controlling software version releases
– Recording and saving releases
– Documenting release differences
• Configuration Control
– Process of evaluating, approving and disapproving, and
managing changes to SCCIs.

35
 SCM
• Software Configuration Management
• Formal engineering discipline
• Methods and tools to identify and manage
software throughout its use

36
 Configuration Control Needs
• Establish clearly defined management authority
• Setup control standards, procedures and guidelines
– All team members must be aware of these
• Requires appropriate tools and infrastructure
• Configuration Management Plan must be
produced during planning phase
– Often part of Software Development Plan

37