1 / 19

Project Risk

Project Risk. Failure Rates of IT Projects. 31% of all IT projects are cancelled. 53% are partially completed with only 61% of its original functionality. 16% are completed on time, on budget, and on-capability. Of those not delivered on-schedule or on-budget: Average budget overrun is 189%;

Télécharger la présentation

Project Risk

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Project Risk

  2. Failure Rates of IT Projects • 31% of all IT projects are cancelled. • 53% are partially completed with only 61% of its original functionality. • 16% are completed on time, on budget, and on-capability. • Of those not delivered on-schedule or on-budget: • Average budget overrun is 189%; • Average schedule overrun is 222% Standish Group, 2005

  3. Project Risk Management • Project risk is the chance that an undesirable event will occur and that the consequences of its occurrence will adversely impact the project. • Risk management attempts to recognize and manage potential and unforeseen trouble spots that may occur when the project is implemented. • Risk management identifies as many risk events as possible (what can go wrong), minimizes their impact (what can be done about it before the project begins), and manages responses to those events that do materialize (contingency plans).

  4. The cost of managing risk in a project is less if the event occurs earlier rather than later. Identifying project risks and deciding a response before the project begins is the best approach.

  5. A Real-World Example 1999 NASA Mars Climate Orbiter • Lockheed Martin botched the design of critical navigation software. While flight computers on the ground did calculations based on pounds of thrust per second, the spacecraft’s computer software used metric systems called newtons. • A check to see if the values were compatible was never done. • After the nine month journey to the Red Planet, the $125 • million probe approached Mars at too low an altitude and • burned up in the planet’s atmosphere.

  6. Risk management is a proactive approach rather than reactive. • It is a preventive process designed to ensure that surprises are reduced and that negative consequences associated with undesirable events are minimized. • It also prepares the project manager to take risk when a time, cost, and/or technical advantage is possible. • Successful management of project risk gives the project manager better control over the future and can significantly improve chances of reaching project objectives successfully.

  7. Risk Identification: Risk Assessment: Risk Response Development: Risk Response Control:

  8. Risk Identification • Occurs during the planning phase. • Use brainstorming and other techniques to identify potential problems. • Generate as many probable risks as possible. • Focus on events that could produce risk, rather than consequences. • Example: Focusing on the failure to meet the schedule as a possible risk, rather than on the events or conditions that could cause this to happen. • Focus first on risks to the entire project, then focus on specific sections after the project-wide risks have been identified.

  9. Examples of Project-Wide Risks • Technical Requirements • Are the requirements stable and do-able? • Are quality considerations and controls built into the development process? • Design • Does the design depend on unrealistic or optimistic assumptions? • Development • Is the development process supported by procedures, methods and tools? • Testing • Will testing procedures and equipment be available when needed? • Scheduling • Does the schedule reflect realistic measures of task/time requirements? • Is the schedule dependent on the completion of other projects?

  10. Examples of Project-Wide Risks • Budgeting • How reliable are cost estimates? • Are sources of funding for the project stable and available? • Staffing • Is the team inexperienced or understaffed? • Work Environment • Do people and organizations work cooperatively across functional boundaries? • Management • Do people know who has authority for what? • Customer • Does the customer understand what it will take to complete the project? • Contractors • Are there ambiguities in contractor task definitions?

  11. Risk Assessment Scenario analysis is the easiest and most commonly used technique for analyzing risks. Team members assess each risk in terms of: 1. The undesirable event. 2. All the outcomes of the event’s occurrence. 3. The magnitude or severity of the event’s impact. 4. Chances/probability of the event happening. 5. When the event might occur in the project. 6. Interaction with other parts of this or other projects.

  12. Risk Response Development Reducing risk is usually the first alternative considered. There are basically two strategies for mitigating risk: • Reduce the likelihood that the event will occur. • Reduce the impact that the adverse event would have on the project. • Transfer the risk (subcontract). • Retain the risk. • If the risk is high, budget reserves will serve to absorb the consequences of the risk.

  13. Contingency Planning A contingency plan is an alternative plan that will be used if a possible foreseen risk event becomes a reality. • Represents preventive actions that will reduce or mitigate the negative impact of the risk event. • Answers the questions of what, where, when, and how action will take place. • Conditions for activating the contingency plan should be clearly documented. • The plan should include a cost estimate and identify the source of funding. • All parties affected should agree to the contingency plan and have authority to make commitments. • Contingency plans should be communicated to team members so that surprise and resistance are minimized.

  14. Contingency Funding Contingency funds are established to cover errors in estimates, omissions, and uncertainties that may materialize as the project is implemented. • In practice, contingencies run from 1 to 10 percent in projects similar to past projects. • In high-technology projects it is not uncommon to find contingencies running in the 20 to 60 percent range.

  15. Risk Response Control • Project managers need to monitor risks just like they track project progress. • An environment needs to be created in which participants feel comfortable raising concerns and admitting mistakes. • A key for controlling the cost of risks is documenting responsibility. • Identified risks should be assigned (or shared) by mutual agreement of the client, project manager, and the contractor or person responsible for the work package or segment of the project.

  16. Change Control Management A major element of the risk control process is change management. • Common sources of change: 1. Scope changes in the form of design or additions represent big changes. Example: Client requests for a new feature or a redesign that will improve the product. 2. Implemented contingency plans represent changes in baseline costs and schedules. 3. Improvement changes suggested by project team members.

  17. Change Control Management • Change requests must go through a formal review and approval process. • Inconsequential changes are discouraged by the formal process. • Costs of changes are documented. • Integrity of the WBS and performance measures is maintained. • Allocation and use of budget and management reserve funds are tracked. • Responsibility for implementation is clarified. • Effect of changes is visible to all parties involved. • Scope changes will be quickly reflected in baseline and performance measures.

  18. The Bottom Line • The essence of project management is risk management. • Managers practice risk management activities to compensate for the uncertainty inherent in project management. • In any sizable project, things never go according to plan.

  19. Questions??Comments??

More Related