Transcript Software Project Management Session 7: Risk and Change Management Q7503, Summer 2002

Software Project Management
Session 7: Risk and Change Management
Q7503, Summer 2002
1
Today
•
•
•
•
•
Exam Review
Risk Management
Feature Set Control
Change Control
Configuration Management
Q7503, Summer 2002
2
Session 6 Review
• The exam
• MS-Project
– A fuller, slower review next week
Q7503, Summer 2002
3
Exam Review
• 1. Phases
– A reference model
– Many other models are just as good or valid
• 2. Tradeoff Triangle
– Dependency of 3 sides
– Determining which is fixed or most important to
customer
– Balance
– Give-and-take
• Often choose two
Q7503, Summer 2002
4
Exam Review
• 3. Project & Program
– PMI definition
– Temporary endeavor undertaken to create a
unique product or service
– Program as set of related projects
• Not just a ‘continuous process’, that could be
manufacturing
Q7503, Summer 2002
5
Exam Review
• 4. Methodology/Context
– Some ‘iterative’ process
– Spiral Methodology
• Risk reduction
– Evolutionary Prototyping
• Early, active user feedback
– Tradeoffs
• Speed vs. Accuracy
• Risks
– Uncertainty, code-and-fix, lack of scope clarity
Q7503, Summer 2002
6
Exam Review
• 5. Man-Month
– People & months are not interchangeable
• 12 months / 2 people != 6 months
–
–
–
–
–
Communications overhead, ex: n(n-1)/2
Software not like bricklaying
Adding to late makes later
Pouring gas on the fire
Also: Optimism, gutless estimating
Q7503, Summer 2002
7
Exam Review
• 6. Requirements Importance
– Where the real scope of project defined
– Defects introduced here are very costly to fix
later
– Issues
•
•
•
•
Developer-Customer conflict
Uncertainty
Lack of support
Forgotten requirements
Q7503, Summer 2002
8
Exam Review
• 7. Waterfall risk
–
–
–
–
No visible product until late in process
Rigid phases
Heavy reliance on documentation
Difficulty in identifying all requirements up front
• 8. Pro/Con 2 other methodologies
– Spiral, Prototyping, V-Model
– Waterfall variations: ‘modified’
– XP, RUP, Sashimi (modified waterfall)
Q7503, Summer 2002
9
Exam Review
• 9. Organizational Types
– Functional, project, matrix
– Pros & Cons
– What it means to a PM
Q7503, Summer 2002
10
Exam Review
• 10. Critical Path define + resources
– Longest sequence of activities
– Zero total slack
– Resources issues
• Conflicts and dependencies
• May force recalculation of path
• “Default” CPM method doesn’t include this
Q7503, Summer 2002
11
Exam Review
• 11. Concept Exploration documents
– SOW
• More detailed
• Can be used in Contracts
– Project Charter
• Higher-level overview
– Other: RFP
Q7503, Summer 2002
12
Exam Review
• 12. Estimation best practices
– Q12: A source of some confusion, I graded
quite leniently (and allowed trade-offs with
Q15)
– Estimate iteratively
– Know presentation techniques
• Q3, +/- 2 months, 90% probability
– Hierarchical breakdown of major activities
– Not: dependencies, durations
Q7503, Summer 2002
13
Exam Review
• 13. Three WBS Types
–
–
–
–
Process
Product
Hybrid
Others: Geographic, Organizational
Q7503, Summer 2002
14
Exam Review
• 14. Fast tracking and crashing
– Crashing sounds worse than it is
• 3 ways discussed
– Add resources, limit requirements, change task sequence
– Fast tracking
• Overlapping of activities
Q7503, Summer 2002
15
Exam Review
• 15. Size Estimation Techniques
– Expert Judgment
– Analogy
– Parametric
• FP, LOC
– Delphi
Q7503, Summer 2002
16
Exam Review
• 16. Dependencies
–
–
–
–
–
Mandatory: “hard”, dev. before QA
External: vendor or client
Discretionary: PM determines, “soft”
Resource
Not really the FS, SF, SS, FF
Q7503, Summer 2002
17
Exam Review
• 18. PMI Process Groups
– A: C, Directing is *not* one of the five
• 19. Org. structure and PM power
– A: A, Projectized (2nd is B, strong matrix)
• 20. Increase risk
– A: C, Fast tracking (overlap tasks = risk)
• 21. Network diagram critical path
– A: D, A/B/D/F/K: 14 days
• 22. Total slack
– A: D, 5 days
Q7503, Summer 2002
18
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
Q7503, Summer 2002
19
Risk Management
• Identification, Analysis, Control
• Goal: avoid a crisis
• Thayer: Risk Mgmt. vs. Project Mgt.
– For a specific vs. all projects
– Proactive vs. reactive
Q7503, Summer 2002
20
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
Q7503, Summer 2002
21
Types of Risks
• Schedule Risks
• Schedule compression (customer, marketing, etc.)
• Cost Risks
• Unreasonable budgets
• Requirements Risks
•
•
•
•
Incorrect
Incomplete
Unclear or inconsistent
Volatile
Q7503, Summer 2002
22
Types of Risks
• Quality Risks
• Operational Risks
• Most of the “Classic Mistakes”
– Classic mistakes are made more often
Q7503, Summer 2002
23
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
Q7503, Summer 2002
24
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
Q7503, Summer 2002
25
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
Q7503, Summer 2002
26
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 riskestimate 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
Q7503, Summer 2002
27
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
Q7503, Summer 2002
28
Types of Unknowns
• Known Unknowns
– Information you know someone else has
• Unknown Unknowns
– Information that does not yet exist
Q7503, Summer 2002
29
Risk Control
• Risk Management Plan
– Can be 1 paragraph per risk
– McConnell’s example
Q7503, Summer 2002
30
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
Q7503, Summer 2002
31
Risk Resolution
– Problem control
• Develop contingency plans
• Allocate extra test resources
• See McConnell pg. 98-99
– Risk Transfer
• To another part of the project (or team)
• Move off the critical path at least
– Knowledge Acquisition
• Investigate
– Ex: do a prototype
• Buy information or expertise about it
• Do research
Q7503, Summer 2002
32
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
• McConnell’s example
Q7503, Summer 2002
33
Risk Communication
• Don’t be afraid to convey the risks
• Use your judgment to balance
– Sky-is-falling whiner vs. information
distribution
Q7503, Summer 2002
34
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
– Increase project tracking effort
Q7503, Summer 2002
35
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
Q7503, Summer 2002
36
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%)
Q7503, Summer 2002
37
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
Q7503, Summer 2002
38
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
Q7503, Summer 2002
39
Minimal Specification
– This is not XP (extreme programming)
– Tradition spec. issues
• Wasted effort
– Too much detail
•
•
•
•
Obsolescence
Lack of efficacy -- details do not guarantee success
Overly constrained design
User assumption that costs are equal (UI ex.)
Q7503, Summer 2002
40
Minimal Specification
• Benefits
• Improved morale and motivation
• Opportunistic efficiency
• Shorter requirements phase
• Costs and Risks
•
•
•
•
Omission of key requirements
Unclear or impossible goals
Gold plating
Used for the wrong reasons
– Lazy substitute for doing good requirements
• Success Factors
• Used only when requirements are flexible
• Capture most important
items;2002
involve key users
Q7503, Summer
41
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
Q7503, Summer 2002
42
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
Q7503, Summer 2002
43
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.
Q7503, Summer 2002
44
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.
Q7503, Summer 2002
45
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
Q7503, Summer 2002
46
Change Control
Change
Control
System
CM
System
CM Tool
“Quality Software Project Management”, Futrell, Shafer, Shafer
Q7503, Summer 2002
47
Configuration Control
• A management support function
• Includes
• Program code changes
• Requirements and design changes
• Version release changes
• Essential for developed items
• Code, documentation, etc.
• Example
• The case of the code that used to work
– But didn’t in time for the demo
Q7503, Summer 2002
48
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
• Proposal, evaluation, approval, scheduling, implementation, tracking
• 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.
Q7503, Summer 2002
49
SCM
• Software Configuration Management
• Formal engineering discipline
• Methods and tools to identify & manage
software throughout its use
Q7503, Summer 2002
50
Configuration Control Needs
– Establish clearly defined mgmt. 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
Q7503, Summer 2002
51
Maintenance
• SCM is very important during all phases
starting with Requirements
• Continues to be important during
Maintenance
Q7503, Summer 2002
52
Homework
• McConnell: 11 “Motivation”, 13 “Team
Structure”
• Schwalbe: 8 “Project Human Resource
Management”
• Earned Value URL: See class web site
• Top 10 Risk List for your project
Q7503, Summer 2002
53
Questions?
Q7503, Summer 2002
54