Managing Risk: A Four-Step Process

Risk Management

Projects can fail for a number of reasons and the risks are always high. While a project manager cannot eliminate risk, she can prevent or mitigate its impacts by using risk management.

Managing Risk: A Four-Step Process

Risk management is the process of identifying, analyzing, controlling, and reporting risk. Risk identification is the identification of major elements of a project and their associated risks. To do this, Perry will rely on his and others knowledge and expertise. He will meet with core team members, the customer, and senior management to solicit input. He will review documentation, including the statement of work, work breakdown structure, and requirements documents. This information prepares him for the next step. Risk analysis is the classification of those elements to different levels of risk. Perry will compare the should be controls with the ones that do exist and will identify any discrepancies. He will also determine the probability or likelihood each risk will materialize and whether a control is necessary. Risk control is the determination of controls that can mitigate the risks. It involves deciding under what circumstances to take action to prevent or mitigate the impact of a risk. Perry essentially will do contingency planning, which involves anticipating responses to negative circumstances. Risk reporting is the act of informing team members and senior management of those risks.

Perry knows that by managing risk, he can identify priorities, thereby focusing his energies and resources as well as developing a meaningful project plan. The analysis of risk indicates the strengths and the weaknesses of the project, so that he can maximize his assets and minimize his losses. It helps him to identify and put into place the most important controls, rather try to control everything.

To perform risk management, Perry needs information, time, expertise, and perspective. The information is necessary to understand the major processes and components, the accompanying threats, and the controls that should be in place. It will take time to collect the information and assemble it in some meaningful form. He will use his expertise in project management to apply risk management while maintaining a broad perspective to avoid focusing on just one area (e.g., technical issues at the expense of business ones).

Exposure

Several factors can expose projects to higher than normal risk.

Team size. The larger the team, the higher the probability of a problem arising. For example, communications can be more difficult as the number of participants increases. The number of interactions among people increases and thus they require greater coordination.

History. Newer projects are riskier because the processes have not been refined. The more times a project of a similar nature has been done, the greater the likelihood of success.

Staff expertise and experience. If the staff lacks direct experience and knowledge of the subject, people will struggle to learn as they go along, robbing the project of time and possibly introducing errors.

Complexity. The more sophisticated a project, the greater the opportunity of a mistake or slipup. Untested technologies, such as ones dealing with information systems or biotechnologies, are risk laden.

Management stability. The more senior management plays musical chairs, the greater the risks of a problem arising. With every new management comes the possibility of changed priorities and directions. Management stability implies unity of direction, which in turn means reaching goals. Management irritability can lead to unrealistic scheduling and inefficient use of resources.

Time compression. If a schedule is highly compressed, then the risks are magnified. Having more time means greater flexibility and the opportunity to prevent or mitigate the impact of errors.

Resource availability. The more resources that are available, the greater the ability to respond to problems as they arise. For example, more money brings greater ability to secure equipment or people when needed. Plentiful resources, of course, do not guarantee protection from risk; however they do provide the means to respond to it.

Categories of risk

Risks can be viewed as business, technical, or operational. An example of a business risk is misuse of project funds. A technical risk is the inability to build the product that will satisfy requirements. An operational risk is the inability of the customer to work with core team members.

Risks are either acceptable or unacceptable. An acceptable risk is one that negatively affects a task on the noncritical path. An unacceptable risk is one that negatively affects the critical path.

Risks are either short or long term. A short-term risk has an immediate impact, such as changing the requirements for a deliverable. A long-term risk has an impact sometime in the distant future, such as releasing a product without adequate testing.

Risks are viewed as either manageable or unmanageable. A manageable risk is one you can live with, such as a minor requirement change. An unmanageable risk is impossible to accommodate, such as a huge turnover of core team members.

Finally, risks are either internal or external. An internal risk is peculiar to a project, such as the inability to get the parts of a product to work. An external risk originates from outside the scope of the project, such as when senior management arbitrarily cuts funding by 20 percent.

Categorizing risks is, of course, mainly an academic exercise. These classifications can help you determine the source, relative importance, and impact to the project.

Key Concepts in Risk Management

When performing risk management, Perry remembers the following concepts.

A component is a basic element of an overall system. A project is a system consisting of components that, in turn, can consist of subcomponents. Components can be processes, deliverables, or both. Examples of a component are a process like determining requirements or a deliverable like a requirements document.

A threat is the occurrence of an event that negatively affects a project in some manner. A threat exploits a vulnerability, or exposure. An example of a threat is when there is no customer buy-in of a schedule or requirement. Vulnerability is the inherent degree of weakness of a component, such as a schedule having no acceptance by the customer.

Probability is the odds that something, like a threat, will occur any-where from 0 to 100 percent. Probability determines the extent to which a risk will occur and the level of vulnerability.

Control is a measure in place to mitigate, prevent, or correct the impact of a threat. A control can be physical, such as a required signature, or logical, such as a peer review.

Keeping the above concepts in mind, Perry can perform risk management using two approaches: quantitative or qualitative.

The quantitative approach relies on statistical calculation to determine risk, its probability of occurrence, and its impact on a project. A common example of the quantitative approach is decision tree analysis, applying probabilities to two or more outcomes. Another example is the three-point estimating technique described in Chapter 7. Still another approach is the Monte Carlo simulation, which generates a value from a probability distribution and other factors.

The qualitative approach relies on judgments, using criteria to determine outcomes. A common qualitative approach is a precedence diagramming method, which uses ordinal numbers to determine priorities and outcomes. Another approach is heuristics, or rules of thumb, to determine outcomes.

An example of a qualitative approach is to list in descending order specific processes of a project, the risk or risks associated with each process, and the control or controls that may or should exist for each risk. See Exhibit 12-1.

Ways to Handle Risk

There are four basic ways to deal with risk.

Accept the risk, known as risk acceptance. Perry can do nothing to prevent or mitigate the impact of a risk. For example, he continues to

address the same requirements despite management having reduced the budget.

Adapt to the risk, known as risk adaptation. Perry can take measures that will mitigate the impact of a risk. For example, he reduces requirements to reflect the corresponding cutback in funding.

Avoid the risk, known as risk avoidance. Perry takes action that will keep a risk from seriously impacting his project. For example, he decides to narrow the scope of the project to avoid certain high risks.

Transfer the risk, known as risk transfer. Perry lets someone else assume the risk. For example, he contracts out or outsources certain high-risk tasks rather than let the core team handle them.

When performing the contingency planning, Perry will identify the expected event or threat, its probability of occurrence, and its impacts (e.g., economic, technical, operational), and then devise an appropriate response. He uses a simple form to capture this information, as shown in Exhibit 12-2.

Perry also reviews the schedule to identify possible risks. He considers options like changing the dependencies, durations, requirements, resource assignments, or time estimates.

Risk Reporting

Risk reporting occurs after risk identification, analysis, and control are complete. Perry has the option to develop either a written or an oral report. In either case, however, the content of the report will be basically the same.

A risk report should be clear, concise, and self-explanatory. It should contain categories of risks (e.g., business and technical); components; risks for each component, to include probability of occurrence and impact; background and scope of project; and recommendations or actions to strengthen controls or respond to risks when they become actual problems (e.g., contingency plans).

The Key: Risk Management, Not Elimination

In a dynamic environment, a project will always face risks. The key is not to try to eliminate risks but to manage them. Perry identifies and analyzes risks. He then implements controls to mitigate or eliminate their potential impact. However, he also communicates the list of risks and their accompanying controls to all people who have a need to know. By developing and distributing documentation on risks and their controls, Perry can either prevent related problems or minimize their effects when they occur.

Questions for Getting Started

Did you identify the major components and processes for your project?

Did you identify the major threats to your project? Did you identify their probability of occurrence?

Did you identify the controls that should exist for preventing or mitigating risks to each component or process?

Did you conduct research to determine what controls actually exist?

For all control weaknesses, did you determine whether contingency plans should be in place? If so, did you prepare the appropriate response?