The ITP-3 – Project Risk Assessment is due as shown in the schedule. The assignment instructions are attached. Use the weekly readings to understand the concepts and what is required for the assignment. I NEED THIS DONE WITH IN 12 HOURS. Much have a degree in Computer Science 

Example Risk Register

Example Risk Register.xlsx |

WBS

1 2014-04-29, 17:19

WBS_ID Task Task Level Risk

Risk Category

(Type)
Risk

Probability

Risk
Consequenc
es (Impact)

Initial Risk
Score

(Probabil. *
Impact)

Risk
Handling
Category Risk Handling/Control Plan

Risk
Owner
(Risk

Manager)

0
SERVER AND SYSTEM UPGRADE
PROJECT

0 Project funding not obtained

External,
Financial

25% $500,000 $125,000 Accept Cancel the project

PM

0
SERVER AND SYSTEM UPGRADE
PROJECT

0 Project funds cut

External,
Financial

50% $250,000 $125,000 Mitigate
Re-plan the project with reduced
scope

PM
0
SERVER AND SYSTEM UPGRADE
PROJECT

0 Lack of client or sponsor support External 33% $250,000 $82,500

Accept

If it happens, it happens. Deal
with it.

PM

:
:

1 INITIATE PROJECT (phase 1)
1.1 Analyze requirements

1.1.1
Contact customer – Start project
initiation

3
Customer non-responsive or schedule
conflicts

External 10% $10,000 $1,000 Mitigate
Keep trying to arrange acceptable
schedule.

PM

1.1.2 Manage project initiation

1.1.3 Engage customer 3
Customer non-responsive or schedule
conflicts

External 15% $10,000 $1,500 Mitigate
Keep trying to arrange acceptable
schedule.

PM

1.1.3.1 Conduct initial requirements analysis 4 Requirements scope exceeds budget

External,
Financial

10% $50,000 $5,000 Mitigate
Re-plan project for reduced
scope.

PM

1.1.3.2 Review concept of operations (if any)

1.1.4
Establish integrated cost estimating
team

3
Participants non-responsive or
schedule conflicts or unable to obtain
expertise

External 25% $50,000 $12,500 Mitigate
Keep trying to arrange acceptable
schedule.

PM

1.1.5 Conduct joint analysis (a’la JAD) 3
Participants non-responsive or
schedule conflicts

External 50% $10,000 $5,000 Mitigate
Keep trying to arrange acceptable
schedule.

PM

1.1.5.1 Generate cost estimate 4 Cost estimate exceeds project budget Financial 10% $50,000 $5,000 Mitigate
Re-plan project for reduced
scope.

PM
:
:

4.3.2 Develop system

4.3.2.1 Precure servers 4 Servers delayed in shipment External 10% $10,000 $1,000 Transfer Insure the shipment
Chief

engineer

4.3.2.2 Procure/build network 4 Technical difficulties building network Technical 10% $25,000 $2,500 Mitigate
Bring in technical experts to
assist; delay project if necessary

Chief
engineer

4.3.2.3 Procure/build databases 4 Technical difficulties buildind databse Technical 10% $10,000 $1,000 Mitigate
Bring in technical experts to
assist; delay project if necessary

DBA

:
:

Example Risk Register (Partial)

Example Risk Register

Example Risk Register.xlsx | WBS 2 2014-04-29, 17:19

WBS_ID Task Task Level Risk
0
SERVER AND SYSTEM UPGRADE
PROJECT
0 Project funding not obtained
0
SERVER AND SYSTEM UPGRADE
PROJECT
0 Project funds cut
0
SERVER AND SYSTEM UPGRADE
PROJECT

0 Lack of client or sponsor support

:
:
1 INITIATE PROJECT (phase 1)
1.1 Analyze requirements
1.1.1
Contact customer – Start project
initiation
3
Customer non-responsive or schedule
conflicts
1.1.2 Manage project initiation
1.1.3 Engage customer 3
Customer non-responsive or schedule
conflicts
1.1.3.1 Conduct initial requirements analysis 4 Requirements scope exceeds budget
1.1.3.2 Review concept of operations (if any)
1.1.4
Establish integrated cost estimating
team
3
Participants non-responsive or
schedule conflicts or unable to obtain
expertise
1.1.5 Conduct joint analysis (a’la JAD) 3
Participants non-responsive or
schedule conflicts

1.1.5.1 Generate cost estimate 4 Cost estimate exceeds project budget

:
:
4.3.2 Develop system

4.3.2.1 Precure servers 4 Servers delayed in shipment

4.3.2.2 Procure/build network 4 Technical difficulties building network

4.3.2.3 Procure/build databases 4 Technical difficulties buildind databse

:
:

Example Risk Register (Partial)

Est. Cost of
Mitigation

Remaining
Probability

after
Mitigation

Remaining
Consequences
(Impact) after

Handling
Final Risk

Score
Current Risk

Status Notes and discussion

13% $250,000 $31,250

$31,250 25% $125,000 $31,250

17% $125,000 $20,625

$250 5% $5,000 $250

$375 8% $5,000 $375

$1,250 5% $25,000 $1,250

$3,125 13% $25,000 $3,125

$1,250 25% $5,000 $1,250

$1,250 5% $25,000 $1,250

$100 5% $5,000 $250

$625 5% $12,500 $625

$250 5% $5,000 $250

Example Risk Register

Example Risk Register.xlsx | WBS 3 2014-04-29, 17:19

WBS_ID Task Task Level Risk
Risk Category

(Type)
Risk
Probability
Risk
Consequenc
es (Impact)
Initial Risk
Score
(Probabil. *
Impact)
Risk
Handling
Category Risk Handling/Control Plan
Risk
Owner
(Risk
Manager)
Example Risk Register (Partial)

4.4.2.7
Prepare developomental testing
report

4 Report preparation delayed PM 5% $5,000 $250 Mitigate
Bring in additional tech writers to
assist

Tech
writing

:
:

5.1.6
Obtain initial operational testing
approval (user acceptance)

3 Client does not accept system External 5% $500,000 $25,000
Mitigate or

Accept

Depending on severity, either
send back to developers for
correction or cancel project

Chief
engineer

or PM

:
:

5.2 Software Development 2 Development schedule delays 25% $41,667 $10,417 Mitigate Add additional programmers
Chief

engineer
or PM

5.2 Software Development 2 Development cost overrun 25% $50,000 $12,500 Mitigate Renegotiate scope
Chief

engineer
or PM

5.2 Software Development 2
Quality issues due to inexperienced
programmers

12% $30,000 $3,600 Mitigate :
Chief

engineer

5.2 Software Development 2
Unclear or incomplete requirements
result in need to scrap and re-start
devleopment of selected modules

10% $50,000 $5,000 Accept etc :

5.2 Software Development 2
Incorrect requirements result in need
to scrap and re-start devleopment of
selected modules

10% $150,000 $15,000 Accept : :

:
:

6
System Initiation, Implementation &
Fielding

6.1 Initital Training 2
Scheduling issues with customer
personnel

40% $30,000 $12,000 Accept

6.2 System Integration, Site Test/Accept 2
Customer does not accept product,
requires rework

10% $500,000 $50,000 Accept

:
:

… etc, etc …

Total at risk:
Likely loss

due to risk:

Example Risk Register

Example Risk Register.xlsx | WBS 4 2014-04-29, 17:19

WBS_ID Task Task Level Risk

Example Risk Register (Partial)
4.4.2.7
Prepare developomental testing
report

4 Report preparation delayed

:
:
5.1.6
Obtain initial operational testing
approval (user acceptance)

3 Client does not accept system

:
:

5.2 Software Development 2 Development schedule delays

5.2 Software Development 2 Development cost overrun

5.2 Software Development 2
Quality issues due to inexperienced
programmers
5.2 Software Development 2
Unclear or incomplete requirements
result in need to scrap and re-start
devleopment of selected modules
5.2 Software Development 2
Incorrect requirements result in need
to scrap and re-start devleopment of
selected modules
:
:
6
System Initiation, Implementation &
Fielding
6.1 Initital Training 2
Scheduling issues with customer
personnel
6.2 System Integration, Site Test/Accept 2
Customer does not accept product,
requires rework
:
:
… etc, etc …
Est. Cost of
Mitigation
Remaining
Probability
after
Mitigation
Remaining
Consequences
(Impact) after
Handling
Final Risk
Score
Current Risk
Status Notes and discussion

$63 3% $2,500 $63

$6,250 3% $250,000 $6,250

$2,604 13% $20,833

$3,125 13% $25,000

$900 6% $15,000

5% $25,000

5% $75,000

20% $15,000

5% $250,000

Total cost of
mitigation:

Likely
remaining
loss after

mitigation: Savings due to risk management:

Example Risk Register

Example Risk Register.xlsx | WBS 5 2014-04-29, 17:19

WBS_ID Task Task Level Risk
Risk Category
(Type)
Risk
Probability
Risk
Consequenc
es (Impact)
Initial Risk
Score
(Probabil. *
Impact)
Risk
Handling
Category Risk Handling/Control Plan
Risk
Owner
(Risk
Manager)
Example Risk Register (Partial)

$1,730,000 $392,250

23%

of cost at risk

Example Risk Register

Example Risk Register.xlsx | WBS 6 2014-04-29, 17:19

WBS_ID Task Task Level Risk

Example Risk Register (Partial)
Est. Cost of
Mitigation

Remaining
Probability
after
Mitigation
Remaining
Consequences
(Impact) after
Handling
Final Risk
Score
Current Risk
Status Notes and discussion

$46,038 $865,000 $98,063 $248,150

3% 50% 6% 14%

of cost at risk of cost at risk of cost at risk
of cost at risk

WBS

ITP-3Project Risk Assessment (Individual project)

Please be sure to read the Team Contribution Assessment and Grading of Team Assignments and the
Project Documentation Requirements sections of the ITP Master Document.

Assignment for the ITP-3 Project Deliverables

This assignment is an INDIVIDUAL assignment. Review your previous deliverable assignments and the
assignments that other teams have posted in the Shared Learning Environment Discussions.

This assignment has two parts.

Part 1. Risk Register in Excel

Using your team’s TTP-4 WBS, develop and submit a project risk register in MS Excel:

• A project risk register, from the textbook, from the classroom material, from www.pmi.org, or
from other valid research, that meets the following requirements.

• In MS Excel, the risk register should be populated with the risks for at least 3 tasks (including
Summary Tasks) of different types and categories at each level of decomposition in the WBS. No
fewer than 12 risks must be identified.

• Risks may include, for example, technical IT risks, external risks that impact the project but
which are outside the PM’s control, project management risks, risks of project changes, and so
forth.

• Please note that a task could have more than one risk! The risk register must include mitigation
strategies to avoid, eliminate or minimize the risk and contingency plans (what you will do if the
risk happens). If the format you are using does not include these columns, please add them. Be
sure you are clear on the difference between mitigation and contingency. Address what aspect
of the project will be affected by each mitigation action – cost, schedule, or scope. Provide a
recommendation for whether or not the mitigation action should be implemented,
remembering that each mitigation will impact the project’s scope, cost or schedule.

The risk register should also include:

• Title or description of item or task at risk (this is the WBS task in which the risk occurs, not the
risk itself).

• Also include the WBS ID and a designation of which WBS level the task is at. Each risk in the Risk
Register should show the WBS level of the task that it refers to. The WBS numbering must come
from Project (Add New Column -> WBS will reveal the WBS numbers).

• Description of the risk (What is the risk? What is at risk of happening?). Identify the nature of
the risk itself, not the task.

• Risk category or type (e.g., technical risks, quality risks, financial risks, external risks,
organization risks, project risks, quality risks, other risks, etc.)

• Consequences, impact, or cost at risk (adjectival or numeric)

• Likelihood or probability (adjectival or numeric)

• Initial risk score (or “risk product”, consequence times likelihood)

• Risk handling category (avoidance, mitigation, transfer, acceptance, etc.)

• The mitigation action that, if taken, would avoid the risk or the impact of the risk.

• Cost and time required for the mitigation action.

• Contingency plan – what the team will do if the risk actually happens

• Designation of risk “owner” or risk manager (best designated by title or role rather than by
individual’s name)

Adding the following items increases the usefulness of the Risk Register:

• Additional risks

• Risks for additional tasks

• Results of handling each risk after controls are implemented:

• Consequences or cost at risk

• Likelihood or probability

• Final risk score or product (consequence times likelihood)

• Quantitative numerical consequences, probabilities, and risk scores (rather than subjective,

qualitative, or adjectival assessments)

• Additional narrative discussion of each risk, handling method, etc.

• Total of all the risk scores (risk products) for the entire project after risk controls are

implemented, in dollars.

• Also include some risks associated with the general ability to complete the project successfully.

(You might consider these risks at the project level of the WBS, affecting the entire

project.)

• Finally, if you quantitatively calculated the risk product in those terms, then what is the total of
all the initial risk scores (risk products) for the entire project, in dollars.

Part 2. Answers to Questions in Word Document

Please include the Executive Summary with appropriate changes

Questions: In an accompanying Word doc or text submission, answer the following questions:

1. Which risks (and associated tasks) would be the most threatening to the success of the project and
why? This discussion should be very specific to tasks and their associated risks.

2. Which top three mitigations (and associated tasks) and risk handling plans should be implemented,
and why? Remember that mitigation actions will affect cost, schedule and/or scope – so discuss
what can you affort to do based on the likelihood and impact of the risk?

3. What are the total impacts on cost, schedule and scope for the project if the recommended risk
controls and mitigation actions are taken? If you use costs, how did you calculate the cost? Will the
risk handling improve things or make them worse? That is, will the project cost more and/or be less
successful because of risk handling, or will it cost less and/or be more successful because of risk
handling? How so? Explain.

4. How did you determine those costs and impacts? Please describe. What is the benefit of mitigating
risks that are identified for mitigation?

5. If your project could only afford $20,000 for mitigation actions, which risks (identify associated
tasks) would be implemented?

6. If your project could only tolerate a 5 day delay related to mitigation actions, which risks and
mitigations (identify associated tasks) would be implemented?

7. What would be the most expensive (time and or schedule) contingency action/plan? Identify the
associated task and explain why this contingency would be the most expensive in terms of time or
schedule.

8. How did you determine those costs and impacts? Please describe.

Submit the Excel and the Word files(s) to the Assignment Area.

Approximate breakdown by areas include:

o General: Structure, Format, Mechanics, Style (~5%)

o Risk register (~84%)

o Questions (~10%)

Rubrics and Grading for the ITP -5 Project Deliverable

To earn 90-100% of the points available for this assignment –

The risk register meets the basic requirements. Identify at least 10 risks at each level of the WBS,

including risks that affect the general ability to complete the project successfully, major tasks of

different types and categories, sub-tasks of different types and categories, risks of several different risk

types and categories, including external risks, financial risks, organization risks, PM risks, quality risks,

technical risks, and other risk categories. In addition, include such things as:

• Multiple risks for single tasks

• Quantitative numerical consequences, probabilities, and risk scores (rather than subjective,
qualitative, or adjectival assessments)

• Show risk assessment (probability, impact, and score) numerically (e.g., percentages, dollars,

etc.) rather than qualitatively.

• Additional narrative discussion of each risk, handling method, etc.

• Designation of risk “owner” or risk manager and why that person or functional position is the

“owner”

• Total of all the risk scores (risk products) for the entire project after risk controls are
implemented, in dollars.
• Also include some risks associated with the general ability to complete the project successfully.

(You might consider these risks at Level 0, the root level, of the WBS, affecting the entire

project.)

• Answer all the initial risk scores (risk products) for the entire project, in dollars.

Include the following risk info for each risk: Title or description of item or TASK at risk; Description of the

RISK; Risk category or type; Initial assessment of Consequences, impact, or cost at risk; initial likelihood

or probability; Initial risk score (consequence x likelihood); Risk handling CATEGORY; Risk handling /

control / mitigation / action PLAN; Designation of risk “owner”; Risk results with/after controls /

handling plans implemented (Consequences or cost with controls; Likelihood or probability with

controls; Final risk score (consequence x likelihood)). Answer all questions, and include reference

sources are used in the text and included in a Reference page. Show risk assessment (probability,

impact, and score) numerically (e.g., percentages, dollars, etc.) rather than qualitatively.

To earn 80-89% of the points available for this assignment –

Identify at least 6 risks at each level, including risks such as: the general ability to complete the project

successfully; major tasks of different types and categories; sub-tasks of different types and categories.

Include risks of several different risk types and categories, including risks such as: external risks, financial

risks, organization risks, PM risks, quality risks, technical risks, and other risk categories. Include several

different risk handling categories (avoidance, mitigation, transfer,

acceptance).

Include most of the following risk info for ea. risk: Title or description of item or TASK at risk; Description

of the RISK; Risk category or type; Initial assessment of Consequences, impact, or cost at risk; initial

likelihood or probability; Initial risk score (consequence x likelihood); Risk handling CATEGORY; Risk

handling / control / mitigation / action PLAN; Designation of risk “owner. Answer all

questions.

To earn 70-79% of the points available for this assignment –

Identify at least 3 risks at each level, including risks such as: the general ability to complete the project

successfully; major tasks of different types and categories; sub-tasks of different types and categories.
Include risks of several different risk types and categories, including risks such as: external risks, financial

risks, organization risks, PM risks, quality risks, technical risks, and other risk categories. Include

different risk handling categories (avoidance, mitigation, transfer, and acceptance).

Include most of the following risk info for ea. risk: Title or description of item or TASK at risk; Description
of the RISK; Risk category or type; Initial assessment of Consequences, impact, or cost at risk; initial
likelihood or probability; Initial risk score (consequence x likelihood); Risk handling CATEGORY; Risk

handling / control / mitigation / action PLAN; Designation of risk “owner. Answer the majority of the

questions.

To earn 60-69% of the points available for this assignment –

Identify at least 6 risks, including risks such as: the general ability to complete the project successfully;

major tasks of different types and categories; sub-tasks of different types and categories. Include risks

such as: external risks, financial risks, organization risks, PM risks, quality risks, technical risks, and other

risk categories. Includes only one of the risk handling categories (avoidance, mitigation, transfer,

acceptance).

Include much of the following risk info for ea. risk: Title or description of item or TASK at risk;

Description of the RISK; Risk category or type; Initial assessment of Consequences, impact, or cost at

risk; initial likelihood or probability; Initial risk score (consequence x likelihood); Risk handling

CATEGORY; Designation of risk “owner. Answer the majority of the questions.

Less than 60% –

Risk Registers that do not meet the requirements will earn a zero. WBSs that are not original work will

earn a zero.

Risk and Risk Management

Risk is something we live with every day in every way. I believe that a PM who does not

understand or address risk is headed for sure disaster. A PM can not possibly anticipate every

risk to the project, but having a sound risk management effort is essential. Therefore, we have a

separate weekly lecture so that you may have the benefit of seeing what risk is and how a PM

should be dealing with it.

One book says that uncertainty “decreases as the project moves toward

completion.” What happens is that those things a PM didn’t know at the beginning of the project

become known as the project moves to completion. The first schedule for the project is little

more than a guess. The number of people required for the project team are estimates. How long

the project should take is never based on some scientific formula; usually the schedule is dictated

by the need for the project to be completed by a certain date. Obviously, as you begin the project

and move through it, you will learn more about what it really costs or how long it really takes or

that you have all the wrong people on your team. So, from that perspective, the author is right

that uncertainty decreases as the project moves toward completion. But you are the PM. You

have just been assigned. What ARE the risks you will be dealing with?? How do you identify

them and how to you eliminate them or at least mitigate (taking action to avoid or minimize the

risk) them?

There are volumes and volumes of literature and techniques for answering these

questions. This lecture is a brief, and very simple, approach to risk that you may find to be a

good start when, as a PM, you need to address risk. You are free to find any source or help you

want to supplement this lecture. A thoughtful student would be able to define and discuss risk as

it relates to project management, in case the subject comes up in your job or with other teams

that you work with.

Risk is defined as the possibility of loss or injury. Identifying and managing risk

allows a PM to lessen the loss or injury to the project. Our first point in dealing with risk is that

managing risk can be expensive. The PM will need to assess identified risks and determine if the

benefits of mitigating the risks outweigh the costs. For example, if you are the project manager

for moving your company to a new building in New Hampshire, you COULD have the building

built to resist earthquake damage. You have identified acts of nature as a potential risk;

earthquakes are a force of nature; and you decide that it is better to be safe than sorry, so you

contract to have the building built using reinforced, flexible materials in case of an earthquake,

probably at great additional expense. But how often do earthquakes strike New Hampshire?

Certainly not often enough to justify the cost of earthquake-proofing the building. But, you have

addressed and mitigated the risk! Now, let’s say you are tasked to move your company to

California. Now is the earthquake preventative measures worthwhile? Yes! Earthquakes are a

real risk in California, so the costs involved to mitigate the risk could prove to be money well-

spent. So the first rule of risk managing is to make sure the cost or benefit of mitigating risk

outweigh the risk itself.

As I mentioned, risk needs to be identified at the beginning of the project. Some risks will

be known early enough to include them in the project charters as you did. Otherwise, the project

team will find and identify risks through the life of the project. Obviously, the first risks

identified will affect the cost, schedule and deliverable or outcome of the project. Cost, schedule

and deliverable are not, in and of themselves, RISKS. The risks you identify will AFFECT the

cost, schedule and deliverable. So, if material were delivered late, or experienced a sudden jump

Page 2

in price, this would affect your schedule or your cost. So the RISK is late delivery or suddenly

increasing price – NOT the cost and schedule of the project. This is a fine point, but worth

spending the time thinking about and understanding. WHAT could cause your project to be late,

over budget, or not what the customer ordered? THAT is the risk!

And the whole purpose of the project is to manage the cost, schedule and outcome. Many

project managers have a risk management plan. This risk management plan is updated on a

regular basis to eliminate the risks that have passed and to add the risks that continue to be

identified. There are risks associated with each stage/phase of your project, but as you progress

some of those will go away and new risks will become known. For example, if you are buying a

house, an early risk might be that the house has termites. You have a termite inspection and find

out that the house does not have termites. Therefore, the risk of termites can now come out of

your risk management plan. But then you find out that the house is built on a high water table, so

you now know there is a risk of leaks in the basement – so you add that to your risk management

plan. The Plan should be a living document that is revisited REGULARLY.

All risks will have some cost, schedule or performance impact. To mitigate a risk, you

must address its impact to cost, schedule or performance/outcome. If you are forced to exercise

your contingency plan (what you will do if the risk happens), you must be prepared to pay for the

contingency with cost, schedule or performance/outcome. So now, we must identify the risks we

know as they relate to the cost, schedule and outcome.

The mechanics of how a PM does this varies from PM to PM and from project to project.

As PMs gain more experience, they use more and more sophisticated means. The very first step

is to identify and document everything that threatens the program. My favorite method is with a

series of brainstorming sessions. We, as a team, look at everything we can think of to determine

what we know and what we don’t know. For example, has similar work been done before? If yes,

what went wrong and what happened that was unexpected? If no, is the project even feasilble?

Does it push the state of the art into unknown territory? Is it bleeding edge technology? Is the

project the first application of pure lab-based research?

For the purposes of our example, we’ll pretend that we are building a software application

to provide a functional capability in the personnel or human resources office. Let’s start by

addressing all the things we don’t know:

• We don’t know if our cost estimates are valid.

• We don’t know if we can get the people we need when we need them.

• We don’t know if the requirements have been thoroughly documented.

• We don’t know if we will be able to get the people and equipment for a thorough testing
of the developed software.

• We don’t know if we will be able to build the interfaces with the existing applications or
be able to migrate data to the new application, for starters.

I’m sure as you sit with your team, you will discover lists and lists of risks, those things

that are unknown or could threaten your project. As you build your work breakdown structure,

you will continue to find areas, items and actions that need to be documented so you can manage

the uncertainty. After you make the list (and you will revisit, revamp and revise the list

continually through the project), you may go through the list to prioritize the risks you have

Page 3

identified. WE have to determine the level of importance, so we know what to do with the risk.

We will mitigate the risk (take action to AVOID the risk happening), or we will avoid the risk

(do nothing and hope it doesn’t happen). If we ignore the risk, we still should have a

contingency plan so that we know what to do if the risk really DOES happen. It’s important to

understand the difference between mitigation and contingency – mitigation is what we do

BEFORE a risk happens; it is the PLAN to avoid or minimize the impact of the risk.

Contingency is what we do AFTER the risk happens – our Plan B and how we minimize the

damage or harm.

You will go through a process of determining what will have the greatest impact on your

project if it really happens. If you are in New Hampshire, the likelihood of not having a good

requirement is more probable than the likelihood of an earthquake. So your requirement ranks

higher on your list (I hope!). You may use a very quantifiable method of ranking, like assessing

and assigning probability, or you may rank based a a simple process like “high, medium or low”

risk, or any other methodology for ranking and rating. Like the list itself, the ranking of the

items on the list may change from time to time. For example, say a vague or changing

requirement ranks high as a very real, very probable risk but senior level management

sponsorship for the project is a low risk because you are sure you have total support for your

project. Six months or a year later, you have been able to develop software against the

requirement you had, but the senior level management has changed because of a corporate

merger. NOW the senior sponsorship and approval is a high risk but the requirement is a low

risk.

So, risks are looked at from TWO perspectives – (1) how likely is this risk? In other

words what are the chances this risk will really happen? And, (2) if the risk happens, what is the

impact to my project? So, if we think about having a big party as soon as our newly constructed

house is finished, we would have to consider (1) is the house likely to be finished on schedule;

and, (2) if the house is not finished on schedule, what happens to the party? Another example, if

we are planning a cruise for a special even in September, we would have to consider hurricanes.

How likely is it that a hurricane would affect the cruise? And, if a hurricane DOES happen and

results in the cruise being cancelled, what happens to the money we paid for the cruise tickets?

Look at the likelihood and then the impact. Is it likely that a building in Kansas will be destroyed

by a tornado? No. But if the building IS destroyed by a tornado and this is the backup facility for

all of our archived data storage, what is the IMPACT on our company and its ability to do

business?

After the PM identifies and documents all risks, and then prioritizes the list from most

important, or critical to the program, the PM will address what actions could be taken to

eliminate or mitigate the risks. This is where reality comes in. To mitigate the risk of earthquake,

you could build an earthquake resistant building or you could move to a less earthquake prone

area, or you could increase your earthquake insurance. In the case of the vague requirement risk,

you could take more time for requirement development, include people from the requirement

activity on the team, compare the requirement to similar efforts, and benchmark the requirement

by comparing it with others done elsewhere, among other possible ways to mitigate the risk of

vague requirements. Now, how many ways are there to mitigate the risk of data migration?

So now, the PM has identified the risks, ranked them based on priorities or what can do

the most damage to his/her project and what is most likely to happen, and identified several

Page 4

different ways to keep the risk from occurring or minimizing the impact of the risk on the

project.

The next step is to identify what you will do if the risk really happens. What will you do

if your building is damaged by an earthquake? What will you do if your number one researcher

takes another job? What will you do if the merger goes through? The contingency is what will

happen next. In Information Technology, we usually build “continuity of operations” (COOP)

plans – what we will do if our systems break for one reason or another. We MITIGATE problems

by building back-up systems and if our systems really breakdown, our CONTINGENCY is to

switch to those back-up systems to continue our business.

And then as a PM, you may only be able to manage the “high” priorities. What you may

find is that your top priorities all have costs associated with the mitigation actions. Obviously,

you will only mitigate those risks you can afford. You can’t put your software development

organization in a fireproof building to avoid the risk of fire, for example, because it would cost

too much..

Now for a real life example: A few years back, I worked on a software program that

required multi-level security access. In other words, the users might have secret, top secret or no

clearance when they got into our system. The software needed to determine what level the user

had and would only give that user information that the user had security clearance for. At the

time, the capability for multi-level security was early bleeding edge – only a few vendors had

attempted to build it, and none had been certified by the National Security Agency or the

National Institute of Standards and Technology, both of which were required. Therefore, we had

a requirement with a high risk rating and the only mitigating actions possible were to cancel that

part of the requirement to avoid project delay OR delay the project. We HOPED that by the time

we needed the capability, the capability would be there. And the technology was rapidly moving

in that direction – it was a race against time! Let me know if you want to know the outcome!

So, as you finish this lesson, you should be able to describe the difference between

mitigation and contingency, and be able to discuss the risk management process.

ProjectRisk Management

Project Risk Management Page 1 of 5 January 2020

Project risk management is one of my favorite topics in project management — not because it’s so much fun
(that’s in the eye of the beholder) but because it’s so important.

In its simplest essence, a risk is an uncertainty, in this case about the project. A risk is essentially a possibility
that something may go wrong in the future. It has not gone wrong yet (if it had, it would be a problem or an
issue, not a risk), but it may in the future. Project planning looks into the future to plan now what we’ll do then;
no area in PM is more future-oriented than risk management. The whole point of risk management is to think in
advance of what might go wrong, and plan in advance how to forestall it so that it doesn’t go wrong, or how to
handle it successfully if it does go wrong.

Since the goal of a project is to succeed and not fail, managing risk is critical. As RADM Bill Carlson says, “if
you’re not managing risk, you’re managing the wrong thing.”

We can drive the management of a project entirely by managing risk. Put another way, we can manage an entire
project from a risk perspective. It’s that key to everything. Personally, I’d argue that it’s even more important
than quality. After all, we can manage quality by managing risk (i.e., by managing the risk of poor quality).

Actually, the above discussion is an oversimplification. Risk isn’t really the possibility that something may go
wrong. Risk is actually uncertainty that can impact a project. It can actually be the uncertainty of a good thing as
well as the uncertainty of a bad thing. (More about this as we go on.)

Risk management is another area that many people would add as a 4th (or 5th) element of the triple constraint

Some Definitions and General Comments on Risk

Project risks can be defined as uncertainties. Another valid perspective is that risks are problems that haven’t
happened yet. In short, everything that does not match the plan is a risk.

The flip side is that problems are materialized risks, i.e., risks that have actually happened. Issues, then, are
problems that we can’t solve ourselves and must elevate to higher management for handling.

So the progression in time is: risks, to problems (if they materialize), to issues (if they can’t be solved). Any of the
above may also generate project or product changes in order to handle the risks or solve the problems (or alter
the factors in the triple constraint if management so directs). They may also, of course, generate process
changes and other effects. To reiterate: If we don’t identify risks up front and plan for how to handle them if
they should occur, then like it or not, we will have to handle them later on as problems and issues, and that will
cost more and put the project (and the project manager) in greater jeopardy than dealing with them up front as
risks.

Risks are ubiquitous. As mentioned above, we can drive the management of a project entirely by managing risk.
Put another way, we can manage an entire project from a risk perspective. It’s that critical to everything. You
could even argue that it’s even more important than quality. After all, we can manage quality by managing risk
(i.e., by managing the risk of poor quality), but we can’t really manage risk by managing quality because there
are a lot more risks than simply quality issues alone.

There can be good risk and bad risk, positive risk and negative risk. Like conflict, we tend to concentrate on the
bad side. However, there can be a risk of something good happening also. How can that be? Remember that
risks are uncertainties. So there can be a possibility, an uncertainty, that some identified or postulated good
thing may happen on the project, also.

Unfortunately, the risks of good things happening seem to be much less likely than the risks of bad things
happening, so we tend to ignore the possibility. As in dealing with bad risk, there’s little point in worrying about
or planning for risks that are extremely unlikely. For instance, there’s not much point in wasting effort on
planning how to handle the risks to the project if an asteroid destroys the earth

2 of 5

R i sk I denti fi c ati on

Project managers tend to be reticent with risk management. That is, they are reluctant to identify or admit risks
and when identified have been too eager to either ignore them or sweep them under the rug. The opposite
approach would better facilitate project success.

I’ve known PMs who said that risk management is the business only of the PM (or of the risk manager, if the
project has an identified risk manager). Again, the opposite approach would be much, much better: Everyone at
every level should be engaged to identify risks. It is normally much more likely that workers will be able to
identify risks in their own areas, with which they are intimately familiar, after all. Outsiders and higher-ups just
aren’t familiar enough with the nitty-gritty daily details of other areas to be able to identify risks in them very
well.

Risks should be specific, not general. There is little benefit in making the risk is so general that it’s vague. Tha’s
not very useful for pinning down the actual risks to an actual project nor developing a risk handling plan for
them. Needless to say, there should be no recriminations or penalties for surfacing or identifying risks.
Identifying risks, after all, is a good thing, not a bad thing.

Ri s k C ateg or i es an d Mi ti g ati on

This week’s reading, Managing Project Risk, has example categories for potential risks. It also explains the
different approaches to mitigating risk. Feel free to use them or other examples that you find during your
research.

C r i ti c al r isks that “th ey ” do n’ t w ant y o u c onsi der

… Stakeholders, that is, especially executive sponsors.

In my experience, there are some kinds of risks that stakeholders don’t want to admit and that PMs don’t think
to consider but that are very real, that can absolutely decimate a project, and that should therefore be included
in all risk registers, lists, and handling plans. These include things like budget cuts, inadequate funding,
customer/stakeholder non-responsiveness, lack of strong and vocal sponsor/stakeholder support, public
reaction and its impacts, and the like. And in public projects, special interest groups, outside agitators, and
lawsuits. They are generally project-level risks (as opposed to technical or other risks affecting only one or a few
work package tasks), and they can be real killers. But the stakeholders often get upset if they see them listed in a
risk register. List them anyway! Identifying them and planning for how to handle them could make or break
your project.

Hi g h-l ev el r i sks

Other high-level, project-level risks might include things like requirements risks (are the requirements accurate
and complete? was anything left out? are they stable or is there significant volatility and scope creep?), project
communications with stakeholders and among the team (is it good? is it poor? is everyone getting the
information they need when they need it?), and similar risks. Try some Brainstorming if you need to (see below).
These are important.

Level 1 of the WBS is the project phases or major components. Are there any risks in those phases or are they
risk-free smooth sailing? Is there adequate funding in the initiation phase? Do customers and billpayers always
agree with cost estimates? Do they ever think they should get something for nothing? How about non-
responsive customers or sponsors in, well, any phase? Mis-steps in planning? A lack of information, perhaps?
Certainly execution encompasses most of the project, is there anything that could go wrong there? Scope creep

3 of 5

in execution is a big one? Budget cuts never happen, right? Oh, and don’t forget natural disasters. Could
anything be unknown (risky) in any of these phases? Ponder these kinds of things for a few minutes and I’m sure
you’ll come up with lots of different risks (and different kinds of risks) for many phases and for many levels.

Ri sk Response Pl an ni n g

Each identified risk should be analyzed and documented in the risk register. If it is a serious risk (both reasonably
likely and reasonably severe, as evaluated by qualitative and quantitative risk analysis), then a risk response plan
should be prepared. The response plan for a risk tells what to do to forestall and prevent the risk, and/or what
to do if the risk actually occurs. (Remember, risks are potential future events.)

If, for instance, the risk is that we’re building a data center in a flood zone, then a way to forestall or prevent
that might be to build it elsewhere outside the flood zone, to build it on high ground, or at least to not put it in
the basement! (Don’t laugh. I’ve seen a data center built in the basement of buildings that were known to flood
in heavy rains. Sure enough, the data center flooded, too. It’s a pity nobody listened when that risk was
identified — repeatedly.)

Other risks can’t be prevented, so the risk response plan tells what to do to reduce or mitigate the damage if the
risk actually occurs. For instance, if the risk is of fire, then we can install sprinklers or the like.

Ri sk Mai nte na nc e

The risk register should be kept up to date. Just because we went through the exercise of thinking about risks
once at the beginning of the project doesn’t mean that no further risks can ever arise! A constant eye must be
kept on conditions to see whether there are new risks that need to be considered, as well as to see whether any
of the risks are materializing. Periodic project team meetings are a good place and time to consider and keep
tabs on risks.

B r ai nstor mi ng

I’ve seen brainstorming done so poorly that it’s counterproductive. Many people have heard the term but
apparently don’t really know how to do it effectively. Here are some observations and suggestions:

• “Brainstorming, familiar to nearly every citizen of the developed world, is the preferred and obvious way
to jumpstart a stalled problem solving process. The freewheeling and uncensored atmosphere of tossing
out ideas without debate or discussion is just what is needed. In fact, brainstorming incorporates into its
procedures another of the great process meta-rules.” — Larry Constantine, “Habits of Productive
Problem Solvers”, Software Development Online, August 1, 1999.

• Branistorming, then, is group outside-the-box thinking.

• “Take, for example, brainstorming. By now, most of us in business have learned how to brainstorm
properly. We sit at the table, politely waiting our turn while the facilitator asks for our ideas in strict
rotation, writing them down verbatim while we all take great care to avoid offering even the slightest
appearance of criticism lest it intimidate the flow of creative thought. Then we get our milk and cookies
and take a nap.” — Bob Lewis, “Braindrizzling”, Inforworld, Sept. 30, 2002.

• Of course, he’s being facetious and ironic. He’s advocating the opposite. Unfortunately, that actually is
how far too many people view brainstorming. Worse, all too many practitioners omit the part about
avoiding criticism; they encourage jumping in and severely criticizing anything that’s different from the
current politically accepted view. (I’m referring to corporate office politics, of course, not Washington

4 of 5

politics.) We immediately notice that Lewis’s facetious paragraph is essentially the opposite of Larry
Constantine’s view, above.

• Brainstorming should be an unstructured, rapid-fire, throwing out of ideas — preferably outside-the-box
ideas — in any order, regardless of reasonability, feasibility, or anything else. The time for analysis and
consideration is after brainstorming is completed, not during. It is definitely not round-robin. Anyone
who gets an idea should immediately throw it out without waiting for his “turn”, even if he has several
ideas in a row. It’s okay — in fact, it’s good — to piggy-back off others’ ideas if that triggers a thought.
Conversely, people who don’t have any ideas shouldn’t be required to think of one just because it’s
“their turn”.

• A contrived example may help: Brainstorm what’s in this small box that I’m holding. (It’s contrived
because we can just open the box to see what’s in it, but please bear with me — there’s a point.)
Everyone should throw out whatever ideas they have. … But you’re being too conservative and not
thinking outside the box. For instance, nobody said that there’s an elephant in the box. An elephant is
far too big and couldn’t possibly fit in this box, you say? True. But if you said “an elephant”, it might well
have prompted someone else to say “a picture of an elephant”. And that, as you can see, is what’s in this
little box.

• Perhaps you can see how this free-wheeling outside-the-box thinking can be a good way to think of
possible risks. Not everything thrown out in a brainstorming session will be useful. After the session, the
ideas should be considered, analyzed, and evaluated. Some of them may yield potential risks that should
be documented and handled.

5 of 5

B i bl i og r aphy

Anonymous (n. d.). “Quantitative Risk Analysis”. King Fahd University of Petroleum & Minerals . Retrieved
December 3, 2011 from
http://faculty.kfupm.edu.sa/CEM/alkhalil/PDF_CEM_516/L05%20Quantitative%20Risk%20Analysis

Elyse (2007, February 7). ”Qualitative Risk Analysis”. AntiClue. Retrieved December 3, 2011 from
http://www.anticlue.net/archives/000817.htm

Fuller, Mark A, Joseph Valacich, and Joey F. George (2008). Information Systems Project Management: A Process
and Team Approach. Upper Saddle River, NJ: Pearson Prentice-Hall.

Kuras, M., Zajac, A. (n.d.) “Information Systems Pitfalls: How To Reduce IT Risks”. Retrieved December 2, 2011
from http://ki.ae.krakow.pl/~zajaca/artykuly/Ostris97.htm

Lewis, Bob (Mar. 19, 2012). “Why ‘premortem’ really stands for ‘prevent mortem’ “. Keep the Joint Running blog.
Retrieved from http://www.weblog.keepthejointrunning.com/?p=4602. [Note: this is more about risk
management than post-mortem assessments. — ks]