PROJECT RISK MANAGEMENT PROCESSES

PROJECT RISK MANAGEMENT PROCESSES

BY

AMAKOM TOCHUKWU

Introduction

Project risk management is an important aspect of project management. Project risks exist because of uncertainty. There is always the possibility that something known or unknown could impact the achievement of your projects goals. Risk management is about being prepared to handle these risks.

Managing risks on projects is a process that includes risk assessment and a mitigation strategy for those risks. Risk assessment includes both the identification of potential risk and the evaluation of the potential impact of the risk. A risk mitigation plan is designed to eliminate or minimize the impact of the risk events—occurrences that have a negative impact on the project. Identifying risk is both a creative and a disciplined process. The creative process includes brainstorming sessions where the team is asked to create a list of everything that could go wrong. All ideas are welcome at this stage with the evaluation of the ideas coming later.

What is project risk management?

project risk is defined by Project Management Institute (PMI) as an uncertain event or condition that if it occurs, has a positive or negative effect on a projects objective.

The purpose of project risk management is to identify project risks and develop strategies to prevent them from occurring or minimize their impact to the project if they occur.

Here are the 5 steps of risk management that every project manager has to know.

RISK IDENTIFICATION:

the first step of risk management is to identify any risks that may impact your project. You are answering the question, “what could go wrong?”. It is important to encourage critical thinking when trying to identify risks.

Risks such as operational or business risks will be handled by the relevant teams. The risks that often impact a project are supplier risk, resource risk and budget risk.

Supplier risk would refer to risks that can occur in case the supplier is not meeting the timeline to supply the required resources.

Resource risk occurs when the human resource used in the project is not enough or not skilled enough.
Budget risk would refer to risks that can occur if the costs are more than what was budgeted.

There are some techniques that can be used to identify risks and they include: brain storming, interviewing, risk profiles, historical data, assumptions analysis and work break down structure analysis. Some examples of categories for potential risks include: technical, cost, schedule, client, contractual, weather, financial, political, environmental and people.

Inputs to Risk Identification

.1 Product description. The nature of the product of the project will have a major effect on the risks identified. Products that involve proven technology will, all other things being equal, involve less risk than products which require innovation or invention.
Risks associated with the product of the project are often described in terms of their cost and schedule impact.
.2 Other planning outputs. The outputs of the processes in other knowledge areas should be reviewed to identify possible risks. For example:
• Work breakdown structure—non-traditional approaches to detail deliverables may offer opportunities that were not apparent from the higher-level deliverables identified in the scope statement.
• Cost estimates and duration estimates—aggressive estimates and estimates developed with a limited amount of information entail more risk.
• Staffing plan—identified team members may have unique skills that would be hard to replace or may have other commitments that make their availability tenuous.
• Procurement management plan—market conditions such as a sluggish local economy may offer opportunities to reduce contract costs.
.3 Historical information. Historical information about what actually happened on previous projects can be especially helpful in identifying potential risks. Information on historical results is often available from the following sources:
• Project files—one or more of the organizations involved in the project may maintain records of previous project results that are detailed enough to aid in risk identification. In some application areas, individual team members may maintain such records.
• Commercial databases—historical information is available commercially in many application areas.
• Project team knowledge—the individual members of the project team may remember previous occurrences or assumptions. While such recollections may be useful, they are generally less reliable than documented results.

Tools and Techniques for Risk Identification

.1 Checklists. Checklists are typically organized by source of risk. Sources include the project context, the product of the project or technology issues, and internal sources such as team member skills (or the lack thereof). Some application areas have widely used classification schemes for sources of risk.

1. Flowcharting. Flowcharting can help the project team better understand the causes and effects of risks.
   .3 Interviewing. Risk-oriented interviews with various stakeholders may help identify risks not identified during normal planning activities. Records of pre-project interviews (e.g., those conducted during a feasibility study) may also be available.

Outputs from Risk Identification

.1 Sources of risk. Sources of risk are categories of possible risk events (e.g., stakeholder actions, unreliable estimates, team turnover) that may affect the project for better or worse. The list of sources should be comprehensive, i.e., it should generally include all identified items regardless of frequency, probability of occurrence, or magnitude of gain or loss. Common sources of risk include:
• Changes in requirements.
• Design errors, omissions, and misunderstandings.
• Poorly defined or understood roles and responsibilities.
• Poor estimates.
• Insufficiently skilled staff.
Descriptions of the sources of risk should generally include estimates of (a) the probability that a risk event from that source will occur, (b) the range of possible outcomes, (c) expected timing, and (d) anticipated frequency of risk events from that source.
2 Potential risk events. Potential risk events are discrete occurrences such as a natural disaster or the departure of a specific team member that may affect the project. Potential risk events should be identified in addition to sources of risk when the probability of occurrence or magnitude of loss is relatively large (“relatively large” will vary by project). While potential risk events are seldom application-area-specific, a list of common risk events usually is. For example:
• Development of new technology that will obviate the need for a project is common in electronics and rare in real estate development.
• Losses due to a major storm are common in construction and rare in biotechnology. Descriptions of potential risk events should generally include estimates of (a) the
probability that the risk event will occur, (b) the alternative possible outcomes, (c) timing of the event, and (d) anticipated frequency (i.e., can it happen more than once).
.3 Risk symptoms. Risk symptoms, sometimes called triggers, are indirect manifestations of actual risk events. For example, poor morale may be an early warning signal of an impending schedule delay or cost overruns on early activities may be indicative of poor estimating.
.4 Inputs to other processes. The risk identification process may identify a need for further activity in another area. For example, the work breakdown structure may not have sufficient detail to allow adequate identification of risks.
Risks are often input to the other processes as constraints or assumptions.

RISK ANALYSIS:

once you have a list of the potential risks, you need to determine which risks need to be manged. Here, you ask questions like, what stage is the risk in? what is the nature of the risk? What can you do to eliminate or avoid the risk?
Generally, those risks that would have the greatest impact to the project as well as those that are more likely to occur are the ones that should be focused on.

Qualitative risk analysis information can be plotted on A Risk Assessment Matrix which incorporates the risk rating rules.
Quantitative risk management methods include the Monte Carlo Technique, sensitivity analysis and expected monetary value analysis.

Inputs to Risk Quantification

.1 Stakeholder risk tolerances. Different organizations and different individuals have different tolerances for risk. For example:
.2 Sources of risk.
.3 Potential risk events.
.4 Cost estimates.
.5 Activity duration estimates.

Tools and Techniques for Risk Quantification

.1 Expected monetary value. Expected monetary value, as a tool for risk quantification, is the product of two numbers:
• Risk event probability—an estimate of the probability that a given risk event will occur.
• Risk event value—an estimate of the gain or loss that will be incurred if the risk event does occur.
.2 Statistical sums. Statistical sums can be used to calculate a range of total project costs from the cost estimates for individual work items.
.3 Simulation. Simulation uses a representation or model of a system to analyse the behaviour or performance of the system. The most common form of simulation on a project is schedule simulation using the project network as the model of the project. Most schedule simulations are based on some form of Monte Carlo analysis. This technique, adapted from general management, “performs” the project many times to provide a statistical distribution of the calculated results.
.4 Decision trees. A decision tree is a diagram that depicts key interactions among decisions and associated chance events as they are understood by the decision maker. The branches of the tree represent either decisions (shown as boxes) or chance events (shown as circles).
.5 Expert judgment. Expert judgement can often be applied in lieu of or in addition to the mathematical techniques described above. For example, risk events could be described as having a high, medium, or low probability of occurrence and a severe, moderate, or limited impact.

Outputs from Risk Quantification

.1 Opportunities to pursue, threats to respond to. The major output from risk quantification is a list of opportunities that should be pursued and threats that require attention.
.2 Opportunities to ignore, threats to accept. The risk quantification process should also document (a) those sources of risk and risk events that the project management team has consciously decided to accept or ignore and (b) who made the decision to do so.

RISK RESPONSE DEVELOPMENT:

For each risk, there are four response strategies that you can choose.

Avoid- risk avoidance is possible by making a change to the project management plan. E.g. extending or shortening the schedule, changing the project strategy or reducing scope.

Transfer- this involves passing the risk to a third party. E.g. insurance, performance bonds, warranties, fixed price contracts and guarantees.

Mitigate- this means to reduce the probability or impact of a risk event. Example, safety training, simplification of the processes, choosing a stable supplier and redundant activities.

Acceptance- this strategy can be passive where the project team decides to just deal with the risk if it occurs or it can be active where the project team has a contingency reserve allocated and plan in case the risk occurs.

Inputs to Risk Response Development

.1 Opportunities to pursue, threats to respond to.
.2 Opportunities to ignore, threats to accept.
These items are input to the risk response development process because they should be documented in the risk management plan.

Tools and Techniques for Risk Response Development

.1 Procurement. Procurement, acquiring goods or services from outside the immediate project organization, is often an appropriate response to some types of risk. For example, risks associated with using a particular technology may be mitigated by contracting with an organization that has experience with that technology.
.2 Contingency planning. Contingency planning involves defining action steps to be taken if an identified risk event should occur.
.3 Alternative strategies. Risk events can often be prevented or avoided by changing the planned approach. For example, additional design work may decrease the number of changes which must be handled during the implementation or construction phase.
.4 Insurance. Insurance or an insurance-like arrangement such as bonding is often available to deal with some categories of risk. The type of coverage available and the cost of coverage varies by application area.

Outputs from Risk Response Development

.1 Risk management plan. The risk management plan should document the procedures that will be used to manage risk throughout the project. In addition to documenting the results of the risk identification and risk quantification processes, it should cover who is responsible for managing various areas of risk, how the initial identification and quantification outputs will be maintained, how contingency plans will be implemented, and how reserves will be allocated. A risk management plan may be formal or informal, highly detailed or broadly framed, based on the needs of the project.
.2 Inputs to other processes. Selected or suggested alternative strategies, contingency plans, anticipated procurements, and other risk-related outputs must all be fed back into the appropriate processes in the other knowledge areas.
.3 Contingency plans. Contingency plans are pre-defined action steps to be taken if an identified risk event should occur. Contingency plans are generally part of the risk management plan, but they may also be integrated into other parts of the overall project plan (e.g., as part of a scope management plan or quality management plan).
.4 Reserves. A reserve is a provision in the project plan to mitigate cost and/or schedule risk. The term is often used with a modifier (e.g., management reserve, contingency reserve, schedule reserve) to provide further detail on what types of risk are meant to be mitigated. The specific meaning of the modified terms often varies by application area. In addition, use of a reserve, and the definition of what may be included in a reserve, is also application-area-specific.
.5 Contractual agreements. Contractual agreements may be entered into for insurance, services, and other items as appropriate in order to avoid or mitigate threats. Contractual terms and conditions will have a significant effect on the degree of risk reduction.

RISK MONITORING AND CONTROL:

Risk can be monitored on a continuous basis to check if any change is made. New risks can be identified through the constant monitoring and assessing mechanism.

Inputs to Risk Response Control

.1 Risk management plan.
.2 Actual risk events. Some of the identified risk events will occur, others will not. The ones that do are actual risk events or sources of risk, and the project management team must recognize that one has occurred so that the response developed can be implemented.
.3 Additional risk identification. As project performance is measured and reported, potential risk events or sources of risk not previously identified may surface.
Tools and Techniques for Risk Response Control
.1 Workarounds. Workarounds are unplanned responses to negative risk events. Workarounds are unplanned only in the sense that the response was not defined in advance of the risk event occurring.
.2 Additional risk response development. If the risk event was not anticipated, or the effect is greater than expected, the planned response may not be adequate, and it will be necessary to repeat the response development process and perhaps the risk quantification process as well.

Outputs from Risk Response Control

.1 Corrective action. Corrective action consists primarily of performing the planned risk response (e.g., implementing contingency plans or workarounds).
.2 Updates to risk management plan. As anticipated risk events occur or fail to occur, and as actual risk event effects are evaluated, estimates of probabilities and value, as well as other aspects of the risk management plan, should be updated.

CONCLUSION

An organization will not be able to fully eliminate or eradicate risks. Every project engagement will have its own set of risks to be dealt with. A certain degree of risk will be involved when undertaking a project.

The risk management process should not be compromised at any point, if ignored can lead to detrimental effects. The entire management team of the organization should be aware of the project risk management methodologies and techniques.

Enhanced education and frequent risk assessments are the best way to minimize the damage from risks.