software project management

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?