Section 9.6. Identifying Project Risks
9.6. Identifying Project RisksBy now it should be clear to you that there are many different kinds of project risks. The question is, which ones should you deal with? If you spent all your time addressing every possible project risk, you'd either end up in planning gridlock getting nothing done or you'd decide to scrap the project because you can't address all the risks. The key to risk management is to identify the risks that are both likely to occur and harmful if they do occur. Some project risks are highly likely to occur, but not particularly harmful, and you would deal with them as you would any minor inconvenience. Other project risks are not particularly likely to occur, but would be harmful if they did occur. This might include a natural disaster that destroyed the office building or destroyed the project work already accomplished. Most project risks fall someplace in between these two types of risks. There are essentially three steps in IT project risk management: risk identification, risk quantification, and risk mitigation. Let's take a closer look at these three elements. 9.6.1. Identify IT Project RisksThe first step in planning for and managing project risk is to identify all known project risks. This is a good opportunity to get the IT project team together (make sure you have some analyzer types included, as they are often particularly good at this type of exercise) to identify risks. The first step is to determine what could go wrong with the project. Here's a list of potential problems to get you started, but you should certainly add to this list to address your project's particular risks.
Remember that your IT project's risks come in many different formsfrom external to internal. Make sure you scan the horizon for all potential risks that may impact your project. If you have people on your team who always see the dark side of things, this is their time to shine. Utilize that skill to root out potential problems. Don't let the meeting spiral down into endless negativity, though. Manage the team so that the outcome of this exercise is cleara list of all potential project risks, not a doomsday report.
9.6.2. Quantify IT Project RiskOnce you've identified your project's risks, you'll need to quantify and qualify them. Different companies have different ways of approaching this exercise, so if your company has a specific method for assessing risk, feel free to use that for your project. Otherwise, you should sort your list twice. First, you should go through your list of risks and sort them from most likely to occur to least likely to occur. If you want, you can use a numbering system and give the smallest numbers to the risks least likely to occur. Use a numbering system such as 5 = highest likelihood and 1 = lowest likelihood (or 50 through 1 if you want to use a somewhat "weighted" scale). If you sort that list in descending order, you should end up with the risks with the highest likelihood of occurrence at the top of your list. Next, go through your sorted list a second time. This time, rank the risk in terms of the impact to the project should that risk occur. Again, use larger numbers for those with the highest impact and use the same numbering system as you did for your likelihood rating (5 = highest impact, 1 = lowest impact for example). Now, tally up the totals for each risk. Your resulting list should have the risks with both the highest likelihood of occurrence and the highest impact to the project listed at the top. The next question that naturally arises is how many risks should you plan for? Clearly, you can't (and shouldn't) plan for every single risk. How far down you plan is a matter of your project's precision. If you recall from our discussion earlier in the book, precision is how much planning and detail are required for any given step in a project. If your least flexible element of the project is project scope, you should look at your project risks with that in mind and deal with all risks that put your project's scope at risk. You may also look at your sorted list and see a natural dividing point. For instance, you might find that your sorted list has 10 project risks with a combined score of 25 or higher because the next risk on the list has a combined score of 12. That gap clearly denotes a change in the nature of the identified risks and might be a natural stopping point in terms of planning (we'll discuss planning for project risks in just a moment). Finally, make sure you look at your project's critical path tasks and critical path schedule and compare them with the project's identified risks. Make sure that you've accounted for risks to the critical path and that those critical path risks are on your list of risks to plan for. It's likely they're accounted for because their impact to the project, should they occur, is the highest. If these risks have a low likelihood of occurrence, you can still choose to plan for them since they could put your project schedule at risk. This is where using a little human intelligence can come in quite handy. After you have your double-sorted, prioritized list, look through it and decide what you will and won't plan for. You should plan for risk to whatever degree is appropriate for your project. If you look at NASA's Space Shuttle missions, where human life is at risk, the risk management process is clearly more rigorous (as it should be) than it would be for a server network upgrade. Don't get paralyzed at this point trying to identify and plan for every possible risk, but do use your best judgment to determine how far down your risk list you should plan. 9.6.3. Mitigate IT Project RiskOnce you've made a determination as to which risks you're going to plan for, spend time with the project team identifying your mitigation strategies. Mitigation strategies are alternate plans or strategies you devise to minimize or avoid (mitigate) the defined risks. Essentially, you are answering three key questions: "What can I change in the project to reduce or avoid this risk?" "What will I do if this risk occurs?" and "How will I know if this risk occurs?" 9.6.3.1. Alternate PlansIdeally, the best risk mitigation strategy is to avoid the risk altogether. In some cases, simply identifying a risk provides you (and your team) with alternative ideas about how to approach a particular task. If you can change a task to avoid a risk altogether, you're far better off. Since it's not always possible to avoid risks, your next course of action will be to make alternate plans in case that risk occurs. For each selected risk, you should identify what you'll do if that risk occurs. For instance, suppose the project you're working on relies upon a particular technology that is in a state of change. There is a risk that the technology you've selected will be the technology that falls out of favor (perhaps the change is occurring during your definition or planning phase) and you'll need to re-tool to use another, competing technology. That's a serious project risk that has both a high likelihood of occurrence and a high impact to the project. It almost certainly impacts your critical path. So, what should you do? In some cases, you may choose to delay the project just a bit until it becomes clear which technology path you should take. In other cases, it might mean developing two paths, using both technologies, until it becomes clear which direction to head. If you can select the "right" technology by doing further research, you're that much better off. If you can't, you will have to plan for the best and worst case scenarios. Creating alternate plans may yield some fascinating new alternatives that end up becoming so desirable that you modify the project plan to utilize these new alternatives or you develop ideas for another related project. The exercise of developing alternatives helps you understand and manage project risk and sometimes leads you down new paths to better alternatives for this project or other projects. Let's look at an example. 9.6.3.1.1. Risk Avoidance (or Countermeasure)Let's say your project is to upgrade the network infrastructure including upgrading a customer relationship management (CRM) application that will use a three-tiered database model. One of the risks you've identified is that a legacy application not slated for upgrade has to tie into this new application and it lacks the proper interface to do so. Clearly, this problem has a high likelihood of occurrence and a high impact to the project. It is likely the interface task is on the critical path as well. What alternative plans can you and your team devise to address this? There are many possibilities, though only a few may end up being feasible, logical, desirable, or affordable (four elements discussed in Chapter 2). For instance, you may choose to upgrade the legacy application prior to moving forward on this project; you may choose to write a custom interface to link the legacy and the new applications as part of this project; you may choose to purchase a third-party interface; you may choose to outsource the development of a custom interface; you may choose to incorporate the functionality of the legacy application into this project (which requires going back and revising your entire project plan including creating a new problem and mission statement, and revising functional and technical specifications, scope definition, Work Breakdown Structures, etc.). As you can see, there are a range of choices (you'll probably be able to think of several other viable alternatives on your own) and there is no one clear direction to go unless you go back to your project definition and look at the problem the project is trying to solve. At that point, the best alternative may become clear. In any case, you must choose your best option and plan accordingly. 9.6.3.1.2. Risk Mitigation (or Reduction)Let's look at another scenario. Suppose there are three high-profile projects being planned that all have roughly the same start date. All three projects at one point or another require the skills of four software developers. You are the IT project manager for one of these three projects and though you have some great political pull in your organization, you realize there's a high likelihood that these four developers will be busy when your project needs them. You've talked with the other IT project managers about the timing of their projects and when they'll need these developers, but you also know that timing on projects shifts around a lot. Without the efforts of these four developers, your project is at risk. With a high likelihood of occurrence and a high impact to the project, this risk must be planned for. Though you may have some strategies in mind to avoid the risk altogether, you also know there's a chance these developers could be available (of course, we're assuming for this example you don't have a Project or Program Management Office overseeing the allocation of all project resources). One of your risk mitigation strategies might be to identify external contractors with the requisite skills to perform this work should your internal developers be unavailable when needed. You may also determine that the work the four developers must do can actually be done in parallel with other work and you may be able to modify your task sequence (and therefore schedule) if these developers are busy when you originally needed them. You might also decide to use outside contractors for this key work regardless because you can't risk not having these developers available. All of these may be viable alternatives, depending on your project's mission and deliverables. All of these potential solutions reduce your risk as it pertains to the four developers. Some of them reduce your risk to zero (by deciding to use contractors regardless of internal staff availability), but increase your costs. Keep in mind that some of these strategies introduce new risks, so you have to watch for secondary risks. For instance, if you choose to use outside contractors, what happens if those contractors simply decide they don't want to work on your project because they got a better offer or better project from someone else? What happens if those contractors fail to deliver as promised? What happens if those contractors don't have the skills you thought they had? There are a number of new risks you've introduced. Again, many of these can also be mitigatedusing contractors with whom you have worked in the past, contractors who come highly recommended by peers or associates, etc. Still, there are new risks and when you come up with any alternative plans, you must also assess those risks and address them to the degree possible. While it might seem that you could identify risks and alternatives and the risks of those alternatives and so on for eternity, you really just need to be aware of the fact that new plans create new risks and you should evaluate the pros and cons before you head off in a new direction. Using the developer example, you might decide that you will line up four external contractors, and you'll actually have one of the contractors start some of the work and you will use the internal developers as they become available while the external contractor continues uninterrupted. Whatever arrangement you choose, make sure you've looked at the new risks you're introducing and try to find a balance between the known risk (your four developers may be busy) and your new unknown risks (the reliability of untested external contractors). 9.6.3.2. TriggersOnce you decide which project risks you're going to address and what you'll do to address those risks (either by avoiding them or by minimizing their impact), you then have to identify triggers. Triggers are the specific sets of circumstances that must occur for you to put your alternative plans into action. Using the example of the four needed software developers who may be busy when you need them, you'll need to identify when you will implement "Plan B." For the sake of argument, let's say you chose to identify two external contractors you could use if your internal developers were busy. You realize it will increase your costs, but you also know that you'll have these two contractors' full time and attention so you may get more productivity from these two than you might otherwise get from two equivalent internal developers (who may be constantly interrupted with questions, pulled into meetings, etc). You're only going to use these two external contractors if the internal developers are busy because your project sponsor does not want to pay for external services if at all possible. When do you decide it's time to use those contractors? Obviously you don't wait until the day the task is scheduled to start to find out those needed resources are busy. At what point will you decide to use those contractors? Under what circumstances? The trigger point for using your contractors may be the projected availability of the four internal developers one month prior to the beginning of the work package to which they are assigned. It might also mean that two months before that work is to begin you work with a technical recruiting firm to locate the developers you need or that you contact contractors you've worked with in the past and get a verbal commitment from them. Whatever arrangement you make, you must decide on the timing of the trigger and what will happen when that trigger occurs. That way, when it becomes clear that three of the four developers will not be available when your project needs them, you have a calm, clear plan for moving forward. Add trigger points as milestones to your project schedule.
9.6.3.3. Risk Mitigation PlanYour risk mitigation plan should be a list of tasks that are at risk, the level of risk, the alternate plan, and the trigger point. You may choose to add a few elements such as who makes the decision to use the alternate plan (the task owner, the project team, the project manager), who needs to approve the alternative plan (if it involves an expenditure, does the project sponsor have to sign off?), what the cost of the alternative is, etc. You can use a format similar to the one shown in Table 9.3 or you can use whatever format suits you as long as it contains these critical elements. Be sure to have clear alternatives and triggers so you can easily implement "Plan B" if the risk occurs and make sure you add in the cost of the alternatives to your budget as an additional reserve amount that is clearly delineated. These details should be captured in a document (depicted in Figure 9.12) and included in the project plan.
Figure 9-12. Project Risk Mitigation Plan |
EAN: 2147483647
Pages: 166