CASE STUDIES

Risk and Risk Management

Additional lecture material from guest lecturer Dr. Donna McKalip, DM, PMP, Academic Director for Information Systems 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 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 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 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.