1 / 32

C H A P T E R S E V E N

Learn the step-by-step process of managing risk in projects, including risk identification, assessment, response development, and contingency planning. Understand techniques such as scenario analysis and risk severity matrix.

blenahan
Download Presentation

C H A P T E R S E V E N

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. C H A P T E R S E V E N Managing Risk

  2. Risk Management Process

  3. The Risk Management Process

  4. Step 1: Risk Identification

  5. Organizations use risk breakdown structures (RBSs) in conjunction with work breakdown structures (WBSs) to help management teams identify and eventually analyze risks. • A risk profile is a list of questions that address traditional areas of uncertainty on a project. These questions have been developed and refined from previous, similar projects.

  6. Partial Risk Profile for Product Development Project

  7. Step 2: Risk Assessment • Scenario analysis is the easiest and most commonly used technique for analyzing risks. Team members assess the significance of each risk event in terms of: • Probability of the event • Impact of the event. • a relatively simple scale ranging from “very unlikely” to “almost certainly” may suffice for one project, whereas another project may use more precise numerical probabilities (e.g., 0.1, 0.3, 0.5, . . .). • Some scales may simply use rank-order descriptors, such as “low,” “moderate,” “high,” and “very high,” whereas others use numeric weights (e.g., 1–10).

  8. Defined Conditions for Impact Scales of a Risk on Major Project Objectives (Examples for negative impacts only)

  9. Risk Assessment Form

  10. Risk Severity Matrix

  11. Failure Mode and Effects Analysis (FMEA) extends the risk severity matrix by including ease of detection in the equation: Impact x Probability x Detection = Risk Value Probability Analysis

  12. Step 3: Risk Response Development • Mitigating Risk (1) reduce the likelihood that the event will occur and/ or (2) reduce the impact that the adverse event would have on the project. • For example, the fear that a vendor will be unable to supply customized components on time may be attributable to (1) poor vendor relationships, (2) design miscommunication, and (3) lack of motivation. As a result of this analysis the project manager may decide to take his counterpart to lunch to clear the air, invite the vendor to attend design meetings, and restructure the contract to include incentives for on-time delivery.

  13. Avoiding Risk For example, adopting proven technology instead of experimental technology can eliminate technical failure. Choosing an Australian supplier as opposed to an Indonesian supplier would virtually eliminate the chance that political unrest would disrupt the supply of critical materials. • Transferring Risk Passing risk to another party is common; this transfer does not change risk. Passing risk to another party almost always results in paying a premium for this exemption. Fixed-price contracts are the classic example of transferring risk from an owner to a contractor. The contractor understands his or her firm will pay for any risk event that materializes; therefore, a monetary risk factor is added to the contract bid price. Before deciding to transfer risk, the owner should decide which party can best control activities that would lead to the risk occurring.

  14. Retaining Risk • In some cases a conscious decision is made to accept the risk of an event occurring. • Some risks are so large it is not feasible to consider transferring or reducing the event (e.g., an earthquake or flood). • The project owner assumes the risk because the chance of such an event occurring is slim. • In other cases risks identified in the budget reserve can simply be absorbed if they materialize. The risk is retained by developing a contingency plan to implement if the risk materializes. • In a few cases a risk event can be ignored and a cost overrun accepted should the risk event occur.

  15. Contingency Planning • A contingency plan is an alternative plan that will be used if a possible foreseen risk event becomes a reality. • The contingency plan represents actions that will reduce or mitigate the negative impact of the risk event. • A key distinction between a risk response and a contingency plan is that a response is part of the actual implementation plan and action is taken before the risk can materialize, while a contingency plan is not part of the initial implementation plan and only goes into effect after the risk is recognized.

  16. Here is an example: • A high-tech niche computer company intends to introduce a new “platform” product at a very specific target date. The project’s 47 teams all agree delays will not be acceptable. • Their contingency plans for two large component suppliers demonstrate how seriously risk management is viewed. • One supplier’s plant sits on the San Andreas Fault, which is prone to earthquakes. The contingency plan has an alternative supplier, who is constantly updated, producing a replica of the component in another plant. • Another key supplier in Toronto, Canada, presents a delivery risk on their due date because of potential bad weather. This contingency plan calls for a chartered plane (already contracted to be on standby) if overland transportation presents a delay problem. • To outsiders these plans must seem a bit extreme, but in high-tech industries where time to market is king, risks of identified events are taken seriously.

  17. Risk Response Matrix

  18. Technical Risks • Technical risks are problematic; they can often be the kind that cause the project to be shut down. What if the system or process does not work? • Contingency or backup plans are made for those possibilities that are foreseen. • For example, Carrier Transicold was involved in developing a new Phoenix refrigeration unit for truck-trailer applications. This new unit was to use rounded panels made of bonded metals, which at the time was new technology for Transicold. • Furthermore, one of its competitors had tried unsuccessfully to incorporate similar bonded metals in their products. The project team was eager to make the new technology work, but it wasn’t until the very end of the project that they were able to get the new adhesives to bond adequately to complete the project. • Throughout the project, the team maintained a welded-panel fabrication approach just in case they were unsuccessful. • If this contingency approach had been needed, it would have increased production costs, but the project still would have been completed on time.

  19. Schedule Risks • Often organizations will defer the threat of a project coming in late until it surfaces. • Here contingency funds are set aside to expedite or “crash” the project to get it back on track. • Crashing, or reducing project duration, is accomplished by shortening (compressing) one or more activities on the critical path. • Cost Risks • Projects of long duration need some contingency for price changes—which are usually upward. • The important point to remember when reviewing price is to avoid the trap of using one lump sum to cover price risks. • For example, if inflation has been running about 3 percent, some managers add 3 percent for all resources used in the project.

  20. Funding Risks • What if the funding for the project is cut by 25 percent or completion projections indicate that costs will greatly exceed available funds? • What are the chances of the project being canceled before completion? • Seasoned project managers recognize that a complete risk assessment must include an evaluation of funding supply.

  21. Opportunity Management • The project management profession has identified four different types of response to an opportunity: • Exploit. This tactic seeks to eliminate the uncertainty associated with an opportunity to ensure that it definitely happens. Examples include assigning your best personnel to a critical burst activity to reduce the time to completion or revising a design to enable a component to be purchased rather than developed internally. • Share. This strategy involves allocating some or all of the ownership of an opportunity to another party who is best able to capture the opportunity for the benefit of the project. Examples include establishing continuous improvement incentives for external contractors or joint ventures. • Enhance. Enhance is the opposite of mitigation in that action is taken to increase the probability and/or the positive impact of an opportunity. Examples include choosing site location based on favorable weather patterns or choosing raw materials that are likely to decline in price. • Accept. Accepting an opportunity is being willing to take advantage of it if it occurs, but not taking action to pursue it.

  22. Contingency Funding and Time Buffers • Contingency funds are established to cover project risks—identified and unknown. • When, where, and how much money will be spent is not known until the risk event occurs. • Project “owners” are often reluctant to set up project contingency funds that seem to imply the project plan might be a poor one. Some perceive the contingency fund as an add-on slush fund • Others say they will face the risk when it materializes. • Usually such reluctance to establish contingency reserves can be overcome with documented risk identification, assessment, contingency plans, and plans for when and how funds will be disbursed. • In practice, the contingency reserve fund is typically divided into budget and management reserve funds for control purposes. • Budget reserves are set up to cover identified risks; these reserves are those allocated to specific segments or deliverables of the project.

  23. Budget Reserves • These reserves are identified for specific work packages or segments of a project found in the baseline budget or work breakdown structure. • For example, a reserve amount might be added to “computer coding” to cover the risk of “testing” showing a coding problem. The reserve amount is determined by costing out the accepted contingency or recovery plan. • The budget reserve should be communicated to the project team. This openness suggests trust and encourages good cost performance.

  24. Management Reserves • These reserve funds are needed to cover major unforeseen risks and, hence, are applied to the total project. • For example, a major scope change may appear necessary midway in the project. Because this change was not anticipated or identified, it is covered from the management reserve. Management reserves are established after budget reserves are identified and funds established. • These reserves are independent of budget reserves and are controlled by the project manager and the “owner” of the project. • The “owner” can be internal (top management) or external to the project organization. Most management reserves are set using historical data and judgments concerning the uniqueness and complexity of the project.

  25. Contingency Fund Estimate (Thousands of Dollars)

  26. Time Buffers • Just as contingency funds are established to absorb unplanned costs, managers use time buffers to cushion against potential delays in the project. And like contingency funds, the amount of time is dependent upon the inherent uncertainty of the project. • The more uncertain the project the more time should be reserved for the schedule. The strategy is to assign extra time at critical moments in the project. • For example, buffers are added to A. activities with severe risks. B. merge activities that are prone to delays due to one or more preceding activities being late. C. noncritical activities to reduce the likelihood that they will create another critical path. D. activities that require scarce resources to ensure that the resources are available when needed.

  27. Step 4: Risk Response Control • Project managers need to establish an environment in which participants feel comfortable raising concerns and admitting mistakes. • The norm should be that mistakes are acceptable, hiding mistakes is intolerable. Problems should be embraced not denied. • Participants should be encouraged to identify problems and new risks. Here a positive attitude by the project manager toward risks is a key. • A second key for controlling the cost of risks is documenting responsibility. This can be problematic in projects involving multiple organizations and contractors. • Responsibility for risk is frequently passed on to others with the statement, “That is not my worry.” This mentality is dangerous. • Each identified risk should be assigned (or shared) by mutual agreement of the owner, project manager, and the contractor or person having line responsibility for the work package or segment of the project. • It is best to have the line person responsible approve the use of budget reserve funds and monitor their rate of usage. If management reserve funds are required, the line person should play an active role in estimating additional costs and funds needed to complete the project.

  28. Change Control Management • Changes come from many sources such as the project customer, owner, project manager, team members, and occurrence of risk events. Most changes easily fall into three categories: 1. Scope changes in the form of design or additions represent big changes; for example, customer requests for a new feature or a redesign that will improve the product. 2. Implementation of contingency plans, when risk events occur, represent changes in baseline costs and schedules. 3. Improvement changes suggested by project team members represent another category.

  29. Change management systems involve reporting, controlling, and recording changes to the project baseline. (Note: Some organizations consider change control systems part of configuration management.) In practice most change management systems are designed to accomplish the following: 1. Identify proposed changes. 2. List expected effects of proposed change(s) on schedule and budget. 3. Review, evaluate, and approve or disapprove changes formally. 4. Negotiate and resolve conflicts of change, conditions, and cost. 5. Communicate changes to parties affected. 6. Assign responsibility for implementing change. 7. Adjust master schedule and budget. 8. Track all changes that are to be implemented.

  30. Change Control Process

  31. Sample Change Request

  32. The benefits derived from change control systems are the following: 1. Inconsequential changes are discouraged by the formal process. 2. Costs of changes are maintained in a log. 3. Integrity of the WBS and performance measures is maintained. 4. Allocation and use of budget and management reserve funds are tracked. 5. Responsibility for implementation is clarified. 6. Effect of changes is visible to all parties involved. 7. Implementation of change is monitored. 8. Scope changes will be quickly reflected in baseline and performance measures.

More Related