JISA Final Lectures

Jump to Navigation Frame Jump to Content Frame
Printable View of: Lecture 7 - Introduction to Risk Management

Print Save to File File: LECTURE 7 - Introduction to Risk Management
Lecture 7 - Introduction to Risk Management
Reading: Kanabar, Chapters 1-6 (you'll read these chapters throughout Weeks 4 and 5).
Use the links at the bottom of this page.
Assignment and Discussion Schedule
To submit assignments and participate in discussions, click on the appropriate icon on the
left (course-wide) or at the top of the page (for each week).
Before beginning this lecture, please watch this

short video introduction by Larry Watson.
Click on the play button to start the video.
Today we start looking at risk management, which is one of the most important areas in
project management, as well as in life in general. Literally, all management and decision-
making are forms of risk management!
Also, for those planning to take the PMP exam, historically the questions on risk
management have been where candidates make the most mistakes. So you can pick up
some additional points by knowing this area.
If you look at the PMBOK 2005, Chapter 11 covers project risk management and breaks
the Project Risk Management Process into six areas:
Risk Management Planning

Risk Identification
Qualitative Risk Analysis
Quantitative Risk Analysis
Risk Response Planning
Risk Monitoring and Control
Following a brief overview, we will address each of these aspects of risk management in
the subsequent material.
For the Risk Management component of this course, we have supplied an additional
resource, which can be downloaded using the links below:
Project Risk Management, A Step-by-Step Guide to Reducing Project Risk by Vijay

Kanabar.
Click here to download.
Project Risk Management, Updates to Risk Management Content.
Click here to download.
File: Fundamentals of Risk Management

Fundamentals of Risk Management
Risk management is not magical—it's something we all do.
You "look both ways" before crossing a street (hopefully) so you avoid geting hit by a
car. This is one example of risk management – behavioral responses to learned risks.
In the business world many projects get hit by the proverbial car because the project did
not practice good risk management. In many cases risk management is put in the back set
as a nice-to-have. This second-order prioritization is principally due to the lack of
understanding of how risk management works. Everyone acknowledges that there are
risks associated with actions, but many teams refuse to analyze "what-ifs" believing
incorrectly, that risks are unpredictable and therefore addressed ad hoc. You must become
a good risk manager, understand what risk analysis and preparation can do for your
project and communicate that to the executive team.
Fortunately learning how to deal with risk does NOT require luck. Here you will learn the
basic steps involved in a creating an effective risk management plan. Keep in mind that
learning about and responding to risk does NOT require any luck, but it does require the
experience and knowledge of the work that is possessed by your project team.
One key concept is that over a project life cycle, the greatest chance of risks occurring are
at the beginning of the project and as the project progresses, the chance of risks occurring
decreases. The impact of these risks on your schedule and cost also change over a project
life cycle; early in the project the risk impact is low and as the project progresses the
potential impact of the risk events increases.
File: Defining Risk
Defining Risk
The dictionary defines it this way:
To most people, risk means the chance of a negative occurrence and is typically
associated with words like "danger," "hazard," "peril," and "jeopardy." However one
should also consider positive risks and so include words such as "contingency,"
"opportunity," "prospect," and "uncertainty." The PMBOK defines risk as "An uncertain
event or condition that, if it occurs, has a positive or a negative effect on a project’s
objectives." Remember that risks may also present positive opportunities.
Risk, as we will use it, has two major components: it has a measurable chance of
occurring, or a probability factor, and it has a potential measurable impact.
What is the Difference between “Risk” and “Uncertainty”?

Let’s look at this in light of three possible states: certainty, risk, and uncertainty. Certainty
implies that we can absolutely predict some outcome in the future. Uncertainty implies
that we don’t have a clue, or any knowledge that would assist us in predicting that future
outcome. With risk we try to predict that future outcome based on some level of
knowledge coupled with the use of probabilities to estimate a measurable expected value
of that outcome and its potential impact.
File: An Example
Defining Risk:
An Example
Let’s look at how you may use risk management in your real life. Let’s say you live in the
Boston area in a single family house with a current market value of $400,000. You
recognize a risk: the house may burn down. What are you likely to do?
The first step was actually recognizing the risk. If you have a mortgage on the house, the
risk was already recognized by the lender who required you to obtain a fire insurance
policy on the house. But what if you don’t have a mortgage?
You still recognize the risk. To you, it may be an uncertainty, i.e., you have no clue of the
chances of that house actually burning down. But to an insurance company, it is a risk
because they can assign the probabilities of your house burning down and due to the “law
of large numbers,” they can add your house to a pool of other houses and statistically,
they can predict how many houses out of that large pool will burn down and what the
total losses will be, and charge each member of the pool a premium which will pay for
the losses, as well as provide a profit to the insurance company.
Chances are that you will not choose to accept the whole risk of the house burning down
yourself, but if you did, you would save the insurance premiums. Also, chances are you
wouldn’t choose to avoid the risk completely by just selling the house and moving into
someone else’s house - someone who would then shoulder the financial risk of their
house burning down.
What you do by purchasing a fire insurance policy is to transfer the financial risk of a
loss to an insurance company.
However, you are also sharing the risk with them because most likely you have a
deductible with your policy.
But there is more to the risk than financial consequences.
You are probably also concerned about potential injury and loss of life. The actual risks
are not transferred to the insurance company, so you probably attempt to mitigate them.
You probably have installed smoke detectors, and you may have evacuation plans
involving stairways and fire ladders, and if you have children, you may have had training
sessions concerning what to do in case of a fire. You probably don’t store lots of
flammable or toxic chemicals in the house, and you may have a fire extinguisher on hand.
Hopefully you have an inventory and pictures of the contents in case there is a fire (you'll
need these in order to assist in justifying your claim). All of these are forms of mitigation
—reducing either the likelihood of a fire or its impact.
File: A Closer Look at Risk Management

A Closer Look at Risk Management
In 1985, T.V. Carver defined risk management as a "method of managing that
concentrates on identifying and controlling the areas or events that have a potential of
causing unwanted change…it is no more and no less than informed management."
Risk events have causes, and if they occur, they have consequences. Risk management
attempts to deal with the events, the causes, and the consequences.
However, risk management needs to be proactive in recognizing the events, the causes,
and the consequences, not just reactive. Therefore, you need a system that plans for the
various risk events, identifies and analyzes the causes and impacts, handles and controls
the risks if they occur, and monitors the whole process throughout a project.
Once a particular risk is identified, there are options for how to deal with it. They include:
File: Understanding Probability and Impact

A Closer Look at Risk Management:
Understanding Probability and Impact
Many years ago I saw a graph similar to the one on the right, which clearly shows the
concepts of measuring the probability of an event occurring like getting bitten by an
animal compared to measuring the potential impact of it. This is risk management, and
we do it all of the time. We measure situations and make choices like accepting the
situation, avoiding or rejecting it, mitigating (reducing) the potential cause, impact, or
chances of the situation, or transferring it to another party.
So, what’s the potential of getting hurt by the above animals and what might you do
about it?
Kittens and puppies are cute and relatively harmless—we usually just ACCEPT the risks.
Many of you will also say the same about cats and dogs—however, some of the dogs may
be Pit Bulls! We may ACCEPT the risks—or AVOID the risks, or even MITIGATE the
risks by making sure the dogs are chained or leashed.
What about alligators? I've occasionally seen them on some golf courses and although
they are potentially very dangerous, they can only sprint for about 30 feet and they can't
run and turn at the same time due to the size of their tails. So, if you hit a golf ball near an
alligator, you can try to out maneuver it (ACCEPT), drop another golf ball (AVOID), or
have the caddy retrieve your ball (TRANSFER).
As for a mother bear with cubs—she is one of the most dangerous animals and should be
AVOIDED at all costs.
The above decisions are based on our analysis of both the potential probability of a
situation occurring, analyzing its potential impact, and factoring our own willingness not
to accept risks—which is referred to as Risk Aversion.
File: The Status of Risk Management

The Status of Risk Management
Historically, risk management is a relatively new art and science. It has always been
around, but now it is becoming much more recognized and formalized in all areas of
business.
Businesses used to be generally reactive: after something happened, they often tried to
just buy insurance in case it happened again, or even just accepted the results as a cost of
doing business. They worked through outside insurance agents and brokers, or even
established internal insurance management departments.
Government intervention in areas like workers' compensation, safety (OSHA), product

safety, and other labor laws tended to lead to companies buying more insurance.
However, as insurance premiums rose, companies realized that they could save money by
reducing the likelihood of risks, not just dealing with the financial consequences. So
companies started developing internal departments like safety, security, and quality, and
many actually developed internal risk management departments.
Today, risk management is becoming much more integrated across all aspects of
companies because of the interrelated causes and effects of various risks. This is
especially true in the field of project management.
One additional point: today you will often see the term risk management used in other
contexts, such as on Wall Street. Risk management concepts are now commonplace in the
financial world in areas such as investment management.
Risk management is everywhere.
File: Risk Management from a Project Management Perspective

Risk Management from a Project Management Perspective
Now, let's move more to the project management perspective on risk management. On
page 241 of the PMBOK, please view the diagram showing how PMBOK looks at the
whole Project Risk Management Process.
Notice the inputs to the first step of the Project Risk Management Process, Risk
Management Planning. These are:
Enterprise Environmental Factors

Organizational Process Assets
Project Scope Statement and Project Management Plan
The primary purposes of the risk management planning process are to attempt to isolate,
minimize, and eliminate risks which may affect the project; determine alternative courses
of action to mitigate risks; develop cost and schedule contingency reserves for risks that
cannot be eliminated or mitigated; and determine how risk management will be done for
the project (Who does what? When? What are the procedures to be followed? What is the
role of the organization's Risk Management Department, if any?).
NOTE: The Project Manager is ultimately the person responsible for the risk
management planning process, even if he or she inherits the project after initial planning
is completed.
As Professor Kanabar points out in his book, risk management has often been compared
to medicine: Prevention is better than the cure.
File: What to Consider with Risk Management

What to Consider with Risk Management
One of the first considerations in the risk management planning area is the length, size,
and/or the complexity of the project. For short-term, simple projects, planning is usually
only needed prior to beginning the project. But as projects increase in time and/or
complexity, additional planning may be needed at major milestones and decision points
or if a significant unplanned change or event affects the project.
The primary enterprise environmental factors are the risk attributes and risk tolerance
levels of the organization and the stakeholders. In real life most of us are naturally risk
averse, which basically means we tend not to accept risks unless we feel that we will be
adequately compensated for taking those risks.
However, especially in business environments, we find some people being risk averse,
some being risk neutral, and some being risk takers. It is critical to know what levels of
risk the stakeholders will accept as well as what attitudes toward risk they expect you to
have.
Looking at organizational process assets, it is a must to know the roles, responsibilities,

and authority levels for anyone in the decision-making process involved in the project.
This includes knowing who approves what, and when they need to be accessed.
The project scope statement and the project management plan are pretty self explanatory.
But the project manager must look around and consider:
the overall behavioral environment of the organization (including organizational risks

like staff attrition).
the organization's attitudes toward both project management and risk management
possible overlapping of management functions surrounding the project
multiple concurrent or competing projects
possible dependence on external participants who cannot be controlled during the project
project management team experience, which may indicate risk management training
needs, as well as the experience of the project manager himself / herself
possible international, cultural, language, and time zone issues
technical risks to include unproven or anticipated new technology
Additionally, the project manager should be aware of in general terms, both internal and
external factors which may present risks to the project. Depending on the project,
external factors might include the overall economy, governmental regulations, market
demand, inflation, currency exchange rates, raw material shortages, and status of
competitors. Internal factors, other than the organization environment, might be technical,
legal, quality, performance, funding availability, labor issues, and the degree of
importance being placed on cost and time schedules.
File: Good Risk Management Planning

Good Risk Management Planning
Good risk management planning helps to develop a risk management strategy which
ultimately leads to a good Risk Management Plan (RMP), which is the primary output of
the risk management planning process. Another output is the Risk Breakdown Structure
(RBS), a sample of which you may see on page 244 of the PMBOK.
Additional outputs of the whole project planning process include the project charter, the
project scope statement, and the work breakdown structure (WBS) in addition to the risk
management plan.
In an article in the September 2005 issue of PM Network, the professional magazine of

the Project Management Institute, entitled Risking Less by Marcia Jedd, and based on a
research paper presented by Chris Felstead, PMP, Chris noted, “At many organizations
today, risk management isn’t aggressive enough in planning for contingency or for
making big decisions necessary for investing in preparation for those contingencies.” He
also pointed out that it is the organization and the stakeholders who bear the brunt of the
risks regarding a project. Their involvement in risk decisions and planning fosters greater
stakeholder commitment to a project.
All of these factors need to be considered for the next phase, which is the actual
identification of risks, where we will start the next lecture.
File: Lecture 7 - Summary

Lecture 7 - Summary
Today we looked at risk management in general and more specifically, the importance of
the Risk Management Plan in project management. Next we will concentrate on
identifying risks and qualitative risk analysis.
To submit assignments and participate in discussions, click on the appropriate icon on

the left (course-wide) or at the top of the page (for each week).
Printable View of: Lecture 8 - Risk Identification and Qualitative Risk Analysis
Print Save to File File: LECTURE 8 - Risk Identification and Qualitative Risk
Analysis
Lecture 8 - Risk Identification and Qualitative Risk Analysis
Reading: Kanabar, Chapters 1-6

We will now look at PMBOK’s second and third steps in the Risk Management Planning
Process: Risk Identification and Qualitative Risk Analysis.
Risk Identification
The identification of possible risks is one of the most critical areas of project risk
management—if you fail to recognize risks you won’t plan for them. Also, risk
identification is not a one-time process—it needs to occur across all aspects of the project
lifecycle as shown here:
Note that new risks may be identified or come into existence at any point of the project.
After the risk management planning meeting, the PM assembles the project team, the
stakeholders, and other major players in the project to identify all possible risks that may
affect the desired outcome of the project. The Risk Assessment Session, which should be
limited to 12-15 participants, has the goal of identifying, qualifying, characterizing and
assigning the risks. During the assessment you will ask each member of your project
team will identify one or two issues that "keep you up at night", but it is very important to
remember that this is meant to identify, and make plans for, the most important risks.
File: Inputs
dRisk Identification:
Inputs
The PMBOK lists five major inputs to risk identification:
Enterprise Environmental Factors, which would include published information from

industry studies and commercial databases, benchmarking, and published lists of risk
categories.
Organizational Process Assets, which would include a review of prior projects from the
project files.
Project Scope Statement, which may contain assumptions which need to be evaluated
regarding their level of possible uncertainty.
Risk Management Plan, which contains the roles and responsibilities of the various
parties and personnel involved, as confusion in this area can pose additional risks. This
plan would also include budget and schedule provisions for risk management functions.
Project Management Plan, which deals with the main issues of costs, schedules, quality,
etc., can be a good source of identifying risks.
Additional input factors might depend on the particular end product of the project, special
constraints imposed on the project, and the potential timing of the various risks across the
project. Other planning documents already prepared for the project like the project
charter, WBS, and initial project estimates are also possible input factors.
There are two general kinds of risks which need to be considered. The first group is
business risks, which are risks or opportunities which may generate a profit or a loss. The
other category is insurable risks, which are risks which only contain the chance of a loss.
File: Tools
Risk Identification:
Tools
The PMBOK then lists several tools and techniques regarding risk identification,
including:
Documentation reviews
Information gathering techniques
Checklist analysis
Assumptions analysis
Diagramming techniques, including Flowcharts, Cause-and-effect diagrams, Network
diagrams, and Influence diagrams
Other common published methods include:
Data Precision Ranking
Assumption Testing for Stability and Consequences
Risk Modeling
Analogy Comparisons
Of these, information gathering techniques are often the most important as well as the
most varied. Some of these techniques include:
Brainstorming
Interviewing
Root cause identification
SWOT (strengths, weaknesses, opportunities, and threats) analysis
Expert judgment analysis
Various tools like the Delphi Method, Nominal Group
Techniques and the Crawford Slip (you should review these tools if you are unfamiliar
with them)
File: Risk Categories

Risk Categories
Remember, the goals are to try and list all possible risks which may impact the project
and understand the causes of these risks. First, you have to develop a list of risk
categories you are going to use. These may include such risk categories as:
Scope risks
Cost risks
Schedule risks
Technical risks
Quality risks
Performance risks
Organizational (internal) risks
External risks
Stakeholder pressure risks
Customer satisfaction risks
Project Management risks (lack of skills and/or tools)
Environmental risks
Other General risks
Once your risk categories are developed, you can create risk profiles tailored to your
project. An example of a partial risk profile is shown below.
The risk profiles provide event descriptions which will be further analyzed in qualitative
and quantitative risk analysis.
Another possible output of the risk identification process is to develop a list of risk
triggers; these are specific warning signs or events that advise you when to take an action
such as implementing contingency plans.
You may also do some sensitivity analysis of your identified risks in order to start to see
where the most serious impacts of the risks may be and to determine activities affected.
In Vijay’s book, he also looks at risk identification from both the top-down approach,
which focuses on the overall project development process, and the bottom-up approach,
which focuses on individual project processes.
Risk identification may also lead you in further qualitative and quantitative sections to
consider testing requirements, modeling and simulation alternatives, and sensitivity
analysis of alternatives.
The final formal output of the risk identification process is the Risk Register, which
contains the full list of risks and potential responses to these risks.
File: Risk Identification Summary

Risk Identification Summary
Remember, the goal of the risk identification process is to have the project team list the
major risks across the project that may have a positive or negative impact on the project,
to formally document these lists, prioritize them, and identify people who will be
responsible for monitoring these risks.
Your project team is the source of the knowledge of most project risk. For example, I was
involved in a couple of large office relocation projects and as the risk manager of the
company, I was involved in the risk management planning and risk identification
processes with a very experienced project manager. He posed a risk that I hadn't
considered, and he proved to be right to consider it.
The overall project plan involved all department managers submitting space requirements
as well as breaking down the types of space, such as executive offices, standard offices,
conference room, specialized rooms, cubicles, storage areas, etc. Once the size of the
expansion was approved by the president, formal plans and drawings were prepared and
approved by the department managers, which led to an approved budget and a project
schedule.
The risk he identified was the potential cost of after-the-fact changes to many of the
areas. Why did he consider this a risk? Because, from his previous experiences, he knew
that many people cannot look at construction drawings and plans and actually visualize
what the final work product will actually look like.
He was right. When the work was basically complete and the managers got to actually
see their new spaces, they had all kinds of problems. The ceilings were too high or too
low, the doors and window weren’t where they thought they were, the furniture was too
big or too small for the space, they could or couldn’t see their secretaries from their
desks, etc.
If everyone involved was allowed to make major changes after the space had been built
and furnished, the cost would have been prohibitive.
Looking ahead, how did he factor this risk into the project?
First, he reviewed all of the plans with the department managers and had them sign off on
the final drawings. Then he had the President issue a memo that any after-the-fact
changes had to come out of the individual department budgets, not the project budget.
Bottom line: there were some grumblings, but no serious changes! If this risk hadn't been
identified and dealt with effectively, the job would have been way over budget as well as
late (while people were waiting for the changes).
File: Qualitative Risk Analysis

Qualitative Risk Analysis
OK. Let’s now go on to the next topic: Qualitative Risk Analysis. Qualitative risk
analysis is a quick and cost/time effective method of establishing the priorities of
different risks which may later need to be considered for effective risk response planning.
The basic inputs of qualitative risk analysis, according to the PMBOK, are:
Organization Process Assets (lessons learned)

The Project Scope Statement
The Risk Management Plan
The Risk Register
The tools and techniques used in the qualitative risk analysis are:
Risk Probability and Impact Assessment, which use expert judgments

Probability and Impact Matrix
Risk Data Quality Assessment, which challenges the quality of the data
Risk Categorization, which helps to determine which areas of the project are most
exposed to risk
Risk Urgency Assessment, which determines the high-priority risks which must be
further addressed and helps prepare watch lists of lower-priority risks
The most important and common tools and techniques are the Probability and Impact
Assessment and the derived Matrix. Probability and impact of the risk events are defined
below:
Probability
The number that represents the chance that a particular outcome will occur, expressed as
a percentage. All risks would have a probability of greater than zero and less than 100%
because if it had a probability of 0, there would be no risk, and if it had a probability of
100%, it would be a certainty.
Impact
The cost we incur if the risk occurs. Or, putting it a different way, it’s the amount of pain
we will feel. We used the term cost, however, the impact may actually be felt on the
schedule or the scope as well.
File: Applying Numbers

Applying Numbers
If we put probability and impact together by looking at Probability X (times) Impact, we
can come up with some numerical system for measuring and ranking the possible severity
of the risks. Such a scale would measure the overall importance of each risk evaluated in
our project and ultimately lead to determining risk strategies.
In order to create such a rating scheme, we first need to determine definitions of ranges.
For example, if we decide to keep it very simple and define probability and impact as
high, medium, or low, what do we mean by high? Or low? If one team member thinks
90% is high but 75% is medium, and another thinks anything over 66% is high, you start
to get different meanings of the words. You need to eliminate these biases by establishing
relatively clear ranges.
At this early stage of risk assessment it makes little sense to concentrate on minutia and
instead agree to three ranges, Low, Medium and High. It is important that the team
understand what these ranges mean in terms of cost, schedule and quality.
Following agreement on defined ranges you can do two things:
First, you can develop a risk assessment form like the following example from the Gray
and Larson text where you can list the identified risks and rate them by both probability
and impact:
Note, in this form they also added another rating on detection difficulty.
File: A Few Additional Points

A Few Additional Points
Qualitative Risk Analysis needs to be revisited throughout the whole project life cycle—it
is not a task to be done once and forgotten about.
Qualitative Risk Management can lead to possible project termination decisions if the
project is deemed too risky.
Qualitative Risk Management can factor into decisions involving comparable projects.
The primary output of Qualitative Risk Analysis is Risk Register updates. However, it
also prioritizes the risks which can then either be analyzed quantitatively or subjected to
risk response analysis. Remember to document non-critical risks even if you choose to
just accept them as you may want to revisit them throughout the project, and they may
also become input items for future projects.
File: Probability and Impact Matrix

Probability and Impact Matrix
You can also prepare a probability and impact matrix like the one on page 252 of the
PMBOK.
Note that PMBOK extends its matrix to include opportunities; in real life only the left
side of the matrix is usually used to determine ranges of combined probabilities and
impacts. Also, the PMBOK example shades some zones in an attempt to show combined
low risk areas, medium risk areas, and high risk areas.
Another way of accomplishing the same thing is to color-code the zones using the
stoplight method of showing low risk areas in green, medium risk areas in yellow, and
high risk areas in red. This is actually quite effective and one’s eyes are drawn to the red
areas, or possible danger zones.
Professor Kanabar has used a similar approach in his book (pages 10 – 12) where a color-
coded the numbers in a matrix and a contour method on the full matrix.
Back in Gray and Larson, they also show you an example of a risk severity matrix as
follows:
Actually, any method that calls attention to the important high-probability/impact risks
can be effective because when we deal with risk tolerances, we need to put our efforts in
the areas which have a high probability and a high impact.
Note that some risks will have a very high probability with a very low impact, like small
tools being misplaced or stolen from the job. We try not to be overly concerned with
these risks, as what we are really going to do is self-insure against the losses. Other risks
may have a very low probability but a very high impact, like what happens if we get hit
by a Category 5 hurricane. We also don’t spend a lot of time and effort on these, since
they are beyond our control and there is not really much we can do other than to insure
some of our potential losses, which we probably would have done anyway against
smaller hurricanes.

Lecture 8 - Summary
In this lecture we looked at risk identification, which is the process of identifying all
possible risks (the risks and their causes - not their results) that might affect the project.
Then we looked at qualitative risk analysis, which is the prioritization of the risks in order
to assess their probability of occurrence and degree of impact in order to determine if
further quantitative analysis is required or if a risk response needs to be planned.
Next week we will move on to Quantitative Risk Analysis and Risk Response Planning.

Print Save to File

===============================================================
=============

Printable View of: Lecture 9 - Quantitative Risk Analysis and Risk Response Analysis
Print Save to File File: LECTURE 9 - Quantitative Risk Analysis and Risk Response
Analysis
Lecture 9 - Quantitative Risk Analysis and Risk Response Analysis

In this lecture, we want to examine the next two PMBOK steps of risk analysis,
Quantitative Risk Analysis and then Risk Response Analysis. Quantitative Risk Analysis
is performed on potentially high risks that may substantially impact the project
discovered in the Qualitative Risk Analysis (or even in the Risk Identification Process).
Not all of the risks identified are analyzed quantitatively as this process can involve
additional costs as well as time. Some of the risks identified are deemed trivial, while we
may be satisfied with the results of our qualitative analysis for some of the other risks.
But for the risks that can potentially make or break a project from a cost, schedule, or
performance perspective, we need to do some additional analysis so we can properly plan
our risk response strategies. Quantitative Risk Analysis provides numerical ratings to the
risks, and this can provide further insights when dealing with the major uncertainties of
the project.
File: What the PMBOK Says

What the PMBOK Says
To quote the PMBOK, this (quantitative) process uses techniques to:
Quantify the possible outcomes for the project and their probabilities
Assess the probability of achieving specific project objectives
Identify risks requiring the most attention by quantifying their relative contribution to
overall project risk
Identify realistic and achievable cost, schedule, or scope targets, given the project risks
Determine the best project management decision when some conditions or outcomes are
uncertain
PMBOK lists the inputs to Quantitative Risk Analysis as:
Organization Process Assets

The Project Scope Statement
The Risk Management Plan
The Risk Register
The Project Management Plan (Schedule and Cost)
PMBOK then lists the tools and techniques for Quantitative Risk Analysis as:
Data gathering and representation techniques

Quantitative risk analysis and modeling techniques
We will look at some of these techniques in detail. Included in the data gathering
techniques are what is often referred to as three-point estimates (optimistic, realistic, and
pessimistic) like the ones you see on page 271 of the PMBOK (Figure 11-10). There are
also different kinds of probability distributions (other than normal distributions), as
shown in Figure 11-11 on p. 271 of the PMBOK.
And there is also the use of expert judgments.
File: Modeling Techniques

What the PMBOK Says:
Modeling Techniques
Under modeling techniques PMBOK lists several, including:
Sensitivity Analysis
Expected Monetary Value Analysis
Decision Tree Analysis
Monte Carlo Simulation
Cost Risk Simulation
Plus there are additional tools such as PERT, and many risk models and semi-quantitative
scenario analyses. Vijay's book does an excellent job of discussing many of these tools,
and if you are not readily familiar with them, I strongly recommend that you reread pages
59-81. However, I want to look more closely at expected values, decision trees, and
Monte Carlo simulation.
Expected value (EMV—not to be confused with EV, or earned value, which we covered
in the cost section) is used to calculate the expected monetary value of a risk.
File: Calculating Expected Value

Calculating Expected Value
A good simple example of how to calculate expected value is to consider the following:
You can also look at the EMV approach to consider the whole project. Let's say you are
deciding whether to pursue a project to develop a new product. It will cost $100,000 to
develop and if it's successful, you estimate it will earn $1,000,000. However, you put the
probability of that happening at 5%. You think there is a 35% chance of complete failure
(no earnings) and a 60% chance of just breaking even (earning $100,000). Should you go
ahead on the project?
You have a positive EMV so the answer is yes but not by a large margin. A slight change
in the probabilities could easily turn this into a “no.” This appears to be a risky project—
not necessarily the project itself, but the potential results of doing it.
An additional point about risky projects. Companies have many opportunities to do

various projects and some of them may be high risk, moderate risk, or low risk.
Obviously, one would expect higher returns from the higher risk projects than from the
medium or low risk ones. But it is important that companies also use risk management
logic and techniques in evaluating the overall risk levels of all of their projects. If a
company always picked the high risk ones and had a bad year, it could put them out of
business.
File: Decision Trees
Decision Trees
In your Project Management text, they show a modified version of EMV called the 10,
50, and 90 percent schedules, shown on page 214, which produces a risk schedule as
shown below:
A good way of expanding probability concepts is to use decision trees. Decision trees are
diagrams which attempt to show decision points and different possibilities resulting from
the decisions, as well as considering the probability of each outcome. A good example of
decision trees is in Vijay's book on pages 77-78. Another example of a decision tree
diagram is shown on page 258 of the PMBOK.
Note: Both EMV and decision trees tend to look at the risks associated with the different
aspects of a project. Sensitivity analysis tends to look at which risks have the most
potential impact on the project as a whole. There is also risk modeling and simulation,
which are computer programs designed to estimate the total risk of a project relative to
something like the project's total cost or completion date. The most common of these
modeling and simulation tools is the Monte Carlo technique.
File: The Monte Carlo Technique

The Monte Carlo Technique
Monte Carlo is a mathematical technique which is based on probability distributions. It
involves multiple iterations, so it is very difficult to calculate without a computer model,
but it can be done. This method usually addresses variables like the estimated total cost of
the project or the estimated completion date of the project.
The answers obtained from the Monte Carlo method give confidence levels on its results,
i.e., “We can say with a 95% confidence level that the project will be completed within
March 15th, or 42 days after its planned completion date.” It can also show what the
probability is of any particular task being along the critical path.
As good as the Monte Carlo method or any of the computer models available are, the
results are only as good as the inputs and the user's interpretation of the outputs. The
answers set ranges; they don't provide accurate absolute results.
There are many online sites that offer sophisticated risk modeling and simulation
software for project management. If you want to further explore this area, I recommend
you look at http://www.palisade.com. This company has a product called @RISK and
you can request a free demo CD which has a trial version on it.
File: Outputs of the Quantitative Risk Analysis

Outputs of the Quantitative Risk Analysis
The outputs of the Quantitative Risk Analysis are:
Risk register updates

Probabilistic analysis of the project, including the probability of achieving cost and time
objectives
Prioritized lists of quantified risks
These will be used in the next step, which is Risk Response Planning.
File: Quantitative Risk Analysis Summary

Quantitative Risk Analysis Summary
Quantitative Risk Analysis is focused on numerical analysis of the probability of
occurrences and the impact of the project risks. This analysis allows the project manager
to determine how much risk a project has and where in the project it is located in order to
decrease the risk, make more informed judgments, determine which risks require a
response or a contingency, deal earlier with the high-risk aspects of the project, and
document the low risks. But this process also requires the use of educated guesses on
probabilities of occurrences and impacts.
Quantitative Risk Analysis helps the project manager identify the most important risks
and the greatest threats to the project. But that is not the most important step - good risk
response planning is. But quantitative risk analysis does provide insight on possible
alternatives and options and a sense of overall risk and opportunity of the project. It also
helps justify setting up contingencies in both the schedule and the budget.
Now, there is one more part of Quantitative Risk Analysis that I need to mention—some
of the mathematical models and computations involve statistics. If this were an in-class
course, I would quiz you about your basic knowledge of statistics and if necessary
(usually!) review basic statistics. I am not going to do that here other than offer a very
simple statement:
Comparing Standard Deviation

The standard deviation is usually the preferred measure of risk, and when comparing
standard deviations—the lower the standard deviation, the lower the risk.
I am not going to make you do moderate statistical calculations like the variance and the
standard deviation. However, the PMI exam has been known to ask questions about the
standard deviation, and it is possible to estimate the standard deviation quite simply for
most basic problems. Vijay has covered this in his book on pages 67 & 68 under the
heading of Statistical Sums. I strongly urge you to review this example on travel times as
it clearly shows what I have also seen referred to as the 1-4-1 method.
PS: If you are completely unfamiliar with standard deviations, you might want to go back
into the Cost book and look at pages 283-285 at the beginning of Chapter 20 for an
example.
File: Risk Response Planning

Risk Response Planning
PMBOK defines Risk Response Planning as the process of developing options and
determining actions to enhance opportunities and reduce threats to the project's
objectives. Also, it takes responsibility for each agreed-to and funded risk response.
The strategies adopted during this phase should be both timely and appropriate for the
levels of severity of the risks or threats. This is an important point: you can't necessarily
just delay the start of a project while you map out all of your planned responses, and you
must keep the financial considerations of your strategies in mind - in other words, if the
planned response costs more than the likely cost of the impact from the risk, you
probably should just accept the risk.
It is also important in the response stage to search out expert opinions on how to deal
with the various risks. Information from prior projects and outside experts like insurance
brokers can often be of assistance. Also, if the stakeholder or the firm the project manager
is employed by has a risk management department, they should be brought in as they may
have solutions or recommendations to some of the issues as well as knowing existing
policies and procedures regarding the management of the project's risks. Involve the
stakeholders in the response strategies.
Often the response plans will break the risks into different categories such as technical
risks, cost risks, schedule risks, cash flow or funding risks, and general risks. In the
response phase, specific personnel are usually assigned to deal with each risk other than
those which will be avoided or accepted.
File: The PMBOK on Risk Response Plans

The PMBOK on Risk Response Plans
PMBOK shows the inputs to the Risk Response Plan, the risk management plan, and the
risk register. The next step, tools and techniques, determines how to deal with each risk.
Choices include:
Some of these choices, such as purchasing insurance, will produce additional costs to the
project and must be included in the project budget. Some of the other choices may result
in additional costs—if they occur. Therefore, you need to factor a contingency budget or
reserve into the project. This budget should be based on numerical possibilities, such as
“$5,000 for a two-week delay due to a strike at a major supplier," or “$10,000 which
covers a 10% increase in raw materials due to anticipated shortages." In real life, people
tend to accept these types of contingencies more readily if they involve metrics rather
than just a general statement such as “we need a 10% contingency reserve fund in case
things go wrong.”
Note: this contingency or budget reserve covers “known unknowns” and is placed in the
project budget and, if it is not used, it goes away at project completion (meaning it’s not a
slush-fund available to cover other items or overages). This is different from the
management reserve which covers “unknown unknowns,” such as category 5 hurricanes,
and needs to be assumed by the stakeholders and budgeted for outside of the project.

Lecture 9 - Summary
For high-risk events, Change. Try and reduce either the probability or the potential
impact.
For medium-risk events, Contain. Concentrate on the potential impact.
For low-risk events, Monitor. Keep an eye on them so they don't develop into a more
serious problem.
Before a threat materializes, try and eliminate it.
Once a threat materializes or continues, use fallback or contingency plans.
For large potential losses, Insure them. For small potential losses, self-insure them.
The outputs of Risk Response Planning include:
Updates to the Risk register

Updates to the Project Management Plan
Risk Prevention plans
Contingency Plans
Contingency and Management reserves
Risk-related contractual agreements
As I stated before, Risk Response Planning (and execution) is one of the most critical
parts of the whole risk management process, and the results can make or break
companies, projects, and careers. Look no further than Hurricane Katrina for examples of
this. Literally all of the problems we have heard discussed on the news relative to
Katrina, New Orleans, the Mayor, the Governor of Louisiana, FEMA, etc. are related to
risk response planning and execution issues, not the other aspects of risk management.
The next lecture will deal with the last aspect of the risk management process, Risk
Monitoring and Control as well as with some miscellaneous risk management issues.

Print Save to File
===============================================================
====================

Printable View of: Lecture 10 - Risk Monitoring and Control
Print Save to File File: Lecture 10 - Risk Monitoring and Control
Lecture 10 - Risk Monitoring and Control


In this lecture we'll review the final step of risk management—Risk Monitoring and
Control. Then we will look at a few other points regarding risk management in project
management.
Risk Monitoring and Control is an ongoing process throughout the life cycle of a project.
It involves monitoring the project’s risk triggers to planned risk responses, but it also
requires continued assessment of new and changing risks. This means monitoring and
controlling is not passive but is an active part of the risk management process.
File: What the PMBOK Says

What the PMBOK Says
Risk Monitoring and Control is defined as the process of:
Identifying, analyzing, and planning for newly arising risks

Keeping track of the identified risks on the watch list
Re-analyzing existing risks
Monitoring trigger conditions for contingency plans
Monitoring residual risks
Reviewing the execution of risk responses while evaluating their effectiveness
Other purposes of Risk Monitoring and Control are to determine if:
Project assumptions are still valid

Assessed risks have changed from their prior states
Proper risk management policies and procedures are being followed
Cost and schedule contingency reserves need to be modified
The the inputs to Risk Monitoring and Control are:
Risk management plan

Updated risk registers
Approved change requests
Work performance information
Performance reports
File: Tools, Techniques, and Outputs
What the PMBOK Says:
Tools, Techniques, and Outputs
The tools and techniques used for Risk Monitoring and Control include:
Risk Reassessments, which should be regularly scheduled and are basically updated
responses to existing risks and identification and response planning for newly identified
risks
Risk Audits, which document responses as well as the overall effectiveness of the risk
management process
Variance and Trend Analyses, such as Earned Value Analysis, which assess the potential
impact of threats or opportunities
Technical Performance Measurement (TPM), and other metrics
Reserve Analysis, which looks at the amounts used and remaining in the cost or schedule
contingency reserves
Project Status Meetings, with risk management on their agenda
The outputs of the Risk Monitoring and Control process are:
Risk Register updates

Requested changes, which become part of the Integrated Change Control process and the
Direct and Management Project Execution process, both which were covered in your AD
642 course
Recommended Corrective Actions, which also affect the two processes mentioned above,
as well as the Monitor and Control Project Work processes
Recommended Preventive Actions, which are used to bring the project into compliance
with the project management plan
Organizational Process Assets updates, which can be used for future projects
The Project Management Plan
As you can see, the outputs of the Risk Monitoring and Control process are ongoing
processes that can impact various aspects of both this project and other projects.
File: Gray and Larson's Approach

Gray and Larson's Approach
Interestingly, Gray and Larson (the authors of your Project Management text) didn't even
address the Risk Monitoring and Control functions as a separate topic; instead they chose
to include them under Risk Response Control (page 225) and Change Control
Management (pages 226-229). Some of the key points of Change Control Management
include project scope changes, implementation of contingency plans, and improvement
changes.
A description of the whole Change Management Process is shown below:
The Change Control process is diagramed in Gray and Larson in Figure 7-8.
The benefits of a Change Control System include:
But remember that the PMP exam is based on the PMBOK.
Note that risk control does not necessarily attempt to eliminate the sources of risks, but
rather to reduce the risk. Some of the possible ways to take risk control actions include:
Alternate designs
Prototyping
Modeling and simulations
Mock-ups
Experiments
Inspections
Use of existing and proven hardware and software
File: Being Proactive
Being Proactive
One of the biggest challenges of dealing with risk events when they occur during a
project is that you are now in a reactive mode instead of a proactive one. Most of the rest
of the risk management process stresses the proactive aspects. In the monitoring and
control stage you often have to manage creatively—like coming up with workarounds.
Remember, the successful implementation of contingency plans can save a project. It's a
critical part of Risk Monitoring and Control.
And the purposes of managing risk and risk response control are also a critical part of the
equation leading to successful projects.
The section on Risk Control in Professor Kanabar's book mentions a few additional
noteworthy topics worth, including the Traffic Light approach (pages 98-99) and the
importance of elevating and communicating risk management issues with stakeholders
and senior management (pages 100-101). The section entitled "The Last Word" has an
excellent summary of the value of risk management summarized for you on the next
page.
File: The Last Word

The Last Word
By Vijay Kanabar
In today’s rapidly changing, increasingly global, business environment, corporations are

faced with new, more challenging opportunities than ever before. With these
opportunities comes risk.
Risk presents tough decisions that could mean the difference between success and failure.
Reengineering and corporate “rightsizing” leave little flexibility when it comes to
managing risk.
These days, it seems, we end up managing one crisis after another. Executives and
managers are charged with managing opportunities (and risks) in spite of dwindling
corporate resources, and face the grim reality that down-sizing and reengineering are far
more often the manifestations of problem management, than proactive business
management.
Today, opportunities are judged more stridently than ever before, and successful
management of these opportunities is valued almost solely on the strength of results—
measurable results. The process by which these results are achieved is an expertise
manager is expected to deliver. The challenge in today’s business climate is simple:
Manage more with less and get the result.
In the last ten years, we’ve all been close to or part of a business down-sizing or
reengineering effort: We’ve pulled back to focus on the core business and divested of
unprofitable ventures. We’ve realigned corporate goals to increase shareholder value, and
we have even outsourced internal functions like human resources administration or
payroll. So what’s left? What will position tomorrow’s market leaders, and how will
today’s leaders hold their competitive edge?
When we consider the broad-based cost of unmanaged risk and lost opportunity—
coupled with thinning human and financial resources—crisis management or fix-on-
failure is not an option. The solution for today’s business leaders is clear: Manage your
risk. Innovative tools and creative solutions are needed to do this.
Companies able to proactively identify and manage risk will have a significant
competitive advantage in the marketplace. When risk management is properly understood
—and practiced—those who use it can manipulate their business environment to their
advantage and position themselves as market leaders. It’s that simple, and it’s that
challenging.
The diagram below illustrates why it is strategically important to understand your risk
position as early as possible.
In contrast, risk management directly impacts the future effects of current decisions by
addressing risks in the decision-making environment. Project teams learn to identify
risks, analyze their choices and make consistent decisions based upon the overall
objectives of the enterprise as well as the task at hand. Managing risks becomes an
indispensable part of every-day workflow, a step in the enterprise’s critical path. Risk
management is the long, hard look before we leap.
It has been estimated that problem management consumes over 30% of our resources.
The “clean up” effort. To counter this reality, the deployment of a risk management
system is designed to:
Take a disciplined approach to decision making throughout the ranks of an organization,

deliberately and continuously re-focusing and realigning the strategic direction of the
company.
Communicate risks clearly and effectively across organizations and throughout the
enterprise with a common “risk vocabulary.”
Provide a repeatable process for analyzing risks that balances well with the strategic
direction of the company, well beyond typical cost-benefit analysis, to decide whether or
not to launch a project.
Free up precious resources. If you frequently find your staff in crisis or problem
management, you have less time and resources available to take on additional
opportunities.
Identify new opportunities and ensure the risk is commensurate with rewards. Also, if
you choose an opportunity with high risk and high return, your chances of success are
greatly enhanced using a risk system.
Utilize organizational strengths for identifying and managing risks, rather than relying on
individual heroics to rescue a project or program.
Eliminate the root causes of risk. While we can never eliminate risk itself, persistent
attention to the causes of risk can help surface the underlying roots that create it.
Help you out-manage your competition. With a risk management system in place, you
will have a strategic advantage over organizations that insist on remaining in crisis
management or fix-on-failure.
Many companies are discovering risk management as a means to effectively manage
business in a rapidly changing environment. Where there is change, there is significant
opportunity and risk.
Your Investment in Risk Management

Your investment in risk management (typically 2-4% of your project costs) compares
favorably with cost overruns and lost opportunity costs, which often reach more than
50%. So, while the investment in risk management is comparatively small, the potential
gains are enormous.

Lecture 10 - Summary
In summary, there are many benefits from performing good risk management on a
project.
Risk management has often been viewed as a "Nice to have (but not essential)" of project
management. In reality, assessing and planning for risk is one of the most important
aspects of project management. To be successful in project management you need to
master the risk management process by leading your team(s) through a risk assessment
and applying those results in your project plan and schedule. During execution and
monitoring you will need to check in with your risk owners and track and control changes
so that the realized risk prompts the appropriate risk response.
Luck always favors the prepared—and being prepared means implementing risk
management methodology best practices and developing the necessary skills a buy-in so
you can assist your team!
Few projects, if any, go exactly according to plan. The risk management process does
require some time and effort, and requires contingency planning. However, the risk
assessment process provides your team with the opportunity to voice their concerns and
provides a realistic response to possible events. General Dwight D. Eisenhower said, " In
preparing for battle I have always found that plans are useless, but planning is
indispensable." One should interpret this to mean,
Because all management is really risk management.
This completes our review of risk management for project management. Next week we
will move on to Continuity, which is contract management and procurement.

Print Save to File
================================================

Printable View of: Lecture 11 - Continuity Management
Print Save to File File: LECTURE 11 - Continuity Management
Lecture 11 - Continuity Management
Reading: Emerson, Chapters 4-9 (pages 75 through 175)
Now we start the last part of the course, labeled continuity management, which
encompasses procurement and contracts – specifically, the various types and the possible
risks associated with them. This lecture will deal with contracts themselves and will offer
an overview of procurement. The next lecture will deal with the various types of contracts
and their risks as well as some miscellaneous areas.
But I am going to approach this lecture much differently from the preceding ones. In
almost 30 years of teaching graduate business and project management courses I have
learned that unless you are an attorney or you have an undergraduate degree in business,
you probably never had a business law course. Therefore, your real knowledge of
contracts is very limited.
So, my approach is to first review the basics of contracts in our legal environment, as you
need an understanding of the risks, limitations, and possible consequences of entering
into contracts. Failure on your part to understand contracts can be very costly, and may
delay or destroy otherwise good projects.
File: Basic Information

Basic Information
I am not an attorney, therefore, I'm not going to teach you business law. But I can direct
you to sources which provide some good, basic information regarding contracts, and that
is why I assigned you the reading of chapters 4-9, pages 75-175 of the Barron's Business
Law book. It provides a very good overview of contracts and is well worth reading—
even if you think you are somewhat experienced in this area. I will review some of the
key points of the chapters, but leave most of the details and definitions for you to review.
In the real world, you must function as a project manager in the environment you happen
to be in—whether you are employed by a large multinational firm, a contractor, a
governmental entity, or whatever. Entering into contracts, especially complex ones can be
very tricky. In some business environments, you will be mandated to submit all potential
contracts through either an internal legal department or through an outside legal council
for review and approval. This may also happen through procurement policies and
procedures, which we will address later.
In any case, I strongly recommend that you take advantage of any legal review or advice
you can obtain before entering into contracts—especially large ones, or ones involving
new technology or custom-designed and hand-made items. Always think about “what
could go wrong” (Risk Management) and how deeply it could affect the project in terms
of cost, delays, or even cancellation. The more risk you perceive, the more important a
legal review is upfront.
File: Contracts
Contracts
OK - Let’s look at Chapter 4 - Nature, Classification, and Formation of Contracts.
So What is a Contract?
It is a legally enforceable agreement, either expressed or implied.
There are four essential elements required for a contract to be valid:
For contracts to be valid, there must be an offer and an acceptance. The acceptance is
unconditional because if it were conditional, it would be a counteroffer—which then
needs to be accepted unconditionally by the other party.
There is a Statute of Limitations, which is usually three to six years, depending on the
state in which the contract is executed; the exception to this is sales contracts, which are
covered under the Uniform Commercial Code (UCC) and are limited to a four-year
period.
File: Mistakes and Fraud
What a Contract Is:
Mistakes and Fraud
Chapter 5, Reality of the Contract, deals with mistakes and fraud. In order to obtain a
finding of fraud, there are five elements, all of which must be present:
Misrepresentation of a material fact

Made knowingly
With intent to defraud
Justifiability relied upon
Causing injury to the other party
Fraud is both a tort, leading to a civil finding (monetary damages) and a crime, leading to
criminal actions including jail and fines. Also, if the fraud is aggravated or malicious, it
can lead to punitive damages which may be up to triple the amount of the actual
damages. If fraud can be proven in a court of law, the defrauded party can either rescind
the contract or affirm the contract and bring legal actions to recover damages.
Contracts entered into under coercion, duress, or undue influence, or unconscionably

[Well, this is better than “under unconscionability,” but I am at a complete loss as to what
he is actually trying to say here], may be voided by the victim.
File: Other Aspects

What a Contract Is:
Other Aspects
Chapter 6, Capacity of the Parties and Legality of the Subject Matter, deals with who can
legally enter into a contract and when a contract can't legally even exist because of its
subject matter. This includes agreements that violate state and federal statutes and public
policy.
Chapter 7 covers the Statute of Frauds, which basically says that certain agreements must
be in writing, or at least have some written evidence of the agreement.
In the case of the UCC, all sales contracts for a price of $500 or more must be in writing.
As laws from the various states are different, many contracts and legal documents contain
a clause that the UCC shall govern the particular agreement.
The chapter also discusses the Parol Evidence rule (which prohibits any outside
information which contradicts a written agreement), the Privity Doctrine (must be party
to a contract), and Assignments of Rights. It is important to understand that the rights and
duties contained in a contract may be assigned to third parties (such as subcontractors)
unless assignment is prohibited in the contract.
Chapter 8 covers Discharge, Damages, and Other Remedies. A contract is automatically

discharged, or terminated, by successful performance. Additionally, contracts may be
terminated by breach, mutual rescission, release, payment in full, and operations of the
law.
However, if a contract is breached, damages may ensue; damages refer to the

compensation due to the non-breaching party to recover any financial loss incurred or
injury caused by the breach of the contract. There are both compensatory and punitive
damages; punitive damages are only available if there was fraud or gross negligence.
Additionally, parties to a contract may seek specific permission to compel the other party
to complete the contract, or parties may seek injunctions to prohibit actions which may
lead to a breach of contract.
Chapter 9 deals with Special Problems Concerning Sales Contracts and gets into Article 2
of the UCC, which basically sets higher standards of conduct for merchants. International
sales contracts may be governed by the Convention on Contracts for the International
Sale of Goods (CISG) if both countries involved in the transaction have ratified the CIGS
agreement. Seeing that more than one set of rules or laws may apply to a sales
transaction, the contract should clearly state which set of rules and laws govern the
transaction.
The chapter also discusses non-sales transactions (bailment, lease, and gift), shipper's
contracts, title to the goods, and buyer's and seller's remedies.
File: Other Aspects (Continued)

What a Contract Is:
Other Aspects (Continued)
For our purposes, I assigned only the above six chapters for this course. However, there
are other parts of the book which may be of interest to you, including the Commercial
Relations section (Chapters 10-13), Chapter 16 on corporate powers, Chapter 19 on torts,
and Chapter 24 on employment law. Some of you might want to eventually review the
whole book.
But what you will really gain from the book and our discussion is the importance of
knowing when you need to know about the law and its possible consequences—which is
usually before you get into trouble! Don't be afraid to seek out legal advice when you
think it may be necessary, especially regarding contracts.
In the United States, I believe we have both the most lawyers per capita and over three
times the number of lawyers per capita as the next closest developed country. Our motto
seems to be that anyone can sue anyone at any time for any reason—and even win! Also,
there is something called the deep pockets effect, which can cause you to have to pay
damages just because a jury feels sorry for the other party and thinks that because you
may be a large and successful company or individual, you can afford to pay the other
party.
Remember, with contracts, it's better to be safe than sorry!
File: Procurement
Procurement
The other issue I want to discuss now is the procurement function in general.
When you leave work and you are hungry you have many choices: you could stop at a
grocery store and shop for supper or you could eat out—at a fancy restaurant or a fast-
food joint. And you can pay by check or debit or credit card. However, even though you
may be the Project Manager at work, you may not always have the ability or the authority
to make such choices. You must function in your business environment and part of that
environment involves learning the procurement policies and procedures (and related
payment policies and procedures) of your employer, the stakeholders, and other parties
involved in the project. You cannot successfully operate in a vacuum.
Procurement management includes the processes which manage the acquisition of

products and services, both internally and externally, for the project, including any related
contract management functions. Procurement management includes the decisions on such
things as make or buy decisions and the actual processes of going about acquiring
resources for the project. The procurement management function usually includes:
planning
bidding
selecting vendors
administering the process
closing out the procurement process
If you are the Project Manager for a company, the company usually has in place some
overall policies and procedures. In addition, there already will be established levels of
authority stating who within the company can commit the company to purchases or
contracts, who can approve or recommend such purchases or contracts up to certain
dollar amounts, and who has the authority to authorize what amount of payments and
under what terms. You, as a company employee, must learn these company policies and
procedures and integrate your project as such. If you are new to a company, this is one of
the first areas you want to become familiar so there won't be any delays or problems with
your project that could have been avoided.
File: Policies
Procurement:
Policies
In addition to getting to know your “boss” on a project, you may want to seek out the
Purchasing Manager and the Accounts Payable Manager (or whatever functional titles
these positions have) and learn the policies, procedures, guidelines, and rules you have to
live with. Some of these might include:
Preferred vendors: vendors you have to use because of special pricing or previous
performance history
Payment terms: if the company's policy is to always pay in 30 days, you can't commit to
payment in 10 days
Approval levels: your Corporate Board of Directors may set certain authorization levels
as to what dollar amounts certain corporate officers or employees may authorize
Paperwork requirements: companies develop internal control systems to both protect and
monitor the use of company assets, including the purchasing and payment functions
If you are involved as a Project Manager for a contractor, or you are in a situation where
there are partners or multiple parties involved in the project, the above issues can become
even more complex. The procurement, purchasing, and payment functions,
responsibilities, duties, and authority levels must be worked out in advance with the
stakeholders and all of the parties involved. Again, “chain of command” issues need to be
resolved before there are problems or power struggles.
Next lecture we will deal with the use of various types of contracts which can be used to
manage risk, as well as addressing some closing points on continuity, risk management,
and the course in general.

Print Save to File
======================================================

Printable View of: Lecture 12 - Project Procurement Management
Print Save to File File: LECTURE 12 - Project Procurement Management
Lecture 12 - Project Procurement Management
Reading: PMBOK, Chapter 12
►Important Notice for Week 7: Since the Final Exam is a closed-book format; the lecture
content of this course will be unaccessible during the exam period.
This is the final portion of lecture for the course will deal mainly with the PMBOK views
of Project Procurement Management. For those of you who are familiar with the older
version of the PMBOK, the process steps are very similar but there have been some
major terminology changes. Words like “procure,” “solicit,” and “solicitation” have been
removed because they may have negative connotations in various areas of the world.
Also, the new PMBOK differentiates the project team as a potential “buyer” of goods and
services versus being a “seller” of goods and services. Contract administration has also
been expanded to include a process on seller performance evaluation.
PMBOK defines Project Procurement Management as the process used to purchase or

acquire the products, services, or results needed from outside the project team to perform
the work. It goes further to include that the organization can be either the buyer or seller
of the product, service, or results under contract. It also includes contract administration.
File: Project Processes

Project Processes
There are six parts to the Project Procurement Process, which are shown on page 273 of
the PMBOK.
These processes interact with each other throughout the project, as well as with many of
the processes in the other Knowledge Areas. Let's look at these six parts.
Plan Purchases and Acquisitions

This is the first step of the Project Procurement Process and it identifies which products
and services are needed from outside of the project organization.
Plan Purchases and Acquisitions Inputs include:
Enterprise environmental factors

Organizational process assets
Project scope statement
Work breakdown structure
WBS dictionary
The Project Management Plan, including the risk register, risk-related contractual
agreements, resource requirements, Project schedule, activity cost estimates, and the cost
baseline
The Plan Purchases and Acquisitions tools and techniques include:
Make-or-buy analysis (which we covered in the cost portion of the course)

Expert judgment
Contract types (which we will look at in detail a little later as this is the really important
part of this topic)
The outputs of the Plan Purchases and Acquisitions include:
Procurement management plan

Contract statement of work
Make-or-changes
Plan Contracting
The second phase of the Project Procurement Process is the Plan Contracting.
The Plan Contracting Inputs include:

Contract statement of work
Make-or-buy decisions
The Project Management Plan, including the risk register, risk-related contractual
agreements, activity resource requirements, project schedule, activity cost estimates, and
the cost baseline
The Plan Contracting tools and techniques include:
Standard forms, which include items like standard contracts, non-disclosure agreements,
criteria checklists, etc.
Expert judgment
The Plan Contracting outputs include:
Procurement documents
Evaluation criteria
Contract statement of work updates
File: Request Seller Responses

Project Processes:
Request Seller Responses
The third step of the Project Procurement Process is Request Seller Responses, which is
the bidding and proposal process.
The inputs to the Request Seller Response include:

Procurement documents
The Request Seller Responses tools and techniques include:
Bidder conferences
Advertising
Qualified sellers' list
Contract Statement of Work (SOW). This tool describes in detail the actual goods or
services to be included in the contract, thus allowing all bidders to bid accordingly.
The outputs of Request Seller Responses include:

Procurement document package
Proposals
Select Sellers
The fourth part of the Project Procurement Process is Select Sellers, or the action or
decision-making phase.
Select Sellers inputs include:

Evaluation criteria
Procurement document package
Proposals
Project management plan
The Select Sellers tools and techniques include:
Weighting systems
Interdependent estimates
Screening system
Contract negotiation
Seller rating system
Expert judgment
Proposal evaluation techniques
The Select Sellers outputs include:
Selected sellers
Contract(s)
Contract management plan
Resource availability
Procurement management plan updates
Requested changes
File: Contract Administration
Project Processes:
Contract Administration
The fifth part of the Project Procurement Process is Contract Administration. It should be
noted that in many large organizations or in complex projects, the Contract
Administration function may be handled by a separate department outside of the project
team. However, the project manager will still have interface and oversight responsibilities
involving the contract administration.
Contract Administration inputs include:
Contract(s)
Contract management plan
Selected sellers
Performance reports
Approved change requests
Work performance information
Contract Administration tools and techniques include:
Contract change control system

Buyer-conducted performance review
Inspections and audits
Performance reporting
Payment systems
Claims administration
Records management system
Information technology
Contract Administration outputs include:
Control documentation
Requested changes
Recommended corrective action
Organizational process assets updates, including correspondence, payment schedules and
requests, and seller performance evaluation documentation
Project management plan updates, including the procurement management plan and the
contract management plan
File: Contract Closure

Project Processes:
Contract Closure
The sixth and final step in the Project Procurement Process is Contract Closure, which
supports the Close Project process.
Contract Closure inputs include:

Procurement management plans
Contract management plans
Contract documentation
Contract closure procedure
Contract Closure tools and techniques include:
Procurements audits
Records management systems
Contract Closure outputs include:
Closed contracts
Organizational process assets updates, including Contract files, Deliverable acceptance,
and Lessons Learned documentation
File: What This All Means

What This All Means
Project Processes:
What This All Means
Now, have you got all that memorized? Well, you really don't have to. As I stated earlier,
the Procurement Management Processes not only interact with each other throughout the
project, but they also interact with other Project Management Knowledge areas
throughout the project. Consequently it appears that there are a lot of inputs and outputs
to the Procurement Management Process steps.
If you step back and look at them again, you'll find that most of them are very logical.
File: Types of Contracts

Types of Contracts
Now, let's go back and look at some of the different types of contracts. There is a strong
correlation between risks and contracts; certain types of contracts can be used as a risk
reduction tool. Or one can add various terms and conditions to contracts to make them
less risky. In fact, you could even contractually outsource potentially high risk aspects of
a project.
In any contractual arrangement, there is always risk present. The real question is who
becomes responsible for what aspects of the risk through the terms of the contract. I am
going to use the terms “buyer” and "seller" to discuss the contracts: the company doing
the project is the "buyer" and the other party to the contract, the contractor, is the "seller."
First, let's look at the two extremes: Fixed-Price (sometimes also referred to as firm fixed
price or lump sum) versus Cost-Plus (sometimes referred to as time and materials). We'll
also look at the key elements of a contract, which usually contain the risks; these
typically involve three areas—costs, time, and satisfactory performance.
File: Fixed-Price and Cost-Plus
Types of Contracts:
Fixed-Price
Fixed-Price contracts typically involve an agreed-upon price, delivery or completion date,
and a stated or assumed level of quality or performance. Once the contract is executed,
basically all of the risks are on the seller. These types of contracts usually work best when
the products are commodity-like, or are well-defined parts or components. The
advantages of fixed-price for the buyer are that they know what the cost will be, when to
reasonably expect delivery and what the expected performance or quality will be. The
disadvantages to the buyer may include not being able to request changes or
customization once the contract is signed (as there are no incentives for the seller to
agree). In this type of contract the seller basically keeps all of the risks; the seller has
already agreed to all of the terms, so he has to deliver. If things like increases in raw
material prices, higher energy and delivery costs, or poor estimating on his part, affect the
contract, the seller has to eat any resulting costs and either make a lower profit or even
incur a loss. Fixed-Price contracts are usually easy to bid, and consequently, bidders who
really want the job know that they have to make a reasonably low bid to be considered
for it.
Cost-Plus
At the other end of the spectrum is the Cost-Plus contract. Under a full Cost-Plus
contract, the seller is reimbursed for all direct allowable costs incurred, and usually an
additional percentage of these costs which covers the overhead, or indirect costs, and the
profit. In this arrangement, the buyer basically assumes all of the risks. If the project
takes longer or goes over budget, it is the buyer's problem. There is no particular
incentive for the seller to reduce the costs other than possibly his reputation.
There are basically 3 types of cost reimbursement or Cost-Plus fee (CPF) contracts:
Cost-Plus a percentage of cost (CPPC)

Cost-Plus a fixed fee (CPFF)
Cost-Plus incentive fees, if earned (CPIF)
File: Modifications
Types of Contracts:
Modifications
Note: we can modify both of these types of contracts by adding additional terms and
conditions, such as penalties and incentives, which will transfer part of the risk to the
other party.
For example, we could take a Fixed-Price contract and add an incentive bonus to it if the
seller delivers either early or on time, or if the quality or performance exceeds
specifications. We could also tag penalties onto a Fixed-Price contract if the seller is late
or if there are quality or performance issues.
With Cost-Plus contracts we could make them Cost-Plus-Fixed Fee, meaning we

reimburse the seller for all direct costs, but pay a flat fee instead of a percentage to cover
his indirect costs and profit. We could also make them Cost-Plus-Incentive - Fee, where
the fee would vary depending on the delivery, quality, performance, and cost criteria of
the contracted item.
Notice that all of these modifications to the contracts result in some manner of sharing
the risks, as well as the potential opportunities of the situation. At the very center of such
a sharing situation is the concept of forming a joint venture to share equally in all of the
risks and opportunities.
A few other ways that these contracts may be modified include:
Guaranteed maximum and minimum fees

Shared savings
Redetermination (after the fact adjustments)
Economic price adjustments
Incentive targets
Profit ceilings or floors
Warranties and guarantees
File: An Additional Point

Types of Contracts:
An Additional Point
One additional point about these contracts. All of the above examples and discussions
apply to the most common type of contract, which is often referred to as a completion
contract because there is a definitive delivery or end to the contract.
Another type of contract, which is often referred to as a term contract, is one that is
required to deliver a specific level of effort, not an actual end product.
With Fixed-Price contracts, sellers assume all of the risks; therefore, it is only reasonable
that they should be compensated for these risks and earn a higher comparable profit than
with other types of contracts. Conversely, with Cost-Plus contracts, buyers assume all of
the risks; therefore they will expect the seller to work for a lower potential profit. All of
the other types of contracts, with their various risk sharing arrangements should
theoretically move the buyer's costs and the seller's profits accordingly.
In Vijay's Risk Management book, he showed the following chart which pretty well
defines the contract/risk tradeoffs:
So you have many choices on how to potentially structure contractual relationships
depending on the aspects of the project and the importance of the risk characteristics of
cost, time, quality, and/or performance. Also, if the project situation is reversed and you
are the seller, remember that the customer, or buyer, is a stakeholder and may want to
work with you contractually on risk transfer or risk sharing.
File: Common Terms

Types of Contracts:
Common Terms
As there is no actual textbook on the procurement section of this course, I've included
below a list of common terms and their basic definitions, related to contracts and
procurement:
File: Course Summary

Course Summary
In this course, we dealt with the quantitative and qualitative aspects of the decision-
making that goes into project management. However, no matter how well a project is
planned, how it is executed can be an entirely different story.
In times of crisis, uncertainty, and adverse conditions, the stakeholders and the project
team look to the Project Manager to provide stability and good decision-making to put or
keep the project on track. Solid cost management, risk management, and procurement
management skills have elevated an average Project Manager into a great Project
Manager. I hope some of this course will help you become one.
Good Luck!
Please click the play button to hear some parting comments from Larry Watson.

Print Save to File

JISA Final Lectures

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

JISA Final Lectures

Încărcat de

Drepturi de autor:

Formate disponibile

Jump to Navigation Frame Jump to Content Frame

Printable View of: Lecture 7 - Introduction to Risk Management

Assignment and Discussion Schedule

Before beginning this lecture, please watch this

Click on the play button to start the video.

Risk Management Planning

Project Risk Management, A Step-by-Step Guide to Reducing Project Risk by Vijay

File: Fundamentals of Risk Management

What is the Difference between “Risk” and “Uncertainty”?

But there is more to the risk than financial consequences.

File: A Closer Look at Risk Management

File: Understanding Probability and Impact

File: The Status of Risk Management

Government intervention in areas like workers' compensation, safety (OSHA), product

Risk management is everywhere.

File: Risk Management from a Project Management Perspective

Enterprise Environmental Factors

File: What to Consider with Risk Management

Looking at organizational process assets, it is a must to know the roles, responsibilities,

the overall behavioral environment of the organization (including organizational risks

File: Good Risk Management Planning

In an article in the September 2005 issue of PM Network, the professional magazine of

File: Lecture 7 - Summary

Assignment and Discussion Schedule

To submit assignments and participate in discussions, click on the appropriate icon on

Reading: Kanabar, Chapters 1-6

Assignment and Discussion Schedule

Before beginning this lecture, please watch this

Click on the play button to start the video.

Enterprise Environmental Factors, which would include published information from

File: Risk Categories

File: Risk Identification Summary

File: Qualitative Risk Analysis

Organization Process Assets (lessons learned)

Risk Probability and Impact Assessment, which use expert judgments

File: Applying Numbers

Following agreement on defined ranges you can do two things:

File: A Few Additional Points

File: Probability and Impact Matrix

File: Lecture 8 - Summary

Assignment and Discussion Schedule

To submit assignments and participate in discussions, click on the appropriate icon on

Print Save to File

Jump to Navigation Frame Jump to Content Frame

Reading: Kanabar, Chapters 1-6

Assignment and Discussion Schedule

Before beginning this lecture, please watch this

Click on the play button to start the video.

File: What the PMBOK Says

Organization Process Assets

Data gathering and representation techniques

And there is also the use of expert judgments.

File: Modeling Techniques

File: Calculating Expected Value

An additional point about risky projects. Companies have many opportunities to do

File: The Monte Carlo Technique

File: Outputs of the Quantitative Risk Analysis

Risk register updates

File: Quantitative Risk Analysis Summary

Comparing Standard Deviation

File: Risk Response Planning

File: The PMBOK on Risk Response Plans

File: Lecture 9 - Summary

Updates to the Risk register