ITP-3 - Project Risk Assessment

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.