Q7503, Summer 2002 1
Software Project Management
Session 7: Risk and Change Management
Q7503, Summer 2002 2
Today
• Exam Review
• Risk Management
• Feature Set Control
• Change Control
• Configuration Management
Q7503, Summer 2002 3
Session 6 Review
• The exam
• MS-Project– A fuller, slower review next week
Q7503, Summer 2002 4
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 5
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 6
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 7
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 8
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 9
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 10
Exam Review
• 9. Organizational Types– Functional, project, matrix– Pros & Cons– What it means to a PM
Q7503, Summer 2002 11
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 12
Exam Review
• 11. Concept Exploration documents– SOW
• More detailed
• Can be used in Contracts
– Project Charter• Higher-level overview
– Other: RFP
Q7503, Summer 2002 13
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 14
Exam Review
• 13. Three WBS Types– Process– Product– Hybrid– Others: Geographic, Organizational
Q7503, Summer 2002 15
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 16
Exam Review
• 15. Size Estimation Techniques– Expert Judgment– Analogy– Parametric
• FP, LOC
– Delphi
Q7503, Summer 2002 17
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 18
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 19
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 20
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 21
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 22
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 23
Types of Risks
• Quality Risks
• Operational Risks
• Most of the “Classic Mistakes”– Classic mistakes are made more often
Q7503, Summer 2002 24
Risk Management Process
Risk Management
Risk Assesment
Risk Control
Risk Identification
Risk Analysis
Risk Prioritization
Risk Management Planning
Risk Resolution
Risk Monitoring
“Software Risk Management”, Boehm, 1989
Q7503, Summer 2002 25
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 26
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 27
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
Q7503, Summer 2002 28
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 29
Types of Unknowns
• Known Unknowns– Information you know someone else has
• Unknown Unknowns– Information that does not yet exist
Q7503, Summer 2002 30
Risk Control
• Risk Management Plan– Can be 1 paragraph per risk– McConnell’s example
Q7503, Summer 2002 31
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 32
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 33
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 34
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 35
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 36
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 37
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 38
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 39
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 40
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 41
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; involve key users
Q7503, Summer 2002 42
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 43
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 44
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 45
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 46
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 47
Change Control
“Quality Software Project Management”, Futrell, Shafer, Shafer
ChangeControlSystem
CMSystem
CM Tool
Q7503, Summer 2002 48
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 49
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 50
SCM
• Software Configuration Management
• Formal engineering discipline
• Methods and tools to identify & manage software throughout its use
Q7503, Summer 2002 51
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 52
Maintenance
• SCM is very important during all phases starting with Requirements
• Continues to be important during Maintenance
Q7503, Summer 2002 53
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 54
Questions?