Software Project Management

1. Software Project Management
Today’s Topic
Risk and Change Management

2. Risk Management

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

4. Risk Management
• Identification, Analysis, Control
• Goal: avoid a crisis
– Proactive vs. reactive

5. Project Risk
• Characterized by:
– Uncertainty (0 < probability < 1)
– An associated loss (money, life, reputation,
etc)
– Manageable – some action can control it

6. Types of Risks
• Schedule Risks
• Schedule compression (customer, marketing, etc.)
• Cost Risks
• Unreasonable budgets
• Requirements Risks
• Incorrect
• Incomplete
• Unclear or inconsistent
• Volatile

7. Types of Risks
• Quality Risks
• Operational Risks
• Most of the “Classic Mistakes”
– Classic mistakes are made more often

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

9. Risk Identification
• Get your team involved in this process
– Don’t go it alone
• Produce a list of risks with potential to
disrupt your project’s schedule
• Use a checklist or similar source to
brainstorm possible risks

10. Risk Analysis
• Determine impact of each risk
• Risk Exposure (RE)
• Also known as “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

11. Risk Prioritization
• Often want larger-loss risks higher
– Or higher probability items
• Possibly group ‘related risks’
• Helps identify which risks to ignore
– Those at the bottom

12. Risk Control
• Risk Management Plan
– Can be 1 paragraph per risk

13. • Risk Mitigation, Monitoring and
Management
Up to this point we have identified different types
of risks
If a software team adopts a proactive approach
to risk then the team can easily avoid the risk or
in other words can easily mitigate the risk

14. • Example
• To mitigate the risk, a project
management must develop a plan for
reducing turn over( before the start of
project).
• Meet with the staff to determine the
causes of turnover( poor working
conditions, low salary etc)

15. • Once the project commences, assume
turnover will occur then adopt the other
mitigation
• Proper documentation
• Backup for each people
• Conduct reviews for information spreading

16. • Monitoring
As the project proceeds, risk monitoring
activities commence
In case of high staff turn over, the following
factors can be monitored
General attitude of the teams
Interpersonal relationships
Problems with salary and Compensations
Availability of jobs in the market

17. • Management
When the mitigation plan fails and the risks
actually happens then in this case we have
contingency plan

18. Risk Monitoring
• Top 10 Risk List
• Rank
• Previous Rank
• Weeks on List
• Risk Name
• Risk Resolution Status

19. Risk Communication
• Don’t be afraid to convey the risks
• Use your judgment to balance
– Sky-is-falling whiner vs. information
distribution

20. Software Configuration
Management
Change is inventible when computer
software is built
Any change increases the level of
confusion among the software engineers
who are working on the project.
Confusion arises when changes are not
analyzed before they are made

21. Software Configuration
Management
• CM is the art to identifying,
organizing and controlling
modifications to the software
being built by a team
• CM is an umbrella activity.
• There is difference between
software maintenance and CM `

22. Software Configuration
Management
• Software Configuration Item
Any document produced during software
development
System Specs.
Project plan
SRS
Design specs
Testing specs etc

23. Software Configuration
Management
• Baseline
A specification or product that has been
formally reviewed and agreed upon that
there after serves as the basis for further
development and that can be changed
only through formal change control
procedure

24. Software Configuration
Management
• SCM Process
Identification of Configuration Items
Version Control
Change control (CCB)
Configuration Audit
Status Reporting