Software Project

Management
(COSC 612)

Tessfu G. (PhD)
School of Computing
Department of Computer Science
Dire Dawa Institute of Technology
Chapter 5 – Risk and Change Management
 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”
• You need to define a strategy early in your project

• Identification, Analysis, Control

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

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)
• a.k.a. “Risk Impact”
• RE = Probability of loss * size of loss
• Ex: 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 expected overrun
• Which is pre risk management

9
 Risk Analysis
• 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 have 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 1 paragraph per risk
• McConnell’s example

13
 Risk Resolution
• Risk Avoidance
• Don’t do it
• Scrub from system
• Off-load to another party
• McConnell: design issue: have client design

• 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
• Example: do 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
• Sky-is-falling whiner vs. information distribution

17
 Miniature Milestones
• A risk-reduction technique
• Use of small goals within project schedule
• Fine-grained approach to plan & track
• Reduces risk of undetected project slippage

• Pros
• Enhances status visibility
• Good for project recovery

• Cons
• Increase project tracking effort

18
 Miniature Milestones
• Can be used throughout the development cycle
• Works with will 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
• Requires a detailed schedule
• Have early milestones
• McConnell says 1-2 days
• Longer is still good (1-2 weeks)
• Encourages iterative development
• Use binary milestones
• Done or not done (100%)

20
 Feature-Set Control
• Class mistake avoidance

• Early Stages
1. 1. Minimal Specification
2. Requirements Scrubbing
3. Versioned Development

• Mid-Project
• Effective change control

• Late-Project
• Feature cuts

21
 Traditional Specs
• Drive for “traditional” specs
• 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

23
Minimal Specification

24
 Requirements Scrubbing
• Removing a feature from the product
• Eliminates all effort: spec., design, dev., test, doc.
• The earlier the better
• Typically done during or right after Requirements

• Less risky than minimal specification

• Aims
• Eliminate all but absolutely necessary requirements
• Simplify all complicated requirements
• Substitute cheaper items

25
 Versioned Development
• Eliminate them from the current version
• “Let’s put it in release 1.1”
• You’re still saying “Yes”, not “No”
• By next rev. the list has changed anyway
• My favorite

26
 Mid-Project Feature-Creep
• Avg. project has 25% change in requirements during development
• Sources of change
• Marketing: want to meet customer’s check-list
• Developers: want to perfect r1 deficiencies
• Users: want more functionality or now ‘know’ what they want
• They will all try to ‘insert’ these during dev.

27
 Mid-Project Feature-Creep
• The devil is in the details
• McConnell’s example: “trivial” feature can have +/- weeks of impact
• Developers can insert things when you’re not looking
• No spec. can cover all details. You must.
• Programmer ideal: flip switch- Word -> Excel
• Up to 10-1 differences in prog. size w/same specs.

28
 Change Control Board (CCB)
• McConnell “best practice”
• Structure: representatives from each stakeholder party
• Dev., QA, Marketing, Mgmt., Customer support
• Perform “change analysis”
• Importance, priority, cost, benefit
• Triage
• Allocating scare resources
• Some will not receive treatment
• Life-critical to the project
• Will say “No” more than “Yes”
• Watch for bureaucracy

29
 Change Control

Change CM
Control System
System
CM Tool

30
Configuration Control

31
 Configuration Control Terminology
• Software Configuration Control Item (SCCI)
• a.k.a. Source Item (SI)
• Anything suitable for configuration control
• Source code, documents, diagrams, etc.

• Change Control: process of controlling changes

• Version Control: controlling software version releases

• Configuration Control: process of evaluating, approving and disapproving,

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

33
 Configuration Control Needs
• Establish clearly defined mgmt. Authority

• Setup control standards, procedures and guidelines

• Requires appropriate tools and infrastructure

• Configuration Management Plan must be produced during planning phase

34
 Maintenance
• SCM is very important during all phases starting with Requirements
• Continues to be important during Maintenance

35
 Project - III
• Prepare the Risk Management Plan (RMP) for your project.
• The Sample Template for RMP is given as follows:
1. Introduction
1.1 Objective
1.2 Definitions, Acronyms, and Abbreviations
2. Risk Assessment
2.1 Risk Identification
2.2 Risk Analysis and Prioritization
3. Risk Control
3.1 Planning
3.2 Resolution
3.3 Monitoring
4. References Deadline for the project will be:
After two Weeks - August 25,
2013.

36
 Project - IV
• Prepare the Software Configuration Management Plan (SCMP) for your
project.
• The Sample Template for SCMP is given as follows:
1. Introduction
1.1 Scope
1.2 Definitions, Acronyms, and Abbreviations
2. Roles and Responsibilities
3. Configuration Management Process
3.1 Identification of Configuration Items
3.2 Change Control Management
4. Schedule
5. References
Deadline for the project will be:
After two Weeks - August 25,
2013.

37
Next – Software Quality Assurance