What is Risk?

Primary Components

Tolerance of Risk

Risk Management

Categories of Risk

Risk Planning

Risk Identification

Risk Assessment (identification and analysis)

Risk Handling

In the early days of project management on many commercial programs, the majority of project

decisions heavily favored cost and schedule. This favoritism occurred because we knew more about cost

and scheduling than we did about technical risks. Technology forecasting was very rarely performed

other than by extrapolating past technical knowledge into the present.

Today, the state of the art of technology forecasting is being pushed to the limits. For projects with time

duration of less than one year, we normally assume that the environment is known and stable,

particularly the technological environment. For projects over a year or so in length, technology

forecasting must be considered. Computer technology doubles in performance about every two years.

Engineering technology is said to double every three or so years. How can a project manager accurately

define and plan the scope of a three- or four-year project without expecting engineering changes

resulting from technology improvements?

A Midwest manufacturing company embarked on an eight-year project to design the manufacturing

factory of the future. The plant is scheduled to go into the construction phase in the year 2000. How do

we design the factory of the future without forecasting the technology? What computer technology will

exist? What types of materials will exist and what types of components will our customers require?

What production rate will we need and will technology exist to support this production level?

Economists and financial institutions forecast interest rates. The forecasts appear in public newspapers

and journals. Yet, every company involved in high tech does some form of technology forecasting, but

appears very reluctant to publish the data. Technology forecasting is regarded as company proprietary

information and may be part of the company's strategic planning process.

We read in the newspaper about cost overruns and schedule slips on a wide variety of large-scale

development projects. Several issues within the control of the buyer, seller, or major stakeholders can

lead to cost growth and schedule slippage on development projects. These causes include, but are not

limited to:

• Starting a project with a budget and/or schedule that is inadequate for the desired level of

performance or scope (e.g., integration complexity).

• Having an overall development process (or key parts of that process) that favors performance

(or scope) over cost and schedule.

• Establishing a design that is near the feasible limit of achievable performance or integration

complexity at a given point in time.

• Making major project design decisions before the relationships between cost, performance,

schedule, and risk are understood.

These four causes will contribute to uncertainty in forecasting technology and the associated design

needed to meet performance requirements. And the inability to perfectly forecast technology and the

associated design will contribute to a project's technical risk, and can also lead to cost and schedule risk.

Today, the competition for technical achievement has become fierce. Companies have gone through

life-cycle phases of centralizing all activities, especially management functions, but are decentralizing

technical expertise. By the mid 1980s, many companies recognized the need to integrate technical risks

with cost and schedule risks, and other activities (e.g., quality). Risk management processes were

developed and implemented where risk information was made available to key decision-makers.

The risk management process, however, should be designed to do more than just identify the risk.

The process must also include: a formal planning activity, analysis to quantify the likelihood and predict

the impact on the project, a handling strategy for selected risks, and the ability to monitor the progress

in reducing these selected risks to the desired level.

A project, by definition, is something that we have not done previously and will not do again in the

future. Because of this uniqueness, we have developed a ''live with it" attitude on risk and attribute it as

part of doing business. If risk management is set up as a continuous, disciplined process of planning,

assessment (identification and analysis), handling, and monitoring, then the system will easily

supplement other systems as organization, planning and budgeting, and cost control. Surprises that

become problems will be diminished because emphasis will now be on proactive rather than reactive

management.

Risk management can be justified on almost all projects. The level of implementation can vary from

project to project, depending on such factors as size, type of project, who the customer is, relationship to

the corporate strategic plan, and corporate culture. Risk management is particularly important when the

overall stakes are high and a great deal of uncertainty exists. In the past, we treated risk as a "let's live

with it." Today, risk management is a key part of overall project management. It forces us to focus on

the future where uncertainty exists and develop suitable plans of action to prevent potential issues from

adversely impacting the project.

Risk is a measure of the probability and consequence of not achieving a defined project goal. Most

people agree that risk involves the notion of uncertainty. Can the specified aircraft range be achieved?

Can the computer be produced within budgeted cost? Can the new product launch date be met? A

probability measure can be used for such questions; for example, the probability of not meeting the new

product launch date is 0.15. However, when risk is considered, the consequences or damage associated

with occurrence must also be considered.

Goal A, with a probability of occurrence of only 0.05, may present a much more serious (risky) situation

than goal B, with a probability of occurrence of 0.20, if the consequences of not meeting goal A are, in

this case, more than four times more severe than failure to meet goal B. Risk is not always easy to

assess, since the probability of occurrence and the consequence of occurrence are usually not directly

measurable parameters and must be estimated by statistical or other procedures.

Risk has two primary components for a given event:

• A probability of occurrence of that event

• Impact of the event occurring (amount at stake)

Figure 44.1: Overall risk is a function of its components.

Figure 44.1 shows the components of risk.

Conceptually, risk for each event can be defined as a function of likelihood and impact; that is,

In general, as either the likelihood or impact increases, so does the risk. Both the likelihood and impact

must be considered in risk management.

Risk constitutes a lack of knowledge of future events. Typically, future events (or outcomes) that are

favorable are called opportunities, whereas unfavorable events are called risks.

Another element of risk is the cause of risk. Something, or the lack of something, can induce a risky

situation. We denote this source of danger as the hazard. Certain hazards can be overcome to a great

extent by knowing them and taking action to overcome them. For example, a large hole in a road is a

much greater danger to a driver who is unaware of it than to one who travels the road frequently and

knows enough to slow down and go around the hole. This leads to the second representation of risk:

Risk increases with hazard but decreases with safeguard. The implication of this equation is that good

project management should be structured to identify hazards and to allow safeguards to be developed to

overcome them. If enough safeguards are available, then the risk can be reduced to an acceptable level.

44.3 Tolerance of Risk

There is no single answer on how to manage risk. The project manager must rely upon sound

judgment and the use of the appropriate tools in dealing with risk. The ultimate decision on how to deal

with risk is based in part upon the project manager's tolerance for risk.

The three commonly used classifications of tolerance for risk appear in Figure 44.2. They include the

risk averter or avoider, the neutral risk taker, and the risk seeker or lover. The Y axis in Figure 44.2

represents "utility," which can be defined as the amount of satisfaction or pleasure that the individual

receives from a payoff. (This is also called the project manager's tolerance for risk.) The X axis in this

case is the amount of money at stake.

With the risk averter, utility rises at a decreasing rate. In other words, when more money is at stake, the

project manager's satisfaction or tolerance diminishes. With the risk lover, the project manager's

satisfaction increases when more money is at stake (i.e., an increasing slope to the curve). A risk averter

prefers a more certain outcome and will demand a premium to accept risk.

A risk lover prefers the more uncertain outcome and may be willing to pay a penalty to take a risk.

Risk management is the act or practice of dealing with risk. It includes planning for risk, assessing

(identifying and analyzing) risk issues, developing risk handling options, and monitoring risks to

determine how risks have changed.

Risk management is not a separate project office activity assigned to a risk management department, but

rather is one aspect of sound project management. Risk management should be closely coupled with key

project processes, including but not limited to: overall project management, systems engineering, cost,

scope, quality, and schedule.

manager is proactive, he might develop a Risk Handling Plan right now. If the project manager

The Project Management Institute categorizes risks as follows:

External–unpredictable: Government regulations, natural hazards, and acts of God

External–predictable: Cost of money, borrowing rates, raw material availability

The external risks are outside of the project manager's control but may affect the direction of the project.

Internal (nontechnical): Labor stoppages, cash flow problems, safety issues, health and benefit plans.

The internal risks may be within the control of the project manager and present uncertainty that may

affect the project.

Technical: Changes in technology, changes in state of the art, design issues, operations/maintenance

issues. Technical risks relate to the utilization of technology and the impact it has on the direction of the

project.

Legal: Licenses, patent rights, lawsuits, subcontractor performance, contractual failure

To identify risk issues, evaluators should break down program elements to a level where they can

perform valid assessments. The information necessary to do this varies according to the phase of the

program. During the early phases, requirement and scope documents, and acquisition plans may be the

only program-specific data available. They should be evaluated to identify issues that may have adverse

consequences.

Another method of decomposition is to create a Work Breakdown Structure (WBS) as early as possible

in a program, and use this in a structured approach to evaluate candidate risk categories against

candidate system or lower level designs. To use this approach, each element at level three of the WBS is

further broken down to the fourth or fifth level and is subjected to a risk analysis. Items at system,

segment or group, or subsystem levels, as well as management items, are assessed using attributes such

as maturity and complexity of hardware and software items or the dependency of the item on existing

systems, facilities, or contractors to evaluate their risk levels.

Another approach is to evaluate risk associated with some key processes (e.g., design and

manufacturing) that will exist on a project. Information on this approach is contained in the government

DoD directive 4245.7-M, which provides a standard structure for identifying technical risk areas in the

transition from development to production. The structure is geared toward programs that are mid-to-late

in the development phase but, with modifications, could be used for other projects. The directive

identifies a template for each major technical activity. Each template identifies potential areas of risk.

Overlaying each template on a project allows identification of mismatched areas, which are then

identified as "at risk." Having used all applicable templates, the program manager will have created a

"watch list" of production transition risk areas and can prioritize control actions— many of which will

be the responsibility of systems engineering. DoD Directive 4245.7-M describes technical methods for

reducing the risk in each identified area.

High-risk areas may reflect missing capabilities in the project manager's organization or in supporting

organizations. They may also reflect technical difficulties in the design or development process. In

either case, "management" of risk involves using project management assets to reduce the identified

risks.

The value in each of these approaches to risk identification lies in the methodical nature of the approach,

which forces disciplined, consistent treatment of risk. However, using any method in a "cookbook"

manner may cause unique risk aspects of the project to be overlooked. Before acting on the outcome of

any assessment, the project manager must review the strengths and weaknesses of the approach and

identify other factors that may introduce technical, schedule, cost, program, or other risks.

Decision-making falls into three categories: certainty, risk, and uncertainty. Decision-making under

certainty is the easiest case to work with. With certainty, we assume that all of the necessary

information is available to assist us in making the right decision, and we can predict the outcome with a

high level of confidence.

Decision-making under certainty implies that we know with 100 percent accuracy what the states of

nature will be and what the expected payoffs will be for each state of nature. Mathematically, this can be

shown with payoff tables.

To construct a payoff matrix, we must identify (or select) the states of nature over which we have no

control. We then select our own action to be taken for each of the states of nature. Our actions are called

strategies. The elements in the payoff table are the outcomes for each strategy.

A payoff matrix based on decision-making under certainty has two controlling features.

• Regardless of which state of nature exists, there will be one dominant strategy that will produce

larger gains or smaller losses than any other strategy for all the states of nature.

• There are no probabilities assigned to each state of nature.

In most cases, there usually does not exist one dominant strategy for all states of nature. In a realistic

situation, higher profits are usually accompanied by higher risks and therefore higher probable losses.

When there does not exist a dominant strategy, a probability must be assigned to the occurrence of each

state of nature.

Risk can be viewed as outcomes (i.e., states of nature) that can be described within established

confidence limits (i.e., probability distributions). These probability distributions are obtained from welldefined

experimental distributions.

The difference between risk and uncertainty is that under risk there are assigned probabilities, and under

uncertainty meaningful assignments of probabilities are not possible. As with decision making under

risk, uncertainty also implies that there may exist no single dominant strategy. The decision-maker,

however, does have at his disposal four basic criteria from which to make a management decision. The

decision about which criterion to use will depend on the type of project as well as the project manager's

tolerance to risk.

It is important that a risk management strategy is established early in a project and that risk is

continually addressed throughout the project life cycle. Risk management includes several related

actions involving risk: planning, assessment (identification and analysis), handling, and monitoring:

• Risk planning: This is the process of developing and documenting an organized, comprehensive, and

interactive strategy and methods for identifying and tracking risk issues, developing risk handling plans,

performing continuous risk assessments to determine how risks have changed, and assigning adequate

resources.

• Risk assessment: This process involves identifying and analyzing program areas and critical technical

process risks to increase the likelihood of meeting cost, performance, and schedule objectives.

•Risk identification is the process of examining the program areas and each critical technical process to

identify and document the associated risk. Risk analysis is the process of examining each identified risk

issue or process to refine the description of the risk, isolate the cause, and determine the effects.

• Risk handling: This is the process that identifies, evaluates, selects, and implements options in order

to set risk at acceptable levels given program constraints and objectives. This includes the specifics on

what should be done, when it should be accomplished, who is responsible, and associated cost and

schedule. Risk handling options include assumption, avoidance, control (also known as mitigation), and

transfer. The most desirable handling option is selected, and a specific approach is then developed for

this option.

• Risk monitoring: This is the process that systematically tracks and evaluates the performance of risk

handling actions against established metrics throughout the acquisition process and provides inputs to

updating risk handling strategies, as appropriate.

Risk planning is the detailed formulation of a program of action for the management of risk. It is the

process to:

• Develop and document an organized, comprehensive, and interactive risk management strategy.

• Determine the methods to be used to execute a program's risk management strategy.

• Plan for adequate resources.

Risk planning is iterative and includes the entire risk management process, with activities to assess

(identify and analyze), handle, monitor (and document) the risk associated with a program. The result is

often the risk management plan (RMP).

Planning begins by developing and documenting a risk management strategy. Early efforts establish the

purpose and objective, assign responsibilities for specific areas, identify additional technical expertise

needed, describe the assessment process and areas to consider, define a risk rating approach, delineate

procedures for consideration of handling options, establish monitoring metrics (where possible), and

define the reporting, documentation, and communication needs.

The RMP is the roadmap that tells the project team how to get from where the program is today to

where the program manager wants it to be in the future. The key to writing a good RMP is to provide

the necessary information so the program team knows the objectives, goals, and the risk management

process. Since it is a roadmap, it may be specific in some areas, such as the assignment of

responsibilities for project personnel and definitions, and general in other areas to allow users to choose

the most efficient way to proceed. For example, a description of techniques that suggests several

methods for evaluators to use to assess risk is appropriate, since every technique has advantages and

disadvantages depending on the situation.

Risk assessment is the problem definition stage of risk management, the stage that identifies, analyzes,

and quantifies program issues in terms of probability and consequences, and possibly other

considerations (e.g., the time to impact). The results are a key input to many subsequent risk

management actions. It is often a difficult and time-consuming part of the risk management process.

There are no quick answers or shortcuts. Tools are available to assist evaluators in assessing risk, but

none are totally suitable for any program and are often highly misleading if the user does not understand

how to apply them or interpret the results. Despite its complexity, risk assessment is one of the most

important phases of the risk management process because the caliber and quality of assessments can

have a large impact on program outcomes.

The components of assessment— identification and analysis— are performed sequentially with

identification being the first step.

Risk identification begins by compiling the program's risk issues. Project issues should be examined and

identified by reducing them to a level of detail that permits an evaluator to understand the significance

of any risk and its causes (e.g., risk issues). This is a practical way of addressing the large and diverse

number of potential risks that often occur in moderate- to large-scale programs.

For example, a WBS level 4 or 5 element may be made up of several risk issues associated with a

specification or function.

Risk analysis is a technical and systematic process to examine identified risks, isolate causes, determine

the relationship to other risks, and express the impact in terms of probability and consequence of

occurrence.

The second step in risk management is to identify all potential risk issues. This may include a survey of

the program, customer, and users for concerns and problems.

Some degree of risk always exists in project, technical, test, logistics, production, and engineering areas.

Project risks include cost, funding, schedule, contract relationships, and political risks. (Cost and

schedule risks are often so fundamental to a project that they may be treated as stand-alone risk

categories.) Technical risks, such as related to engineering and technology, may involve the risk of

meeting a performance requirement, but may also involve risks in the feasibility of a design concept or

the risks associated with using state-of-the-art equipment or software. Production risk includes concerns

over packaging, manufacturing, lead times, and material availability. Support risks include

maintainability, operability, and trainability concerns. The understanding of risks in these and other

areas evolves over time.

Consequently, risk identification must continue through all project phases.

The methods for identifying risk are numerous. Common practice is to classify project risk according to

its source. Most sources are either objective or subjective.

Objective sources: Recorded experience from past projects and the current project as it proceeds

• Lessons learned files

• Program documentation evaluations

• Current performance data

Subjective sources: Experiences based upon knowledgeable experts

• Interviews and other data from subject matter experts

Risks can also be identified according to life-cycle phases, as shown in Figure 44.3. In the early lifecycle

phases, the total project risk is high because of lack of information. In the later life-cycle phases,

the financial risk is the greatest.

Figure 44.3: Life-cycle risk analysis

Any source of information that allows recognition of a potential problem can be used for risk

identification. These include:

• Systems engineering documentation
• Life-cycle cost analysis
• Plan/WBS decomposition
• Schedule analysis
• Baseline cost estimates
• Requirements documents
• Lessons learned files
• Assumption analysis
• Trade studies/analyses
• Technical performance measurement (TPM) planning/analysis
• Models (influence diagrams)
• Decision drivers
• Brainstorming
• Expert judgment

Expert judgment techniques are applicable not only for risk identification, but also for forecasting and

decision-making. Two expert judgment techniques are the Delphi method and the nominal group

technique. The Delphi method has the following general steps:

Step 1: A panel of experts is selected from both inside and outside the organization. The experts do

not interact on a face-to-face basis and may not even know who else sits on the panel.

Step 2: Each expert is asked to make an anonymous prediction on a particular subject.

Step 3: Each expert receives a composite feedback of the entire panel's answers and is asked to

make new predictions based upon the feedback. The process is then repeated as necessary.

Closely related to the Delphi method is the nominal group technique, which allows for face-to-face

contact and direct communication. The steps in the nominal group technique are as follows:

Step 1: A panel is convened and asked to generate ideas in writing.

Step 2: The ideas are listed on a board or a flip chart. Each idea is discussed among the panelists.

Step 3: Each panelist prioritizes the ideas, which are then ranked mathematically. Steps 2 and 3 may

be repeated as necessary.

Expert judgment techniques have the potential for bias in risk identification and analysis. Factors

affecting the bias include:

• Overconfidence in one's ability
• Insensitivity to the problem or risk
• Proximity to project
• Motivation
• Recent event recall
• Availability of time
• Relationship with other experts
• There exist numerous ways to classify risks. In a simple business context, risk can be defined as:
• Business risk
• Insurable risk

Business risks provide us with opportunities of profit and loss. Examples of business risk would be

competitor activities, bad weather, inflation, recession, customer response, and availability of resources.

Insurable risks provide us with only a chance for a loss. Insurable risks include such elements as:

Direct property damage: This includes insurance for assets such as fire insurance, collision insurance,

and insurance for project materials, equipment, and properties.

Indirect consequential loss: This includes protection for contractors for indirect losses due to third

party actions, such as equipment replacement and debris removal.

Legal liability: This is protection for legal liability resulting from poor product design, design errors,

product liability, and project performance failure. This does not include protection from loss of

goodwill.

Personnel: This provides protection resulting from employee bodily injury (worker's compensation),

loss of key employees, replacement cost of key employees, and several other types of business losses

due to employee actions.

On construction projects, the owner/customer usually provides ''wrap-up" or "bundle" insurance, which

bundles the owner, contractor, and subcontractors into one insurable package. The contractor may be

given the responsibility to provide the bundled package, but it is still paid for by the owner/customer.

Risk handling includes specific methods and techniques to deal with known risks, identifies who is

responsible for the risk issue, and provides an estimate of the cost and schedule associated with reducing

the risk, if any. It involves planning and execution with the objective of reducing risks to an acceptable

level. The evaluators who assess risk should begin the process by identifying risks and developing

handling options and approaches to propose to the program manager, who selects the appropriate one(s)

for implementation. There are several factors that can influence our response to a risk, including but not

limited to:

• Amount and quality of information on the actual hazards that caused the risk (descriptive

uncertainty)

• Amount and quality of information on the magnitude of the damage (measurement uncertainty)
• Amount and quality of information on probability of occurrence
• Personal benefit to project manager for accepting the risk (voluntary risk)
• Risk forced upon project manager (involuntary risk)
• Confusion and avoidability of the risk
• The existence of cost-effective alternatives (equitable risks)
• The existence of high-cost alternatives or possibly lack of options (inequitable risks)
• Length of exposure to the risk

Risk handling must be compatible with the RMP and any additional guidance the program manager

provides. A critical part of risk handling involves refining and selecting the most appropriate handling

option(s) and specific approach (es) for selected risk issues (often those with medium or higher risk

levels).

Personnel who evaluate candidate risk handling options may use the following criteria as starting points

for evaluation:

• Can the option be feasibly implemented and still meet the user's needs?

• What is the expected effectiveness of the handling option in reducing program risk to an

acceptable level?

• Is the option affordable in terms of dollars and other resources (e.g., use of critical materials,

and test facilities)?

• Is time available to develop and implement the option, and what effect does that have on the

overall program schedule?

• What effect does the option have on the system's technical performance?

Risk handling options include: risk assumption, risk avoidance, risk control, and risk transfer.

Although the control option (often called mitigation) is commonly used in many high technology

programs, it should not automatically be chosen. All four options should be evaluated, and the best one

chosen for each risk issue.

The options for handling risk fall into the following categories:

Risk assumption (i.e., retention): The project manager says, ''I know the risk exists and am aware of the

possible consequences. I am willing to wait and see what happens. I accept the risk and its impact

should it occur."

Risk avoidance: The project manager says, "I will not accept this option because of the potentially

unfavorable results."

Risk control (i.e., prevention or mitigation): The project manager says, "I will take the necessary

measures required to control this risk by continuously reevaluating it and developing contingency plans

or fall-back positions. I will do what is expected."

Risk transfer: The project manager says, "I will share this risk with others through insurance or a

warranty, or transfer the entire risk to them. Perhaps I can convert the risk into an opportunity."