WTF! PM -- Effective Risk Management

So what is hell is risk?

Risk -- something, anything that might occur unexpectedly.

There are two types of risk-positive and negative. Positive risk is often called opportunity, and as our friend Murphy has said, is not as likely as negative risk. Furthermore, most people are not concerned about positive risks, so in dealing with risk management, we will focus only on negative risk- those things that can unexpectedly go wrong.

Actually, most people don't even consider positive risk, so when we refer to risk, we are referring to negative events.

Risk then has the following characteristics--(1) it may or may not happen (uncertainty or probability); (2) you can estimate this probability; (3) if it happens, it will result in some negative impact on the project (it could be cost, schedule, quality, or reputation); and (4) we may or may not be able to do something to reduce the impact (mitigation).

Risk management is therefore an informed, systematic approach to minimize the company's risk exposure. One very important concept is that "Risk management does not deal with the future decisions, but with the future consequences of present decisions". In fact, it has been said that everything we do in project management is actually aimed at managing risk.

It’s important that risk management not be so risk averse that no risks are taken, because without risk there is no innovation or entrepreneurship. It’s senior management's role to decide how much risk the company will accept in pursuit of business objectives. The project team's job is to assess all project risks and take proactive steps to deal with them within the boundaries established by management.

PROACTIVE RISK MANAGEMENT

The reactive approach to risk is to wait until something goes wrong and then decide what to do about it. Unfortunately, under such conditions, it’s often very difficult to recover from the event. The proactive risk management process is to identify, assess, quantify, and manage risk (through planning) within a project in a timely and active manner so as to maximize the chances for the project's success. Proactive risk management should be done at the very outset of the project and be reviewed and updated throughout the project. Risk assessment should be done for each project phase. The findings, risk prevention actions, and contingency planning should be presented to management at each management re view meeting. Management should focus on the following key distinct activities:

1. Risk management planning. This should be done at the beginning of the project, at the project definition and planning stages. The main objective is to define the approach that will be used to examine all potential risks that are associated with the project. This is critical. All potential risks should be properly reviewed, analyzed, quantified, and communicated to the project team, the project sponsor, and the sponsor organization based on their importance and potential impact on the organization. Risk management planning should specify responsibilities and requirements, and outline tools and techniques that will be employed.

A risk management plan is a summary of all the action plans used to identify, assess, quantify, and prioritize project risks, in order to determine contingency plans, or to identify the triggering points for actions and subsequent management review. This plan should be updated prior to every management review meeting. Any actions taken and decisions made should be documented and reviewed again at the next management review meeting.

2. Risk identification. Risk identification is the first step in the risk management process. The project team members determine what kind of risks may impact the project and define the characteristics of each of them.

The simplest way to identify risks (since we are considering only negative risks) is to ask, "What might go wrong?" Like risk management planning, risk identification should be done at the beginning of the project (i.e., project definition and planning stages).

This is important because if the team identifies a major risk at this stage, it may better to cancel the project or alter the project scope to reduce that risk.

For example, suppose the customer expects that a new product will be available within nine months, but the project employs a new technology that is still being developed and won’t be released for eight months. Like any new technology, there is a very high risk that it will be delayed. Thus it’s essential for the project team to identify this as a high risk and discuss this issue with the customer. The outcome may be that the customer is willing to accept a delay in delivering the new product, or has a contingency plan ready. The contingency plan may not be the best solution-it may be either more costly or have fewer features than the new technology-but it will be an acceptable alternative if the cutting-edge technology can't be delivered on time.

3. Risk assessment. Once potential risks have been identified, the team should assess the impact on the project should they occur. This would include such factors as commercial risks (market conditions, competitor response, etc.), technical risks (new key component development, new technologies), and project risks (budget, time, resources, and scope). These include both qualitative risk analysis and quantitative risk analysis. The main objective is to assess and quantify the exposure to the project and sponsor organization. This risk assessment should be repeated throughout the project at different stages (i.e., execution and closeout). Many good analytical tools are available for assessing risks, but remember, they are just tools. The project team's judgment will be critical if the assessment is to be meaningful.

There are also existing techniques for thinking through a problem or situation that don’t involve statistical methods. Often the risks identified don’t lend themselves to hard data.

Furthermore, analytical techniques can pro duce a false sense of precise measurement, even when estimates of probability and exposure are being made. These statistical methods generally re quire a large population of data to be valid. What is most important is that the team must constantly reassess the potential risks and make new judgments about them.

Following are some of the most commonly used analytical tools used for risk assessment.

Risk Assessment--Tools

Failure mode and effect analysis (FMEA)--This is a quantitative method in which design engineers identify the possible modes of failure for various components and production processes (which we also call process FMEA). Based on past data from similar components and processes, the team will then identify the probability and severity of the failure mode and calculate a risk priority number (RPN). Tables are used to do this, but as a simple example, say that a low probability of occurrence gets a value of 1, a moderate probability of occurrence a value of 5, and a high probability a 9. For severity, if the impact will be negligible, you assign an index of 1; for moderate impact a value of 5; and for severe impact, a value of 9. In addition, you ask whether the failure can be detected easily. If not, an index of 9 may be used, if the answer is mod eratea5is assigned, and if it’s easy to detect, you use a value of 1.

So assume that you have two possible failure modes.

Notice in the following table that the RPN is the same for each possible failure, but in one case the severity is 9 and in the other the severity is 1. Clearly, the failure mode with the highest severity would be a "show stopper," while the other would not.

Comparing Two Different Failure Modes

Using the data generated in this analysis, engineers then decide what to do about the various failure modes.

This technique can be used to analyze any kind of risk, including non-engineering risk. In such a case, you may want to drop detection, and use just probability and severity as your "measures." This yields what might be called simply a risk index (RI). Naturally the numbers have no absolute or exact meaning. They are subjective in nature. Nevertheless, they give you a tool by which to make important decisions about how various risks should be handled. In general, when a failure mode has a high severity, it’s best to try to avoid the outcome entirely.

Simulations--This is also a quantitative method that involves manipulating a set of variables through all likely combinations to develop a most likely result. The most common application in project management is to test the project schedule duration and its dependencies, although it can be used on cost estimates as well. The most frequently used simulation method, the Monte Carlo technique, varies task duration over some predetermined range of values, and calculates the critical path for each random combination. These calculations may be made a thousand times to generate a distribution of critical-path durations. This allows assessment of the probability that the project will be completed by a certain time. The validity, of course, is only as good as one's ability to model likely variations. A software program called @RISK works with Microsoft Project to do such simulations.

This technique can also be used to simulate component usage for different application conditions such as temperature, vibration, component tolerances, or other factors, which allows designers to identify the boundary conditions of a component design. To ensure a valid result, Monte Carlo and other simulation methods require the use of sophisticated computer software and user-defined conditions. Putting aside the computer resources availability and cost issues, the most difficult part is for the users to specify all the possible test conditions, schedules, and their dependencies. Thus simulation methods are generally used only in very complicated or important projects.

Early tests (chicken tests)--This quantitative method requires the team to conduct special tests to evaluate some of the key components or subprojects before proceeding to the next step.

This is a reality test of extreme conditions. The chicken test is named after the approach by jet engine designers in which bodies of dead chickens are hurled at the intake of a jet engine to ensure that it will survive a hit from a bird during flight.

Like the chicken test for the jet engine, the project team must evaluate certain project risks as early as possible to determine if their impact on the project might be catastrophic.

Risk implication matrix (RIM)--Another quantitative method, very similar to FMEA, that requires the team to quantify risks using certain values.

Risk description--Outlines the risk that is being evaluated.

Severity--Describes the impact on the project or company should the risk occur. For example, if the problem is a safety issue, it will be rated as 5 (highest).

Probability--The chance that the risk will happen. The highest score is unknown= 5.

Exposure--The cost to fix the problem or the loss that will result to the company.

Risk Index--The product of severity, probability, and expo sure. This risk index can be used as a reference for prioritizing the project risks.

Contingency plan--The alternative action that will be followed to avoid or to prevent the risk, or, if this is not possible, the mitigation steps to be taken if the risk actually occurs.

Triggering point--This is the date and time that the project team must act to implement the contingency plan.

The risk implication matrix is useful for prioritizing risks and communicating them to management for support and endorsement.

Delphi technique--This qualitative method requires several experts in specific fields to state what they see as the top 5 to 10 project scope requirements. Based on these top requirements, each expert lists the major risks and indicates their impacts on the project. The organizer of this analysis then consolidates all the experts' answers into a complete list of potential risks. This method depends on the individual ex pert's personal experiences and judgments, and sometimes there may be conflicting views that make the assessment very difficult. These differences, however, form the basis for discussing the issues and arriving at an approach that the experts can support.

Strengths-weaknesses-opportunities-threats (SWOT)--This qualitative method provides an organized way of assessing the ability of the project team to execute the job successfully.

To conduct a SWOT analysis, the team answers the following questions:

1. What strengths do we have, and how can we take advantage of them?

2. What weaknesses do we have, and how can we minimize the impact they will have on the project?

3. What opportunities are there, and how can we capitalize on them?

4. What threats to the project exist? What can we do to eliminate or minimize them? ( ) Using the SWOT analysis, the team can develop an action plan to address the weaknesses and threats and formulate ways to take advantage of strengths and opportunities.

Force-field analysis--This is also a qualitative method, in which the project team concentrates on the potential actions of people. It essentially addresses the political environment for the project. Two questions are asked. The first is, What social or political forces will help us succeed? The second is, What social or political forces may cause us difficulty? Once these are identified, the idea is to estimate the strength of each force, and then compare the positive forces with the negatives. If the sum of the positive forces does not exceed the strength of the negatives, your project is headed for failure. This is a difficult exercise to quantify and therefore is best done by attempting to find ways to accommodate or neutralize the resistance. Other areas to concentrate on when performing a force-field analysis could include feelings or perceptions of other nonrelated groups that could have a negative impact on the project.

Risk Response Control Plan

Once risks have been identified and quantified, it’s time to develop a plan on how to handle the risks that have been selected for action (there is no need to take action for risks that are unlikely to have any impact on the project). Based on the risk assessments, the team should prioritize them according to their severity, probability, and exposure and should recommend actions to handle these risks. These actions may include:

Avoidance-- You can avoid the risk. This often means finding the root cause of the risk and eliminating it. For example, suppose there is a risk of hostile community relationships due to an industrial installation near a neighborhood. This actually happened in a mill town. The company avoided the problem by offering to purchase the residents' houses for twice the appraised value. Those homeowners who had objected eventually accepted the offer and moved.

Transference--It may be possible to transfer the consequence of a risk to another organization. Transference is widely used, especially for large projects that cost millions of dollars.

There are two ways in which this can be done. One is to con tract the work to another group. The second is to purchase insurance to cover the risk. Either way, the risk exposure has been transferred to someone else. In the case of insurance, the downside is that the organization is required to pay a risk premium to the insurance company. In the case of contracting out the work, you lose direct control over it.

Mitigation-- You can also reduce the risk by reducing its probability and/or the impact on the project. For example, the new product is more likely to be completed on time if the scope of the project is reduced; more frequent tests are conducted to ensure problems are detected early; or a more stable and proven production process is implemented. Other examples are the seat belts and airbags in your car. Their objective is to reduce the chances of the risk occurring or its impact. An expert has suggested that seat belts and airbags actually in crease the probability of an accident because people have a false sense of security should they have an accident. He has (not entirely jokingly) suggested that a better approach may be to place spikes across the dashboard so that drivers are sure they will be injured should they hit something. Doing so would cause them to be more careful.

Acceptance--It’s a sometimes-viable strategy to simply accept a risk if it occurs. This approach should be coupled with a "what-if" scenario and a triggering action if the risk occurs.

For example, in the digital phone market, since the time-to-market is the most critical factor, the manufacturer may be willing to offer "patches" or quick fixes online for minor firmware bugs or "un-user-friendly" features found in the product, rather than delay the new product launch.

Risk Handling / Tracking

The last step in proactive risk management is to continue to assess the identified risks, track the status (or changes), and update the response actions. It’s also important to continue to identify new risks in the project. No project is static-every project will change over time. This is a continuous process that will only be completed when the project is completed or terminated.

RISK MANAGEMENT REVIEW

If you don’t actively attack and prevent risks in advance, they will catch up with you one day. Management should therefore enforce proper risk management in a project. While the project team should handle the detailed actions, such as risk management planning, risk identification and assessment, and risk response planning (as discussed above), the team must communicate these findings and actions to management for endorsement. This is because these decisions will have great implications not only for the project alone, but also for the organization, sponsor(s), and stakeholders. Therefore, management must fully understand the implications of these project risk decisions for the organization as a whole.

All risks must be clearly identified and quantified, and response actions provided. A proper format is therefore necessary for consistency and easy management review. The risk implication matrix (RIM) is a good tool for the project team to use to monitor and track the risk action plan. In preparing for the management review, the team should summarize the risks in a simple and easy-to-understand format for management to endorse. Many companies have applied a tool called the maturity grid for management review and making decisions. The maturity grid is used to judge whether the risks and their action plans are acceptable before the team continues with the project. As we have seen in Section 1, the biggest investment for a new product development project is made at the time when the new product is ready for production. To minimize cash flow and cost problems, it’s better to terminate a doomed project as early as possible. Senior man agers make this decision, so they need solid information on risks as early in the project as possible. The maturity grid is also used to communicate project readiness.

RISK ASSESSMENT DURING PROJECT CONCEPT PHASE

At the project concept phase, management should review project risks and decide if the project should be implemented.

So that management can make this determination, the project team should assess project feasibility in all areas- including market risk, project scope, and timing risk, as well as re source and technology risks. The first risk management meeting should include participants and representatives from marketing and sales, product quality, manufacturing, development, engineering, and the core project team members.

The team should identify potential risks in their respective areas and, together as a team, assess the risks and produce a response plan. The risks should be prioritized, and risk response actions defined, in the risk implication matrix. The team should then translate the risks into the project maturity grid using the following criteria.

Project Risk Severity

Market and customer risk (M) (market stop)--The project is not feasible to implement due to a lack of market or no major customers. This is a showstopper for the project. The team is required to prepare a response action plan and a contingency plan.

Project timing risk (T) (time stop)--The project cannot be completed within the time frame specified. This is also a show stopper for the project, and the team is required to prepare a response action plan and contingency plan.

Project resources risk (R) (resources stop)--The project team does not have all the necessary resources to implement this project. This includes human resources (project team members) and funding. This is a showstopper for the project, and management is required to allocate the necessary resources or place the project in jeopardy. The project team is required to prepare a proposal to manage the situation.

Project scope risk (S) (scope stop)--The project scope, product functions, and features are not feasible to execute be cause new technology is not yet ready or staff lacks the know-how to operate it. This is another showstopper. The team is required to prepare a response action plan and contingency plan.

Acceptable risk (D) (accepted risk)--The project team has identified the potential risks but found they are not critical or are acceptable. These risks don’t affect project implementation but do require continued monitoring and assessing to see if their attributes change during project implementation.

Evolution Factors Level 5--Risks are identified but not yet evaluated.

Level 4--Risks are identified and assessed but there is no response and action plan to address the risk. Contingency plan is not available.

Level 3--Risks are identified and assessed, a response and an action plan are prepared, and a contingency plan is available.

However, the effectiveness of these plans has not been assessed or agreed upon within the project team and among the project stakeholders.

Level 2--The response action plan and contingency plan have been reviewed and accepted. This plan is not yet included in the overall project plan for execution.

Level 1--The risk response action plan is part of the overall project plan for monitoring and tracking.

--Project Maturity Grid -- For Project at Conceptual, Definition, and Planning Phase--

Based on the above classification and the documented risks in the RIM, the team can now summarize the risks into the project maturity grid. This will provide management with a clear idea of the risks associated in this project. For example, if there is a risk of delaying the project due to unavailability of new technology, but the team has not assessed how long this new technology may be delayed, or has failed to assess its impact on the project, then this would be a T-5 Risk scenario. "1" (as indicated, 1 risk) will be placed in the T-5 square. If you have another risk related to another problem that may cause another de lay, then the number will be increased accordingly. The shaded zone represents major risks for which management attention is required.

RISK ASSESSMENT DURING THE PROJECT-DEFINITION PHASE

At the project definition phase, management is to review with the project team the final definition, scope, and specifications for the project. This is a critical stage, as it will finalize project requirements before the team can proceed with planning. This is also the last opportunity for the team to agree with the project sponsor and project beneficiaries on project deliverables. The project team must state clearly the deliverables of the project in a project charter that summarizes all project details, in agreement with the project sponsor. The risk assessment should also cover the unfinished items from the previous risk assessment at the project concept phase.

However, risk assessment at this stage should focus primarily on risks related to project definition.

Project Risk Severity

The same factors are examined in this phase that were examined at concept phase-market feasibility, schedule, re sources, scope, and so on.

Evolutionary Factors

The evolution factors are also the same as those examined in the concept phase.

Once again, these factors are entered into the risk implication matrix. Management will decide whether to proceed with the project, cancel it, or modify requirements so it can continue.

RISK ASSESSMENT DURING THE PROJECT-PLANNING PHASE

At the project planning phase, management is to review project risk and decide if the project plan covers the whole project, including adequate risk response and action.

Management should also determine if there are any changes in market conditions that may affect the project. The same procedure is applied to this phase that was used in previous phases to examine project risk severity, evolution factors, and the risk implication matrix, again to determine the disposition of the project. This procedure is often referred to as a stage-gate process, which enables management to decide whether a project should continue or be terminated at each major step.

RISK ASSESSMENT DURING THE PROJECT IMPLEMENTATION PHASE

For new product development projects, the focus of risk assessment at this phase will be on the development of the product and customer acceptance. In general, additional risks are often found during the design verification test (DVT) and design maturity test (DMT). The team should use the RIM to document, monitor, and track all these risks, as was done at previous phases. The product maturity grid is the most effective tool to report risks to management.

Following are a few guidelines specific to this phase that should be considered.

Product Risk Severity

--Product Maturity Grid-For New Product Development Project at Implementation Phase--

Safety or environmental risk (S)--During the DVT and DMT, a product found to have safety risk or environmental risk must be corrected immediately. This is a showstopper for the project. The team is required to prepare a response action plan and a contingency plan.

Not sellable or not producible (A)--Based on the DVT and DMT tests, there are major defects that cause this product to be unsaleable or unproducible. This is a showstopper for the project. The team is required to prepare a response action plan and a contingency plan.

Not acceptable by major customers or produce with major difficulties (B)--The problem detected won’t be accepted by major customers and/or production will have difficulties producing the product. This is a showstopper. The team is required to prepare a response action plan and contingency plan.

Can be sold or produced with minor difficulties (C)--The problem detected will be accepted by most customers but won’t be improved at the mass production stage; or the problem may cause minor production problems. This is a not show stopper. The team is required to prepare a response action plan to resolve this problem.

Risks are identified and accepted (D)--The project team has identified potential risks but found they are noncritical or are acceptable. These risks don’t affect the implementation of the project but require continued monitoring and assessment to determine if their attributes change during project implementation.

Evolutionary Factors

Level 5--The root cause of the problem is unknown. This is rated as the highest risk.

Level 4--Corrective action is not yet finalized. This is rated as second highest risk. The team must come up with corrective action as soon as possible.

Level 3--The corrective action has been determined but not yet verified or proven.

Level 2--The corrective action is verified to be effective but is not yet implemented.

Level 1--The corrective action is both implemented and effective.

The project and product maturity grids are very useful tools for management. They provide a clear, concise over view of project risks and response and action plans at different project phases. Management uses them to understand individual project risk issues and their impacts on the organization before reaching final project decisions.

Many companies have also adopted the traffic light system to highlight critical problems. Any problem that falls into the "red zone" (up to B-3) is considered a "red alert" and re quires special management attention.

.