Risk Management Framework: Risk Response Development

Published Categorized as Trends
risk response
risk response

When a risk event is identified and assessed, a decision must be made concerning which response is appropriate for the specific event.This will be the third process inside an effective risk management framework and you need to take notice if it’s importance and impact on the project.

Responses to risk can be classified as mitigating, avoiding, transferring, sharing, or retaining.

Risk Response: Mitigating

Reducing risk is usually the first alternative considered. There are basically two strategies for mitigating risk:

  • reduce the likelihood that the event will occur
  • and/or
  • reduce the impact that the adverse event would have on the project.

Most risk teams focus first risk response, reducing the likelihood of risk events since, if successful, this may eliminate the need to consider the potentially costly second strategy.

Testing and prototyping are frequently used to prevent problems from surfacing later in a project.

An example of testing can be found in an information systems project. The project team was responsible for installing a new operating system in their parent company.

Before implementing the project, the team tested the new system on a smaller isolated network. By doing so they discovered a variety of problems and were able to come up with solutions prior to implementation.

The team still encountered problems with the installation but the number and severity were greatly reduced.

Often identifying the root causes of an event is useful.

For example, the fear that a vendor will be unable to supply customized components on time may be attributable to:

  • poor vendor relationships
  • design miscommunication
  • 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.

Other examples of reducing the probability of risks occurring are scheduling outdoor work during the summer months, investing in up-front safety training, and choosing high-quality materials and equipment.

When the concerns are that duration and costs have been underestimated, as a risk response managers will augment estimates to compensate for the uncertainties. It is common use a ratio between old and new project to adjust time or cost. The ratio typically serves as a constant.

For example, if past projects have taken 10 minutes per line of computer code, a constant of 1.10 (which represents a 10 percent increase) would be used for the proposed project time estimates because the new project is more difficult than prior projects.

An alternative mitigation strategy is to reduce the impact of the risk if it occurs.

For example, a bridge-building project illustrates risk reduction. A new bridge project for a coastal port was to use an innovative, continuous cement-pouring process developed by an Australian firm to save large sums of money and time.

The major risk was that the continuous pouring process for each major section of the bridge could not be interrupted. Any interruption would require that the whole cement section (hundreds of cubic yards) be torn down and started over.

An assessment of possible risks centered on delivery or the cement from the cement factory. Trucks could be delayed, or the factory could break down. Such risks would result in tremendous rework costs and delays.

As a risk response the company decided to have two additional portable cement plants built nearby on different highways within 20 miles of the bridge project in case the main factory supply was interrupted. These two portable plants carried raw materials for a whole bridge section, and extra trucks were on immediate standby each time continuous pouring was required.

Similar risk response scenarios are apparent in system and software development projects where parallel innovation processes are used in case one fails.

Risk Response: Avoiding

Risk avoidance is changing the project plan to eliminate the risk or condition. Although it is impossible to eliminate all risk events, some specific risks may avoided before you launch the project.

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.

Risk Response: Transferring

One of the most common risk response is passing the risk to another party; 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 on this risk response, the owner should decide which party can best control activities that would lead to the risk occurring. Also, is the contractor capable of absorbing the risk? Clearly identifying and documenting responsibility for absorbing risk is imperative.

Another more obvious way to transfer risk is insurance. However, in most cases this is impractical because defining the project risk event and conditions to an insurance broker who is unfamiliar with the project is difficult and usually expensive.

Of course, low-probability and high-consequence risk events such as acts of God are more easily defined and insured. Performance bonds, warranties, and guarantees are other financial instruments used to transfer risk.

On large, international construction projects like petrochemical plants and oil refineries, host countries are insisting on contracts that enforce Build-own-operate-Transfer (BOOT) provisions. Here the prime project organization is expected not only to build the facility, but also to take over ownership until its operation capacity has been proven and all the debugging has occurred before final transfer of ownership to the client.

In such cases, the host country has transferred financial risk of ownership until the project has been completed and capabilities proven.

Risk Response: Retaining

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 to none.

In other cases risks identified in the budget reserve can simply be absorbed if they materialize. The risk response is applied 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.

The more effort given to the particular risk response before the project begins, the better the chances are for minimizing project surprises. Knowing that the risk response to an event will be retained, transferred, or mitigated greatly reduces stress and uncertainty.

Again, control is possible with this structured approach.

More information about the topic of Risk Response Development is available in these articles:

  • Risk Management Framework: Contingency Planning
  • Risk Management Framework: Risk Types (some or the most common methods for handling risk)
  • Risk Management Framework: Opportunity Management
  • Risk Management Framework: Contingency Funding and Time Buffers

Also you can always go back to the Risk Management Guide post and continue reading from there, or you can continue from here to read: Risk Response Control.

By Alex Puscasu

I am a Project Management practitioner with more than 5 years experience in hardware and software implementation projects. Also a bit of a geek and a great WordPress enthusiast. I hope you enjoy the content, and I encourage you to share your knowledge with the world.

Exit mobile version