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

2. Q7503, Summer 2002 2 Today Exam Review Risk Management Feature Set Control Change Control Configuration Management

3. Q7503, Summer 2002 3 Session 6 Review The exam MS-Project –A fuller, slower review next week

4. Q7503, Summer 2002 4 Exam Review 1. PhasesPhases –A reference model –Many other models are just as good or valid 2. Tradeoff TriangleTriangle –Dependency of 3 sides –Determining which is fixed or most important to customer –Balance –Give-and-take Often choose two

5. 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

6. 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

7. 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

8. 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

9. Q7503, Summer 2002 9 Exam Review 7. Waterfall riskrisk –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)

10. Q7503, Summer 2002 10 Exam Review 9. Organizational Types –Functional, project, matrix –Pros & Cons –What it means to a PM

11. 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

12. 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

13. 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

14. Q7503, Summer 2002 14 Exam Review 13. Three WBS TypesWBS –Process –Product –Hybrid –Others: Geographic, Organizational

15. Q7503, Summer 2002 15 Exam Review 14. Fast tracking and crashingcrashing –Crashing sounds worse than it is 3 ways discussed –Add resources, limit requirements, change task sequence –Fast tracking Overlapping of activities

16. Q7503, Summer 2002 16 Exam Review 15. Size Estimation Techniques –Expert Judgment –Analogy –Parametric FP, LOC –Delphi

17. Q7503, Summer 2002 17 Exam Review 16. DependenciesDependencies –Mandatory: “hard”, dev. before QA –External: vendor or client –Discretionary: PM determines, “soft” –Resource –Not really the FS, SF, SS, FF

18. 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 (2 nd 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

19. 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

20. 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

21. 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

22. 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

23. Q7503, Summer 2002 23 Types of Risks Quality Risks Operational Risks Most of the “Classic Mistakes” –Classic mistakes are made more often

24. Q7503, Summer 2002 24 Risk Management Process “Software Risk Management”, Boehm, 1989

25. 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 riskschecklist

26. 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

27. 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

28. 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

29. Q7503, Summer 2002 29 Types of Unknowns Known Unknowns –Information you know someone else has Unknown Unknowns –Information that does not yet exist

30. Q7503, Summer 2002 30 Risk Control Risk Management Plan –Can be 1 paragraph per risk –McConnell’s exampleexample

31. 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

32. 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

33. 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 exampleexample

34. 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

35. 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

36. 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

37. 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%)

38. 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

39. 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

40. 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.)

41. 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

42. 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

43. 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

44. 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.

45. 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.

46. 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

47. Q7503, Summer 2002 47 Change Control “Quality Software Project Management”, Futrell, Shafer, Shafer

48. 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

49. 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, trackingProposalevaluation 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.

50. Q7503, Summer 2002 50 SCM Software Configuration Management Formal engineering discipline Methods and tools to identify & manage software throughout its use

51. 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 phaseConfiguration Management Plan Often part of Software Development Plan

52. Q7503, Summer 2002 52 Maintenance SCM is very important during all phases starting with Requirements Continues to be important during Maintenance

53. 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

54. Q7503, Summer 2002 54 Questions?