Risk Management

Risk Management, in Gower Handbook of Project Performance for Agile, Waterfall and Everything in Between, 1st Edition, 2017.
Risk Management Principles
Risk Management is How Adults Manage Projects ‒ Tim Lister
Risk management is essential to the success of all project
work. Information about key project cost, performance, and
schedule attributes are often unknown until the project is
underway and changes are occurring during execution.
When risk is known, corrective actions can be taken to
mitigate to their outcomes. For unknown risks ‒ things that
we now know we don't know ‒ risk management can still
take place. For unknowable risks, Plan B is the first response.
Both known and unknown (but knowable) can be addressed
with a risk management process can quantify the risk and its
impact and provide plans for mitigating their affects.
Risk management is a critical skill applied to a wide variety
of projects. In an era of downsizing, consolidation, shrinking budgets, increasing technological
sophistication, and shorter development times ‒ no matter the domain, risk management
provides valuable insights. These insights help key project personnel plan for risks, alert them of
potential risk issues, analyze these issues, and develop, implement, and monitor plans to address
risks long before they surface as issues and adversely affect project cost, performance, and
schedule.
Let’s start with putting Risk Management in a project management context. There are Five
Immutable Principles of Project Success determined by Five questions that need answers:
1. What does Done look like in units of measure meaningful to the decision makers?
2. What is the plan and schedule to reach Done on plan?
3. What are the resources needed to reach Done?
4. What are the impediments to reaching Done as planned?
5. How are we going to measure progress toward Done?
It is number Four that will be addressed here. Let’s use an example to convey the principles,
processes, and practices of Risk Management. There are lots of choices, but here’s one that is
common ‒ the remodeling of a kitchen.
Here’s the situation. The current kitchen is going on fifteen years old. It was a builder’s quality
kitchen with builder appliances, a standard layout, and tract-home feel. We want to upgrade the
kitchen to with of modern appliances, have a better layout within the framing structure of the
home, and provide capabilities not found in the current design. Today appliances are available
that have much higher efficiency ratings as well as desired features. The prices for restaurant-
quality cooking appliances has come down and the style of modern kitchens is moving from
cooking centric to entertaining centric layouts, with the kitchen as the focus of the party, not the
dining area.
Managing Risk is how adults manage
projects ‒ Tim Lister
§ Hope is not a strategy
§ No point estimate of the risk impact
on cost or schedule can be correct.
§ Without integrating cost, schedule,
and technical performance you are
driving in the rear view mirror.
§ Without a model for risk
management, you are driving in the
dark with the head lights off.
§ Risk management means
communication management

Let’s apply the Five Immutable Principles to our Kitchen project:
1. What does Done Look Like? ‒ The old kitchen is gone and the new kitchen with new
everything is installed without collateral damage to any other part of the house. All done
close to planned budget and close to the planned time frame.
2. What’s our Plan and Schedule? ‒ the Master Plan is, pick out everything, decide when we
need the kitchen, and work backward to the start date. Demo the Kitchen, electrical and
plumbing, install cabinets, install appliances, do tile and flooring, start cooking
3. What resource do we need? ‒ cabinet shop, designers, plumbing, appliance designers and
installers, painters, trim carpenters, flooring installers, electricians, and all the other usual
players.
4. What are the Risks and Impediments? ‒ let’s save this for later.
5. Measuring Progress toward Done? ‒ physical objects, installed and working is the best
measure for this project. Having momma happy is the primary measure as well. If momma
ain’t happy no one can be happy is the ultimate measure of success.
Hope is not a Strategy
Hoping our kitchen project will proceed as planned, without
any disruptions, is naïve at best and poor project
management at worse.
Project Managers constantly seek ways to eliminate or
control risk, variance, and uncertainly.
This is a hopeless pursuit. Managing in the presence of risk,
variance and uncertainty is the key to success. Some projects
have few uncertainties – only the complexity of tasks and
relationships is important – but most projects are
characterized by several types of uncertainty. Although each
uncertainty type is distinct, a single project may encounter
some combination of four types:
§ Variation – comes from many small influences and yields a range of values on a particular
activity. Attempting to control these variances outside their natural boundaries is a waste
(Muda). This type of uncertainty is labeled Aleatory. Aleatory uncertainty is “naturally”
occurring. It is part of the process, the culture. It’s just “in the air.” The key here is that it is
not possible to reduce aleatory uncertainty. The only protection is to have cost, schedule, and
technical “margin” to absorb these variances.
§ Foreseen Uncertainty – are uncertainties identifiable and understood influences that the
team cannot be sure will occur. There needs to be a mitigation plan for these foreseen
uncertainties. There needs to be a mitigation plan for them. This type of uncertainty is labeled
Epistemic. Epistemic uncertainty creates a probability of the occurrence for a specific risk.
This type of uncertainty and resulting risk can be “handled” in two ways. First, the risk can be
“bought down,” or “retired,” by spending money to learn more information or doing work to
remove the uncertainty and therefore the risk. Second, Management Reserve can be
provided to protect the project when this risk comes true. Management Reserve (MR) is the
Strategy is a Plan to Successfully
Complete the Project
§ When General Custer was completely
surrounded, his chief scout asked,
“General what's our strategy?” Custer
replied, “The first thing we need to do
is make a note to ourselves – never
get in this situation again.”
§ If the project’s success factors, the
processes that deliver them, the
alternatives when they fail, and the
measurement of this success are not
defined in meaningful ways for both
the customer and managers of the
project – Hope is the only strategy left.

amount of the total budget withheld for management control purposes, rather than assigned
for the accomplishment of work. MR is held and applied through a disciplined process to any
additional work that is to be accomplished within the authorized work scope.
§ Unforeseen Uncertainty – is uncertainty that can’t be identified during project planning.
When these occur, a new plan is needed. This new plan now needs to deal with the
uncertainty and the resulting risk created by the Unforeseen Uncertainty.
§ Chaos – appears with the presence of “unknown unknowns.” The concept of UNK UNK is
overused and even abused. “We didn’t see it coming,” is a common response. In fact, we
were just too lazy to look for the risk. Our mortgage crisis, our lack of understanding of
international politics, our failure to adequately talk to the stake holders are all examples of
the misapplication of UNK UNK’s.
We need a Plan to address these uncertainties and their sources. This Plan needs to define:
§ How the products and services will be “matured” as the project progresses.
§ What are the “units of measure” for this increasing maturity.
§ At what points in the project will this maturity be assessed be assessed to confirm progress
is being made.
Hope Means A Plan Means
I hope we can get done by the weekend with the
integration test. We’ll work as hard as we can to get
done by Monday morning. If not we’ll make it up in
System Test.
If we don’t get the integration test done by Friday,
well release without features A, B and F
I hope the control bus will be fast enough for the
command loop.
If the control bus is not fast enough, we’ll run two in
parallel until the new version is complete.
I hope we’ll have enough management reserve to
complete the project on budget. We’ll watch the
budget expenditures real close and let you know if
we’ll need more money
At each 20% budget absorption level, we’ll confirm
our deliverables value (BCWP) match is investment
value (BCWS) and adjust our forecast for
management reserve on a monthly basis.
Hope must be replaced with a risk tolerant plan. In this plan larger variances can be tolerated in
the early parts of the project. But as the project proceeds the tolerance for risk must bane
reduced. At the end of the project all the risks must have been retired.

Before going further, let’s discuss some definitions and background. Project management,
naturally, is success oriented, focused on producing products and services for customers. Risk
management is focused on failure modes of the project and can be easily pushed aside by a
success culture. It is critical that all project participants, not just project managers, understand
that risk management is a process to identify and mitigate the barriers to this success. When the
success orientation is combined with risk management, opportunity management emerges.
Some starting definitions for risk management:
§ Risk – a potential problem or threat that could affect a project’s ability to meet its operational
capability and performance, technical, cost, schedule, financial, or other objectives.
§ Risk Management – the continuous, proactive process of identifying and assessing program,
risk, defining appropriate risk handling strategies and plans, and monitoring those actions to
completion.
For the Kitchen we need to remove all the Unknowns and prevent any Unknown Unknowns from
every occurring. This mean starting with a full survey of the current kitchen as shown in Figure 3 for
the Identify Risks step ‒ electrical panels, current capacity, water and drainage, structural, floor
loading, cabinet attachment requirements, assess for removing and installing new equipment.
What is the Intention of Risk Management?
So with the start of our kitchen projects what is the intention for this formal risk management?
Actively managing risks increase the probability that a project or program will have a successful
outcome.
This motherhood statement makes it clear that risk management is part of a successful project
management as a strategy. Risk management is not an event performed along the way; it is a
continuous process.
There are many books, papers, articles, and professional associations describing how to manage
risk. One phrase used by project a manager is risk buy down that is, the buying of information to
reduce risk. The purchasing of this information can be explicit: buy a report that compares three
kitchen appliances being considered as an off-the-shelf solution rather than analyze them as part
of the project. Or, spend money exploring what’s behind the kitchen walls that we are going to
tear into. Mock up with paper templates the counter tops and how they will fit in and around the
appliances.
Risk Management Needs a Hierarchy
Project risk management requires more than the intent to manage risks, it requires cultural
changes, processes and their use, tools, and the consistent application of all of these to be in
place for successful risk management.
§ A Risk Management Culture in which the success of the project is understood to be based on
delivering the planned results and managing risks that interfere with those plans.
§ Effective risk processes from simple identify, assess, plan, control, and communicate to
complex probabilistic risk assessments.

§ Risk tools from simple list to complex software system integrated across the enterprise.
§ Consistent practices are in place when risk management becomes part of the everyday
routine rather than an additional task to burden the project.
§ Sound risk management cannot save a poorly planned program with bad processes.
§ Costs of pursuing and managing risks must be weighed against the expected impacts to the
project. This the Value at Risk discussion that is part of project governance.
§ An environment must be created to encourage risk management.
Risk Management must be an integral part of planning and execution. PMBOK®
defines 6
processes for managing risk. To make risk management explicit the tasks for managing risk must
be:
§ Embedded in the schedule – flagged as risk management tasks with predecessors,
successors, durations, and priorities.
§ Assigned resources – risk manager and technical assessment staff, cost accounts, and WBS
numbers, performance targets, and exit criteria.
§ Budget – apportioned to the risk level, cost baseline, and actuals against the project baseline.
§ Tracked in the normal status review – risk manager reports risk reduction status as
percentage complete or 0%/100% complete.
§ Defined outcomes ‒ result of risk buy down, and management tasks are made visible through
accomplishment criteria or some form of qualitative assessment.
§ Assessed for compliance ‒ to specification through a risk buy down chart showing risk
reduction as the project proceeds.
This makes risk management part of the normal project planning and control processes. Once in
place, the risk management plan is no longer a separate event represented solely in a document,
but part of the project management team’s responsibility.
Let’s visit Tim Lister’s quote again. It says volumes about project management and project failure.
It also means that managing risk is managing in the presence of uncertainty. Let’s start with a
formal definition of Risk Management.
Risk management is a set of activities aimed at understanding, controlling, and, as appropriate,
accepting risk to the achievement of objectives. Risk management operates continuously in an
activity, proactively risk-informing the selection of decision alternatives and then managing the
implementation risks associated with the selected alternative. ‒
Managing in the presence of uncertainty and the resulting risk, means making estimates of the
outcomes that will appear in the future from the decisions made today, in the presence of
naturally occurring variances, and probabilistic events during the period over which the decision
is applicable. Without these estimates, there is no means of assessing a decision for its
effectiveness in keeping the project on track for success.
In one form or another, Risk Management has been a part of every human endeavor. From the
building of the Pyramid’s to flying to Mars, to large construction, to enterprise IT, to planning
your 6 year olds birthday party.

In modern times quantitative risk management is the basis of decision making for non-trivial
projects. There is lots of debate about which form of Risk Management is best suited for what
class of projects. But it is likely there is no debate that effective risk management is a Critical
Success Factor to all project work.
There are many sources of risk and just as many impacts on project performance from these risks.
This chapter is too short to enumerate then all, so here’s a quick summary of the causes of
program performance shortfalls that are considered risks and can be addressed by Risk
Management.
Figure 1 ‒ four sources of unfavorable outcomes for projects that are connected to risks. Each of these risks comes from
uncertainty. In all cases impacts from risk are unaddressed uncertainties.
Risk, Uncertainty, and Chaos
The four types of risk do not appear on a project out of thin air. Risk is created when there is
uncertainty. If there were no uncertainty, there would be no risk to the project’s cost, schedule,
and technical performance. So risk management is actually the management of the project in the
presence of uncertainty. This implies that making decisions in the presence of uncertainty is the
same as risk management. A Risk Informed Decision is a decision in the presence of uncertainty.
The hope that risk can be "programmed" out of a project schedule is a false hope. However, you
can manage uncertainties by understanding the risk types they represent and addressing each in
an appropriate manner. In part two of this risk management series, an aerospace program
manager explains. In Against the Gods: The Remarkable Story of Risk, author Peter Bernstein
states that one of the major intellectual triumphs of the modern world is the transformation of
risk from a matter of fate to an area of study. And so, risk analysis is the process of assessing risks,
while risk management uses risk analysis to devise management strategies to reduce or

ameliorate risk. Managing the uncertainty in a network of tasks that describe a schedule is the
topic of this article.
All risk is created by Uncertainty. There are two types of uncertainty ‒ Epistemic uncertainty and
Aleatory uncertainty.
Epistemic uncertainty can be reduced. Epistemic (subjective or probabilistic) uncertainties are
event based probabilities, knowledge-based, and are reducible by further gathering of
knowledge. Epistemic uncertainty pertains to the degree of knowledge about models and their
parameters.
This term comes from the Greek episteme (knowledge). Epistemic uncertainties,
§ Are Event based uncertainties, where there is a probability of something happening that
will unfavorably impact the project.
§ Are described by a probability that something will happen in the future.
§ Can state this probability of the event and do something about reducing this probability
of occurrence.
Aleatory uncertainties pertain to stochastic (non-deterministic) events, the outcome of which is
described using a probability distribution function(PDF). The term aleatory come from the Latin
ALEA. For example in a game of chance stochastic variabilities are the natural randomness of the
process and are characterized by a probability density function (PDF) for their range and
frequency. Since these variability's are natural they are therefore irreducible.
§ These are Naturally occurring Variances in the underlying processes of the program.
§ These are variances in work duration, cost, technical performance.
§ We can state the probability range of these variances within the Probability Distribution
Function.
Both Aleatory and Epistemic uncertainties create project risk.

Figure 2 ‒ Aleatory and Epistemic uncertainty creates project risk.
For our kitchen project we have both reducible and irreducible uncertainties that create risk:
§ Reducible risks ‒ include uncertainties for material cost, labor cost, physical issues
(structural, electrical), fit of appliances, plumbing routing.
§ Irreducible risks – include uncertainties for surprises when the demolishing work starts,
discovery of structural issues, delivery dates for appliances, labor availability and labor
skills.
For the reducible uncertainties, we can perform work for confirm the pricing of materials, labor
cost by asking for a not to exceed quote. The physical issues can be addresses by cutting into
walls and floors to confirm all right pieces are in the right place.
For the irreducible uncertainties, the delivery dates can be confirmed, but a time margin can be
applied to deal with lateness from normal work processes ‒ weather is a common one
Risk Buy Down Activities
Risk buy down is work, just like any other task in the plan. The role of this work is to manage the
uncertainty in the project. This uncertainty can be characterized by:
§ Uniqueness – a project is a unique undertaking. This does not bode well for the management
of technical or programmatic risk, since there is little, if any, historical data by which to
calibrate the models describing this risk.
§ Variability – there are various tradeoffs between performance, cost, schedule, quality and
risk. A model of these tradeoffs requires that the correlation between each of the elements
of the model be known in some way.
§ Ambiguity – a state that emerges from the lack of clarity and structure as well as the built-in
biases of estimating cost, schedule and risk.

Although mature organizations use tools to support project planning, quantifying the uncertainty
in these plans is not as common. The PMBOK Guide identifies risk as a key area of concern but
does not describe the management of the underlying uncertainty that results in this risk.
Transforming project risk into project uncertainty often requires that the concept of risk as an
event ignore the source of risk emerging from the probabilistic nature of the project’s technical
and programmatic activities.
The concept that uncertainty and risk can be programmed out of the schedule is a false hope.
Intrinsic variation pervades all natural systems. Observe or measure any characteristic of
anything, and the result will vary from instance to instance. Plan or measure a task-duration, or
a cost associated with that task, and a natural variance will appear. Management gurus Walter
Shewhart and W. Edwards Deming taught that reacting to random changes in the system as if
they mean something always degrades the process.
But first let’s put some bounds on the term uncertainty. With the two kinds uncertainty in
projects and corresponding mechanisms to address them – irreducible uncertainty and reducible
uncertainty.

Identifying Risk Mitigation Takes a Plan
Planning for risk management starts after risks have been identified and assessed. Risk Analysis
makes use of a variety of mathematical models to evaluate the effects of choices of risk and
mitigation. Risk Analysis also determines the sensitivity of risks to changes in independent and
dependent factors described in the plan.
Table 1. – There are four types of variation for each type of uncertainty in a project’s technical and programmatic variables. Two are simply
part of the ether and are present in any normally operating project. Two are unforeseen and unforeseeable variations. The first two must
have explicit mitigations and the last two will cause the plan to be reevaluated when they appear.
Variation Type Mitigation For This Variation Type
The normal variations that occur in the
completion of tasks arising from normal work
processes. Deming has shown that these
uncertainties are just part of the process and
attempts to control them, plan around them, or
otherwise remove them is a waste of time.
Fine-grained assessment points in the plan verify progress.
The assessment of these activities should be done in a 0%
or 100% manner. Buffers and schedule margin are inserted
in front of the critical activities to protect their slippage.
Statistical process control approaches forecast further
slippage.
Foreseen uncertainties that are identified but
have uncertain influences.
Creation of contingent paths forward are defined in the
plan. These on ramp and off ramp points can be taken if
needed
Unforeseen uncertainties are events that can’t be
identified in the planning process.
When new problems appear new approaches must be
developed
Chaos appears when the basic structure of the
project becomes unstable, with no ability to
forecast its occurrence are the uncertainties that
produced
Continuous verification of the project’s strategy is needed.
Major iterations of deliverables can isolate these
significant disruptions
Next Steps
Using the risk classifications in Table 2, the explicit risk mitigation tasks (risk buy down or risk
margin) can then appear in the schedule as discrete activities or margin activities in the same
way any business work activity that delivers business value can be found in the schedule
Table 2. – The ordinal classification of risk needs to have descriptions meaningful to the reader. The ordinal values
should not be numeric. This avoids the temptation of performing arithmetic on the risk raking.
Classification Uncertainty Overrun (%)
A Routine, been done before Low 0 to 2
B Routine, but possible difficulties Low to Medium 2 to 5
C Development, with little technical difficulty Medium 5 to 10
D Development, with some difficulty Medium to High 10 to 15
E Significant effort with technical challenge High 15 to 20
F No experience in this area Very High 25 to 50
With these risk mitigation activities in place, the next steps include:
1. Identify probabilities for the various durations for risky activities in the plan and the
durations of the mitigation activities.
2. Assessing the risk adjusted completion dates for the deliverables defined in the schedule.
3. Assessing the impact of these risks and the mitigations on the cost and schedule described
in the activity network.

Decision Making in the Presence of Uncertainty
With the Risk Management processes in plan, we can now make decisions about the project
Decision-making is the process of choosing among alternatives. The nature and context of
decisions vary and have a variety of criteria to be considered in making a choice. The alternatives
can involve a large number of uncertainties about the factors that influence the ultimate
outcomes. For high-consequence decisions with potential outcomes that can have a large impact
on valued things, the decision-making process should involve consideration of uncertainties
about the outcomes.[3]
Each level focuses on different aspects of the problem of making decisions in the presence of
uncertainty and the resulting risk.
Risk Management is critical, but it is decision making that we're after.
The purpose of the analysis is not to obtain a set of numbers describing the risks and the potential
decision alternatives. The analysis is to provide the decision-maker the insight needed to choose
between alternatives. These insights typically have three elements:
§ What is important to making the decision?
§ Why is it important?
§ How important is it?
For customers paying for the development of software, these things include - cost, schedule (time
cost of money), market timing, and performance of the product to name a few.
A decision is a resolution on an issue, or a problem of interest being considered. The process of
making a decision involves three elements: values, alternatives, and facts (Buede, 2009). [3]
Values are criteria used to assess the utility of the outcome. Depending on the context, values
can be objective or subjective, and quantitative or qualitative. The values capture the needs,
objectives, and preferences of the stakeholders, which are the people and organizations that
have an interest and can influence or be influenced by a decision.
Alternatives may be given or can be the result of a creative process to generate potential
solutions to the problem of interest. The facts are everything known about the alternatives and
the context or environment in which the alternatives will be deployed or applied.
Facts are the relevant data, information, and knowledge used in the process of assessing the
alternatives against the values in order to make the decision. The decision makers use available
facts, history, experience, and judgment to select an alternative.
Decision making is hard. Decision making is easy when we know what to do. When we don't know
what to do there are conflicting choices that must be balanced in the presence of uncertainty for
each of those choices. The bigger issue is that important choices are usually ones where we know
the least about the outcomes and the cost and schedule to achieve those outcomes.
Decision science evolved to cope with decision making in the presence of uncertainty. This
approach goes back to Bernoulli in the early 100’s, but remained an academic subject into the
20th century, because there was no satisfactory way to deal with the complexity of real life. Just

after World War II, the fields of systems analysis and operations research began to develop. With
the help of computers, it became possible to analyze problems of great complexity in the
presence of uncertainty.
In 1938, Chester Barnard, authored of The Functions of the Executive, and coined the term
“decision making” from the lexicon of public administration into the business world. This term
replaced narrower descriptions such as “resource allocation” and “policy making.”
Decision analysis functions at four different levels:
1. Philosophy ‒ uncertainty is a consequence of our incomplete knowledge of the world. In
some cases, uncertainty can be partially or completely resolved before decisions are made
and resources committed. In many important cases, complete information is not available or
is too expensive (in time, money, or other resources) to obtain.
2. Decision framework ‒ decision analysis provides concepts and language to help the decision-
maker. The decision maker is aware of the adequacy or inadequacy of the decision basis.
3. Decision-making process ‒ provides a step-by-step procedure that has proved practical in
tackling even the most complex problems in an efficient and orderly way.
4. Decision making methodology ‒ provides a number of specific tools that are sometimes
indispensable in analyzing a decision problem. These tools include procedures for eliciting
and constructing influence diagrams, probability trees, and decision trees; procedures for
encoding probability functions and utility curves; and a methodology for evaluating these
trees and obtaining information useful to further refine the analysis.
For our Kitchen project, we need to apply each of these risk analysis functions.
1. What uncertainties can we remove before we even start? Visiting the appliance showroom
provides information about cost, features, availability, installation effort, service plans. Do
we want a 4 burner cook top or a 4 burner cook top? What’s the impact on plumbing and
electrical for that choice?
2. How are we going to make decisions in the presence of uncertainty for the kitchen? One way
is to develop a rough sketch of the kitchen and assess the risks to each of the major elements.
Using a risk register to capture this information, assess a probability of occurrence or a
statistical range of values (duration variance) to each of these risks.
Framework for Continuous Risk Management in Support of Decision Making
There are several frameworks for managing risk in the presence of uncertainty. One place to start
is the Software Engineering Institute’s Continues Risk Management framework. While this
sounds like a process for software development, the CRM Framework can be applied in any
project management domain.
CRM has six elements.

Figure 3 – the six elements of the Software Engineering Institute Continuous Risk Management process. All six processes must be in place and
used, if Risk Management is going to be successful. Figure 4 describes more detail of the steps and data needed for Risk Management, but this
diagram is the starting point.
1. Risk Identification ‒ Before risks can be managed, they must be identified. Identification
surfaces risks before they become problems and adversely affect a program. The SEI has
developed techniques for surfacing risks by the application of a disciplined and systematic
process that encourages program personnel to raise concerns and issues for subsequent
analysis. To identify risks we must:
§ Capture a statement of risk describing the name of the risk, the probability of the risk
occurring, the potential impact of the risk if it were to occur, and risk handling plans to
either retire the risk or handle the risk if it were to occur.
§ Capture the context of a risk that provides additional information about the
circumstances of the risk. The context is a detailed description of the events,
circumstances, and inter-relationships that may affect the project.
2. Risk Analysis ‒ is the conversion of risk data into risk decision‒making information. Analysis
provides the basis for the program manager to work on the “right” risks. To analyze risks we
need to:
§ Evaluate the attributes of the risks to gain a better understanding of the risk to determine
the expected impact, probability, and timeframe of the risk.
§ Classify the risks by looking at the set of risks and how the risk relates to each other as a
class. The classes or groups of risk provide different perspectives when planning for the
risk mitigation processes.
§ Prioritize and rank the risks to separate which risks should be dealt with in what order
when allocating resources.
3. Risk Planning ‒ turns risk information into decisions and actions (both present and future).
Planning involves developing actions to address individual risks, prioritizing risk actions, and
creating an integrated risk management plan. The plan for a specific risk could take many
forms. For example:

§ Mitigate the impact of the risk by developing a contingency plan (along with an identified
triggering event) should the risk occur.
§ Avoid a risk by changing the product design or the development process.
§ Accept the risk and take no further action, thus accepting the consequences if the risk
occurs.
§ Study the risk further to acquire more information and better determine the
characteristics of the risk to enable decision making.
4. Risk Tracking ‒ consists of monitoring the status of risks and actions taken to ameliorate risks.
Appropriate risk metrics are identified and monitored to enable the evaluation of the status
of risks themselves and of risk mitigation plans. Tracking serves as the “watch dog” function
of management. The person responsible for the tracking process:
§ Acquires information about the risk by collecting data about the context, impact,
probability, timeframe, rank, and planned approach for each risk.
§ Compiles which data for a given risk is analyzed, combined, calculated, and organized for
tracking the risk and the risk handling plans.
§ Reports this tracking information in a Risk Management Plan (RMP) used to communicate
risk status and handling plans. These reports are delivered as part of routine project
management activities of the project.
5. Risk Control – corrects for deviations from planned risk actions. Once risk metrics and
triggering events have been chosen, there is nothing unique about risk control. Rather, risk
control melds into program management and relies on program management processes to
control risk action plans, correct for variations from plans, respond to triggering events, and
improve risk management processes.
6. Risk Communication & Documentation – Risk communication lies at the center of the model
to emphasize both its pervasiveness and its criticality. Without effective communication, no
risk management approach can be viable. While communication facilitates interaction among
the elements of the model, there are higher level communications to consider as well. To be
analyzed and managed correctly, risks must be communicated to and between the
appropriate organizational levels and entities. This includes levels within the development
project and organization, within the customer organization, and most especially, across that
threshold between the developer, the customer, and, where different, the user. Because
communication is pervasive, our approach is to address it as integral to every risk
management activity and not as something performed outside of, and as a supplement to,
other activities.
Putting these six processes together and the supporting data and integrations is shown in Figure
4.

Figure 4 ‒ integrating the six risk management process of Continuous Risk Management, with their supporting data. This process flow is a
continuous set of activities, performance at periodic points. Usually when the project is statused ‒ weekly and no longer than monthly. Since all
project performance management is risk informed, conducted with the continuous risk management processes as part of the project’ status is
the way to make informed decisions.
Risk Management Plan is the Starting Point for Risk Management
The best way to start to think about risk management is to reflect again on Tim Lister’s advice –
“risk management is how adults manage project.” Risk management is essential to the success
of any significant project. Information about key project cost, performance, and schedule
attributes is often unknown until the project is underway. These risks can be mitigated, reduced,
or retired with a risk management process. Risk management is concerned with the outcomes of
a future event. Project events whose impacts are unknown. Risk management is about dealing
with this uncertainty.
We’ve seen the previous steps needed to perform Continuous Risk Management. But let’s look
at the motivation for this process and the beneficial outcomes. There are five simple concepts of
risk management that are represented in the Risk Register and the Risk Management Plan.
1. Hope is not a strategy: Hoping that something positive happens will not lead to success.
Preparing for success is the basis of success. We need a written plan for identifying and
handling the risks that threaten the success of the project. This is the basis of the Risk
Management Plan. If it is not written down, it will not be handled.

2. All single point estimates are wrong: Single point estimates of cost, schedule, and
technical performance are no better than 50/50 guesses in the absence of knowledge
about the variances of the underlying distribution. In our Risk Management Plan, we must
have credible estimates for our work and the performance of the outcomes from the
work. This means a probabilistic estimate of cost and schedule at a minimum. With these
estimates, we can now plan for the contingencies needed to deliver on-time and on-
budget.
3. Without integrating Cost, Schedule, and Technical Performance, we are driving in the
rearview mirror: The effort to produce the product or service and the resulting value
cannot be made without making these connections. Our Risk Management Plan must
describe how we are going to do this integration and who is accountable for assuring
these three entities are connected in the proper manner to show not only the risks, but
how they will be handled.
4. Without a model for risk management, you are driving in the dark with the headlights
turned off: Risk management is not an ad hoc process that you can make up as you go. A
formal foundation for risk management is needed. Choose one that has worked in high-
risk domains – defense, nuclear power, manned spaceflight.
5. Risk Communication is everything: Identifying risks without communicating them is a
waste of time. The Risk Management Plan must have a Communication Plan that connects
the project participates with the customer, so all the risks are visible, agreed to, and have
acceptable handling plans.
To be credible, the Risk Management Plan must contain the following sections:
1. Executive summary: a short summary of the project and the risks associated with the
activities of the project. Each risk needs an ordinal rank, a planned mitigation for the risks
that are active and approved by the Risk Board. , These mitigation plans are then shown
in the IMS with their costs defined and approved.
2. Project description: a detailed description of the project and the risk associated with each
of the deliverables. Each of the descriptions needs to speak to what happens is the risk
comes true, how we are going to prevent this from happening, the probabilities of the
risk happening and residual probability of the risk after the mitigation work has been
done. This residual risk probability is always there, because in the project world, there is
no such thing as 100 percent anything.
3. Risk reduction activities by phase: using some formal risk management process that
connects risk, mitigation and the IMS. The efforts for mitigation need to be in the
schedule.
4. Risk management methodology: – using the Risk Management process, as shown in
Figure 4, is a good start. This approach is proven and approved by high risk, high reward
projects. The steps in the processes are not optional and should be executed for ALL risk
processes.

The Risk Register
The Risk Management Plan tells us how we are going to manage risks on the project. The Risk
Register is where we record these risks, their probability of occurrence and impacts, and our
“handling” strategy. Figure shows a “notional” risk register, with the minimum elements needed
to manage project risks. Risk is composed of two core components:
1. The “threat”: there are circumstances with the potential to produce a loss or harm the
project in some way.
2. The “consequences”: that the loss will occur when the threat is realized.
There are three ways to structure the risk statement in the Risk Register, but they always contain
the same semantics:
1. An “If Then” statement: “If we miss our next milestone, then the project will fail to achieve
it product, cost, and schedule objectives.”
2. A Conditions-Concern statement: “Data indicates that some tasks are behind schedule
and staffing levels may be inadequate. We are concerned the program could fail to
achieve its product, cost, and schedule objectives.”
3. A Condition-Event-Consequence statement: “Data indicates that some tasks are behind
schedule and staffing levels may be inadequate. This will mean (the event of) missing our
next milestone, with the project (consequence) failing to achieve its product, cost, and
schedule objectives.”
The Risk Register needs to contain descriptions of the risk, impact, consequences, and conditions
before we can define any risk handling plans. Simply making a list of risks will not be sufficient to
protect the project from their occurrence.
The next step is to rank the risks in some form so we can prioritize them along with their impacts
and cost to “handle.” Many books and papers guide us in assigning numbers to the probability of

occurrence and then ranking the risks using those numbers. They also guide use in assigning
numbers to the impact. With these two numbers, we can multiply them together to get a risk
score. This approach, called “ordinal” ranking, must be avoided if we are to have a credible risk
management plan. “Ordinal” ranking is a relative comparison of two items. “This risk is larger
than that risk, because one has a 1 assigned and the other has a 2 assigned.” I’ll say it again: Do
not label the probability of occurrence and impact with numbers and multiply them. We do
define the risks in terms of “cardinal” measures, that is, measures are “calibrated” to the domain
of the risk. The details of this “cardinal” approach are described in a scale of A, B, C, D, E, and
these values assigned specific probabilities of occurrence. For example, for the probability of
occurrence, we can speak in “cardinal” terms:
§ A = “unlikely to occur = 10% probability of occurrence.”
§ E = “high probability to occur = 90% probability of occurrence”
For the impacts, we need more detail as to what will actually happen.
§ A = “minimal or no impact”
§ B = “minor reduction in technical capability”
§ E = “severe degradation of the technical performance”
These “Cardinal” values can then be used to construct a Risk Matrix like the one shown in Figure
5

Figure 5 ‒ a Risk Matrix with cardinal values for likelihood of the risk occurring and the impact of that concurrence.

Wrap-up for the Principles of Risk Management Applied to the Kitchen Project
Let’s apply Continuous Risk Management to the Kitchen project
CRM Process Example in the Kitchen Project
Identify the risks § What’s hidden behind the dry wall when we tear into it
for electrical rewriting
§ Same for the plumbing
§ Same for the structural elements – ceiling and floor
joints
Analyze the risks § If we find these, what’s the impact on the cost and
schedule?
Plan for the mitigation of the risk § Assess impacts and have a handling plan for each risk
Track the mitigation activities § Determine as early as possible these risks and assess
the impact on the design of the kitchen
Control the risk § Using the assessment information, update the
schedule, cost estimate and resource requirements.
Licensed electrician for example.
Communicate the progress on
risk management
§ Have a daily meeting with the client on the progress of
the work, any delays, any higher costs.
Bibliography
1. Continuous Risk Management Guidebook, Christopher J. Alberts, Audrey J. Dorofee, Ron
Higuera, Richard L. Murphy, Julie A. Walker, and Ray C. Williams, Software Engineering
Institute, Carnegie Mellon University, 1996.
2. Risk Informed Decision Making Handbook, NASA/SP-2010-576
3. "Considering Risk and Resilience in Decision Making," Wilfredo Torres-Pomales, Langley
Research Center, Hampton, Virginia, NASA/TM-2015-218777

Risk Management

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Risk Management

Similar to Risk Management (20)

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

Risk Management