1 / 54

Software Project Management

Software Project Management. Session 7: Risk and Change Management. Today. Exam Review Risk Management Feature Set Control Change Control Configuration Management. Session 6 Review. The exam MS-Project A fuller, slower review next week. Exam Review. 1. Phases A reference model

libitha
Télécharger la présentation

Software Project Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

More Related