Software Project Management Session 7 Risk and Change

Software Project Management Session 7: Risk and Change Management Q 7503, Summer 2002 1

Today • • • Exam Review Risk Management Feature Set Control Change Control Configuration Management Q 7503, Summer 2002 2

Session 6 Review • The exam • MS-Project – A fuller, slower review next week Q 7503, 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 Q 7503, 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 Q 7503, 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 Q 7503, 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 Q 7503, 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 Q 7503, 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) Q 7503, Summer 2002 9

Exam Review • 9. Organizational Types – Functional, project, matrix – Pros & Cons – What it means to a PM Q 7503, 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 Q 7503, Summer 2002 11

Exam Review • 11. Concept Exploration documents – SOW • More detailed • Can be used in Contracts – Project Charter • Higher-level overview – Other: RFP Q 7503, Summer 2002 12

Exam Review • 12. Estimation best practices – Q 12: A source of some confusion, I graded quite leniently (and allowed trade-offs with Q 15) – Estimate iteratively – Know presentation techniques • Q 3, +/- 2 months, 90% probability – Hierarchical breakdown of major activities – Not: dependencies, durations Q 7503, Summer 2002 13

Exam Review • 13. Three WBS Types – Process – Product – Hybrid – Others: Geographic, Organizational Q 7503, 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 Q 7503, Summer 2002 15

Exam Review • 15. Size Estimation Techniques – Expert Judgment – Analogy – Parametric • FP, LOC – Delphi Q 7503, 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 Q 7503, 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 (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 Q 7503, 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 Q 7503, 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 Q 7503, 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 Q 7503, Summer 2002 21

Types of Risks • Schedule compression (customer, marketing, etc. ) • Cost Risks • Unreasonable budgets • Requirements Risks • • Incorrect Incomplete Unclear or inconsistent Volatile Q 7503, Summer 2002 22

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

Risk Management Process “Software Risk Management”, Boehm, 1989 Q 7503, 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 Q 7503, 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 Q 7503, 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 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 Q 7503, 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 Q 7503, Summer 2002 28

Types of Unknowns • Known Unknowns – Information you know someone else has • Unknowns – Information that does not yet exist Q 7503, Summer 2002 29

Risk Control • Risk Management Plan – Can be 1 paragraph per risk – Mc. Connell’s example Q 7503, Summer 2002 30

Risk Resolution – Risk Avoidance • Don’t do it • Scrub from system • Off-load to another party – Mc. Connell: design issue: have client design – Risk Assumption • Don’t do anything about it • Accept that it might occur • But still watch for it Q 7503, Summer 2002 31

Risk Resolution – Problem control • Develop contingency plans • Allocate extra test resources • See Mc. Connell 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 Q 7503, 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 • Mc. Connell’s example Q 7503, 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 Q 7503, Summer 2002 34

Miniature Milestones • A risk-reduction technique • Use of small goals within project schedule – One of Mc. Connell’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 Q 7503, 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 Q 7503, Summer 2002 36

Miniature Milestones • Requires a detailed schedule • Have early milestones • Mc. Connell says 1 -2 days – Longer is still good (1 -2 weeks) • Encourages iterative development • Use binary milestones – Done or not done (100%) Q 7503, 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 Q 7503, Summer 2002 38

Traditional Specs • Drive for “traditional” specs – Necessity – Downstream cost avoidance – Full control over all aspects • As Mc. Connell 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 Q 7503, 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. ) Q 7503, 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 Summer 2002 Q 7503, items; involve key users 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 Q 7503, 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 Q 7503, 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 r 1 deficiencies • Users: want more functionality or now ‘know’ what they want • They will all try to ‘insert’ these during dev. Q 7503, Summer 2002 44

Mid-Project Feature-Creep • The devil is in the details • Mc. Connell’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. Q 7503, Summer 2002 45

Change Control Board (CCB) – Mc. Connell “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 Q 7503, Summer 2002 46

Change Control “Quality Software Project Management”, Futrell, Shafer Q 7503, 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 Q 7503, 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. Q 7503, Summer 2002 49

SCM • Software Configuration Management • Formal engineering discipline • Methods and tools to identify & manage software throughout its use Q 7503, 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 Q 7503, Summer 2002 51

Maintenance • SCM is very important during all phases starting with Requirements • Continues to be important during Maintenance Q 7503, Summer 2002 52

Homework • Mc. Connell: 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 Q 7503, Summer 2002 53

Questions? Q 7503, Summer 2002 54