software project management
TRANSCRIPT
![Page 1: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/1.jpg)
Q7503, Summer 2002 1
Software Project Management
Session 7: Risk and Change Management
![Page 2: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/2.jpg)
Q7503, Summer 2002 2
Today
• Exam Review
• Risk Management
• Feature Set Control
• Change Control
• Configuration Management
![Page 3: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/3.jpg)
Q7503, Summer 2002 3
Session 6 Review
• The exam
• MS-Project– A fuller, slower review next week
![Page 4: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/4.jpg)
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
![Page 5: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/5.jpg)
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
![Page 6: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/6.jpg)
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
![Page 7: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/7.jpg)
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
![Page 8: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/8.jpg)
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
![Page 9: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/9.jpg)
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)
![Page 10: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/10.jpg)
Q7503, Summer 2002 10
Exam Review
• 9. Organizational Types– Functional, project, matrix– Pros & Cons– What it means to a PM
![Page 11: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/11.jpg)
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
![Page 12: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/12.jpg)
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
![Page 13: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/13.jpg)
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
![Page 14: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/14.jpg)
Q7503, Summer 2002 14
Exam Review
• 13. Three WBS Types– Process– Product– Hybrid– Others: Geographic, Organizational
![Page 15: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/15.jpg)
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
![Page 16: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/16.jpg)
Q7503, Summer 2002 16
Exam Review
• 15. Size Estimation Techniques– Expert Judgment– Analogy– Parametric
• FP, LOC
– Delphi
![Page 17: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/17.jpg)
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
![Page 18: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/18.jpg)
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
![Page 19: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/19.jpg)
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
![Page 20: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/20.jpg)
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
![Page 21: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/21.jpg)
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
![Page 22: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/22.jpg)
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
![Page 23: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/23.jpg)
Q7503, Summer 2002 23
Types of Risks
• Quality Risks
• Operational Risks
• Most of the “Classic Mistakes”– Classic mistakes are made more often
![Page 24: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/24.jpg)
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
![Page 25: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/25.jpg)
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
![Page 26: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/26.jpg)
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
![Page 27: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/27.jpg)
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
![Page 28: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/28.jpg)
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
![Page 29: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/29.jpg)
Q7503, Summer 2002 29
Types of Unknowns
• Known Unknowns– Information you know someone else has
• Unknown Unknowns– Information that does not yet exist
![Page 30: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/30.jpg)
Q7503, Summer 2002 30
Risk Control
• Risk Management Plan– Can be 1 paragraph per risk– McConnell’s example
![Page 31: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/31.jpg)
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
![Page 32: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/32.jpg)
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
![Page 33: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/33.jpg)
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
![Page 34: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/34.jpg)
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
![Page 35: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/35.jpg)
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
![Page 36: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/36.jpg)
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
![Page 37: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/37.jpg)
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%)
![Page 38: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/38.jpg)
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
![Page 39: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/39.jpg)
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
![Page 40: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/40.jpg)
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.)
![Page 41: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/41.jpg)
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
![Page 42: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/42.jpg)
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
![Page 43: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/43.jpg)
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
![Page 44: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/44.jpg)
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.
![Page 45: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/45.jpg)
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.
![Page 46: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/46.jpg)
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
![Page 47: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/47.jpg)
Q7503, Summer 2002 47
Change Control
“Quality Software Project Management”, Futrell, Shafer, Shafer
ChangeControlSystem
CMSystem
CM Tool
![Page 48: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/48.jpg)
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
![Page 49: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/49.jpg)
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.
![Page 50: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/50.jpg)
Q7503, Summer 2002 50
SCM
• Software Configuration Management
• Formal engineering discipline
• Methods and tools to identify & manage software throughout its use
![Page 51: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/51.jpg)
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
![Page 52: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/52.jpg)
Q7503, Summer 2002 52
Maintenance
• SCM is very important during all phases starting with Requirements
• Continues to be important during Maintenance
![Page 53: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/53.jpg)
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
![Page 54: Software Project Management](https://reader035.vdocuments.net/reader035/viewer/2022070318/5578885dd8b42a02618b4cde/html5/thumbnails/54.jpg)
Q7503, Summer 2002 54
Questions?