U08784 Software Project Management

1. U08784 Software Project Management lecturer: Timothy Au email: timothykfau@yahoo.com url: www.geocities/timothykfau/2007/u08784

2. What have we learnt last week • In this lecture, you will learn : • Project Estimation: An Introduction to COCOMO 5a • An Introduction to COCOMO (Word document)5b • An Introduction to Estimating 5c • The COnstructive COst MOdel (COCOMO) 5d • In the second-half lecture, • Week 2 Exercise Ex. COCOMO (Page 153-158) • Measure Software Quality (Page 163-175) 6a • Estimating Function Point Analysis (Page 186-192) 6e

3. Lecture 5 • In this lecture, you will learn : • Risk Management 3a • Risk Analysis Report • In the second-half lecture, • RMMM Report Example • RMMM Report 1 3b • RMMM Report 2 3c

4. Lecture Outcomes • You should be able to understand the following upon this lecture: • Risk Identification, Risk Analysis, Risk Treatment and Risk Mitigation • How to prepare a Risk Analysis report • Project Milestones • Have done your effort estimation: cost effort & duration • Prepare cost justification on your project • Refine your detailed project plan (individual) • Prepare risk treatment and mitigation plan for your project risks (risk analysis report) • Draft Quality Plan

5. Risk Analysis and Management • Risk • PM-BOK defines risk as • ‘an uncertain event or condition that, if occurs,, has a positive or negative effect on project’s objectives’. • PRINCE2 defines risk as • ‘the chance of exposure to the adverse consequences of future events.’

6. Risk Analysis and Management • Risk • concerns future happenings • involves change • involves choices • involves cause and effect • Risk concerns future changes and uncertainties and risk management deals with managing uncertainties. • Reactive and Proactive strategies • Risk can be dealt with reactive strategy – fire fighting mode. • A more intelligent strategy for risk management is to be proactive. • A proactive strategy begins long before • Potential risks are identified, their probabilities and impacts are assessed, and • they are ranked by importance. • Then, the software team establishes a plan for managing the risk. • The primary objective is to avoid risk, but because not all risks can be avoided, the team works to develop a contingency plan that will enable it to respond in a controlled and effective manner. • In this lecture, we will discuss a proactive strategy for risk management.

7. Risk Management • The risk management provides a systematic decision-making process to effectively deals with uncertainty in accomplishing program objectives. • Risk Identification. • Risk Analysis • Developing & Implementing Risk Mitigation Plan • Risk Monitoring and Tracking & Control

8. Risk Identification • Risk identification can be viewed from five different areas: • Project-wise risks • restricted or untimely funding, mandated schedules, excessive contractual requirements and constraints or political risks. • Technical risks • involves the risk of meeting performance requirement or a safety or security requirement and may also include risks in the feasibility of a design concept or the risks associated with using state-of-the-art hardware or software • Quality risks • occurs when the development practices that were to be used to develop a product are not actually followed. This can result in a product that does not satisfy requirements. • Logistics risks • include reliability, maintainability, operability and suitability concerns • Distribution risks • or operational risks (also called deployment risks) can result in improper installation and use of the product, which can, impact its use by customers

9. Factors affecting Cost and Schedule risks • Factors affecting Cost and Schedule risks • Uncertain requirements. • The requirements of the project are initially not known or well understood. This can result in very large cost and schedule estimation errors being built to a project. • Incorrect cost estimates. • Even if requirements are well understood, errors can occur during the estimation process. These can be as simple as data entry errors as complex as using unrealistic factors in the estimation model or not compensating for changes. • Requirement creeping. • Increase in system requirement is not reflected by a corresponding increase in budget or the schedule. • Schedule compression. • It is usually brought about by incorrect schedule estimates or commitments before the project starts or by pressure from upper management or the customer. Thus creates schedule risks and usually results in a non-linear increase in costs drastically! • Unreasonable budget. • It might be based on incorrect assumptions or analyze or on a decision that project will be bid for the price.

10. Factors affecting Requirement risks • Factors affecting Requirement risks • Incorrect cost estimates. • Requirements that attempts to specify user needs and customer expectations that contains errors. Most likely rework will be the result. • Incomplete requirements. • Requirements that do not specify desired product features or particular aspects of desired products features. Cost and schedule will both grow. • Inconsistent requirements. • Requirements that conflicts with other requirements. Rework and loss of quality will be likely the result. • Unexpectedly hard requirements. • Requirements that result in a technically difficult or complex product that is either difficult to design or to implement. Cost, schedule and quality are all put into risk. • Infeasible requirements. • Requirements that cannot be achieved using current available people, tools or technology.

11. Factors affecting Requirement risks • Factors affecting Requirement risks (continued) • Unclear requirements. • Requirements that have one ore more semantic interpretation. Rework is likely or customer dissatisfaction. • Unverifiable requirements. • Requirements that have no finite process exists to verify the products meet the requirements. Effort may be misdirected. • Untraceable requirements. • Requirements that have no audit trail from the requirements to tested code. Unpredictable effort may be expended. • Volatile requirements. • Requirements that are constantly changing as some requirements are added, removed, changed or reinterpreted. Cost, schedule and quality are all likely to impact

12. Categories of Risk • When risks are analyzed, it is important to quantify the level of uncertainty and the degree of loss associated of the risk. • To accomplish this, different categories of risks are considered: • Project Risks • It threaten the project plan. If the project risks become real, it is likely that the project schedule will slip and that costs will increase. • Technical Risks • It threaten the quality and timeliness of the software to be produced. If technical risk becomes a reality, implementation may become difficult or impossible. • Business Risks • It threatens the viability of the software to be built. Business risks often jeopardize the project or the product.

13. Risk Analysis • How big is the risk? • There are categories of risk that may affect the project: • Technical • Project Schedule • Cost • Business

14. Risk Analysis • Top TEN Risk List • The following is a list of risk Top Ten Risk in this week for the period of dd/mm/yyyy to dd/mm/yyyy:

15. Risk Analysis • Risk Grid

16. Risk Analysis • Likelihood • What is the Likelihood that the risk will happen?

17. Risk Analysis • Consequence • Given the risk is realized, what would be the magnitude of the impact?

18. Risk Estimation • Risk Exposure • RE = Probability x Cost Distribution of Software Growth and Resulting Exposure

19. Risk Mitigation, Monitoring and Management • All of the above risk analysis activities up to this point have a common goal • to assist the project team to develop a strategy for dealing with risk. • An effective strategy must consider the following THREE issues: • Risk avoidance (always the best strategy) • Risk monitoring • Risk management and contingency plan

20. Risk Mitigation • The risk mitigation plan:

21. Risk Treatment • Risk treatment: select risk mitigation process. How can you reduce the risk? • Risk Avoidance (always the preferred choice) • Risk Acceptance (or Assumption) • Problem Control (or Prevention) • Risk Transfer • Research & Knowledge

22. Risk Treatment • What next? • Assess the New Risk Level if implemented • High • Medium • Low • Action to be taken if implemented • Change budget to include Mitigation activities • Change planning to include Mitigation events • Change schedule to include Mitigation activities • Communicate changes to stakeholders • Estimating Risk Impacts and Avoidance Costs

23. Risk Analysis Document • A sample table of contents of a typical risk analysis document is as follows: • Introduction • Purpose • Risk Management • Risk Identification • TOP TEN Risk List • Risk Analysis • Risk Mitigation Strategy • Risk Mitigation Plan • Reference

24. Risk Analysis Document • Purpose • This document describes how we will perform the job of managing risks for <YourProject> System. The purpose of this risk mitigation plan is to outline the risks that have been identified by the team as having highest probability to impact our schedule. These risks have been categorized as High, Medium and Low. • The risk analysis and mitigation plan contains the following: • Risk identification – the project risks, technical risks and cost risks are categorized and listed. • A risk mitigation strategy and activities for each identified risks are planned

25. The RMMM Plan • The RMMM Plan is an integral part of your project plan • A risk management strategy can be included in the software plan • Or we can say the risk management steps can be organized into a separate Risk Mitigation, Monitoring and Management Plan (The RMMM Plan). • This RMMM Plan documents all works performed as part of the Risk Analysis and is used by the project manager as part of the overall project plan.