Risk Strategies

Previous articles in this series have addressed identifying risks to the project and choosing which risks to avoid or minimize by scoring and prioritizing the identified risks. The purpose of these two activities is to determine which risks you should deal with to increase the likelihood that your project will meet its goals and objectives. The actions that can avoid a risk are determined by the nature of risk, as are actions that can reduce the impact or probability of the risk event. The risks to a project that will build a bridge will differ from those that will build a software system. This article will address devising strategies for risks to software development projects.

Risk strategies are categorized in accordance with their approach to dealing with the risk:

• Avoidance The action or strategy chosen will be such that it eliminates the factors that generate the risk. For example, multi-sourcing a software system’s server will avoid the risk of delays to the project if your single source supplier cannot deliver the server on time.
• Mitigate Risk mitigation entails devising an approach that can lessen the likelihood of the risk event happening, but not completely avoid it, or lessen the impact if it does happen, but not completely eliminate it.
• Transfer You don’t avoid the risk or mitigate its impact or probability, you transfer responsibility for dealing with the risk to a third party. The classic example of this is insurance.

These strategies all deal with risk events that are threats to the project’s goals and objectives. There are things that could actually enable your project to exceed its goals and objectives and these are called Opportunities. Opportunities differ from risks in that risks are discouraged while opportunities are courted. A common example of an opportunity is the chance that a programmer finishes a piece of coding ahead of schedule. If you do nothing, the programmer will have a nice holiday but the project won’t benefit. A contingency plan for deploying the programmer in question on a piece of code on the critical path could help you deliver the project ahead of time. Contingency plans are not the only tool in the risk manager’s arsenal. Here is the complete list:

• Exploit To exploit an opportunity the project manager would implement a plan to increase the likelihood of the event happening. Taking our example of the programmer finishing the code earlier than planned, we could put a senior programmer on that code to increase the likelihood they would finish early. It is likely however, that putting the senior programmer on work that lies on the critical path.
• Enhance Deals with the impact of the opportunity. Let’s stick with our software system example. We have implemented a plan to exploit this opportunity by assigning the senior programmer to that code. We could enhance our opportunity by having a marketing program ready to capitalize on the early release. Enhancing the opportunity in this case would mean we not only save money by completing the project early, we also increase revenue with our marketing campaign.
• Share Sharing the opportunity means that the opportunity is shared with one or more parties outside the organization performing the project. The classic example of this is the formation of partnerships between companies to develop new technology. The purpose of sharing is to engage skill or expertise that the performing organization does not have in order to enhance or exploit the opportunity.

There are 2 strategies that we have not covered as yet and they apply to both threats and opportunities. These are:

• Acceptance Risks that are accepted have scores that are below the project’s risk threshold. The costs saved by avoiding or mitigating the risk do not justify the expense. Opportunities that are accepted are not acted upon for a similar reason: the expense of enhancing, exploiting, or sharing the opportunity exceeds the benefits that would be reaped should the event happen.
• Contingency The key difference between a contingency plan and the other actions for threats and opportunities is that the other plans (avoid, mitigate or transfer for threats; exploit, enhance, or share for opportunities) are proactive; they require you to act before the risk event happens. Contingency plans require you to devise a plan that will be acted upon should the risk event happen.

The skill that good risk manager’s have is not the ability to categorize an approach to a threat or an opportunity, rather it is the ability to identify the best strategy or plan to deal with the threat or opportunity with the budget available. Focus on the strategy or plan before worrying about whether the action falls into the avoidance or mitigation category. Good risk managers know their limitations when it comes to identifying the best strategies and plans and know how to supplement their knowledge with Subject Matter Experts (SMEs) to address their shortcomings. The first part of your risk strategy planning should be the identification of your areas of deficiencies and a plan to engage SMEs who can make up for them.

Let’s walk through some things to look for in each of the above strategies. The purpose of expanding on each of the categories is not to give you a comprehensive list of strategies or plans for each category, but rather to give you an overview of the characteristics that tend to make the different strategies or plans effective.

Avoidance

Avoiding a threat to your project’s goals will involve a plan to remove the project element(s) that would introduce the risk. You need an action that effectively removes the threat and you need to implement it in time to avoid the risk event. Let’s take the example of the risk of flu infecting a programmer developing a key piece of code for your software system. Having that programmer (and probably the entire team) inoculated for flu would be one way of avoiding this threat. Let’s assume that the shot has a 2 week incubation period. That means that the shot won’t be effective until 2 weeks after its been given. To be an effective avoidance plan you’ll need to ensure the programmer gets the shot at least 2 weeks in advance of the start of programming.

I have exposed a weakness in the segregation of approaches to dealing with risk into categories: is the flu shot 100% effective in avoiding the risk? The difference between avoidance and mitigation lies in that percentage. The flu shot is an avoidance plan if it is 100% effective, but becomes a mitigation strategy if it is only 99% effective. The real question is: does it eliminate enough of the risk to make it worth while? You would probably need to be a doctor to be able to provide a good answer to that question, but there are other situations where your SMEs will be able to provide good answers.

Let’s use another example to demonstrate an effective avoidance plan. The risk event you want to avoid is that the introduction of a new development platform that your development team has never used before will add extra effort to the project and delay the delivery of the software system past a hard deadline. The platform was chosen in the first place because eventually it will make programming more efficient and produce a better quality system but your project will not be able to realize those benefits. A possible avoidance strategy would be to continue programming on the old platform. Continuing on the old platform is guaranteed to be 100% effective in avoiding this risk because you remove the technology that introduced the risk event in the first place.

The trick to devising a strategy that will effectively avoid a risk event is to choose one your project and your organization can afford. The cost of the example cited above might be greater than the budget for the project would allow. Worse than that, it might be an approach that your organization cannot afford. Delaying the benefits to be derived from the introduction of the new platform might be urgently needed by the company. Your subject matter experts can help you gather the information you, or your sponsor, need in order to make a good decision.

In the case where an effective strategy that avoids the risk event cannot be devised, is it possible to devise a mitigation strategy that will reduce the impact of the risk event enough to preserve the project’s goals and objectives. Would a training program that provides the programmers with training in the new technology, plus the addition of 1 or 2 extra programmers reduce the impact of the risk event enough to deliver on time? The choice will always be a business decision: is the cost of the preventive strategy greater or less than the benefits derived? Is there a more cost effective way of achieving the same goal?

Mitigation

Mitigation is typically reserved for referring to threats to the project, but can be expanded to include both threats and opportunities if you divide the category into 2 sub-categories: exploitation of the opportunity or reduction of the likelihood of the threat and enhancement of the opportunity or reduction of the impact.

Exploit the Opportunity or Reduce the Likelihood of the Threat

Mitigation strategies that reduce the likelihood of the risk event, or threat, can be exemplified by our flu shot example. If the flu shot is less than 100% effective, then the flu shot would reduce the likelihood of the risk event. Test tools are another good example of a mitigation strategy that reduces the likelihood of a risk event. The risk event in this case is a bug being introduced into a later development phase such as Quality Assurance testing or User Acceptance Testing. The introduction of the automated test tool will increase the capacity of each programmer to test so if a programmer has a total of x hours to conduct unit, function, and system testing, the automated test tool will increase the number of test cases the programmer can run. This will reduce the risk of a bug that should be identified at this stage finding its way into the next stage where it is more expensive to fix.

Tools that enable continuous integration are also examples of mitigation through the reduction of the likelihood of the risk event. The risk is that a bug that has to do with the integration of various applications in a software system will not be found during development and will be propagated to a later test stage where it will be more costly to fix. Continuous integration reduces the likelihood of this by compiling and testing the system each time a piece of code is checked into the library. The question is how effective is it in reducing the likelihood: 100%?, 75%?, 50%? The answer is that it will depend on the number and thoroughness of the test cases.

Notice that the strategy does not reduce the impact of the risk event in any of the examples given above. A bug that escapes the rigorous tests implemented with the automated test tool will still cost the same amount of effort to report and fix.

Exploitation of an opportunity will also increase thelikelihood of an opportunity without enhancing its impact. I will stick to the example stated in the section entitled Exploitation above, where you staff the programmer role with a senior programmer to increase the likelihood that they finish the task early. There are several issues to consider in this case. Does the amount of time saved on this task warrant the expense of the senior programmer? Will engaging the senior programmer for this role put another task at risk?

Enhance the Opportunity or Reduce the Impact of the Threat

Reducing the impact of a threat does not have any effect on the possibility of the event happening. It does tend to reduce the cost of the event if it does happen, either the cost in terms of time or money. Taking our example of the flu shot, let’s suppose we have weighed the benefits of reducing the likelihood (or avoiding it altogether in the case of 100% effectiveness) against the cost of the shot and determine our risk budget can’t afford the flu shot. We still want to do something to address the risk we run of the programmer falling ill and delaying delivery of the software system.

We could partner another programmer with them so that if the programmer who is developing an application that is on the critical path falls ill the partner can pick up their work without having to be brought up to speed on the application. The partner should be working on an application that is not on the critical path and has at least 3 days of slack, assuming the average length of a flu bout is 3 days. The programmer should also have roughly the same skill set as the key programmer and have a comparable amount of experience. The cost of this strategy would certainly be less than the cost of flu shots. It will not reduce the likelihood of your key programmer catching the flu but will reduce the impact of the event if it were to happen.

Please note that this is not a tutorial on appropriate risk responses. The examples I’ve chosen merely illustrate the points I’m trying to make. Flu shots for the entire development team, or specific members of it, wouldn’t be feasible in smaller companies. You probably would not be able to dictate to the team  that they must be inoculated even if you had the means to provide the inoculation.

Enhancing the opportunity should provide a benefit to the project in terms of money, time, feature set, or quality. Let’s take the example we used in defining the approach. Let’s say we engaged the senior programmer to code the critical path application increasing our chances of getting to market with our software in advance of our planned launch date. Investing in a marketing campaign which takes advantage of our early launch date should generate extra sales. Just how many more sales it would generate would be impossible to forecast. You would need the help of a market analyst to forecast the increase as accurately as possible. The decision then becomes will the cost of the marketing campaign (or the change to the existing campaign), plus the cost of the senior programmer be less than the forecast revenue increase? Would there be a revenue increase without an additional marketing campaign (or change to the existing one)? Would that revenue increase exceed the cost of the senior programmer?

Transference

I used the example of purchasing insurance to illustrate this approach to risk. Insurance is certainly not the only option for this strategy, you could transfer the risk by engaging a vendor or sub-contractor to develop an application using a new technology that is a core competence of the vendor. You could also transfer the risk of introducing bugs into the User Acceptance Test environment by engaging your companies Quality Assurance group to do QA testing before turning the system over to the user community. You will need to weigh the cost of transference against the benefits that will be gained by the transfer.

Sharing is similar to transfer in that you engage a third party to increase the likelihood of the event happening or increasing the reward if it does. Let’s use the example of the new technology again. Our competent crew of programmers could certainly master the new technology with the proper training, if your project has the time to conduct the training. Outsourcing the development of the part of the system that uses the new technology would allow you to complete that part of the project in less time than could be expected if it were done in-house. That savings in time may allow you to get your system to market quicker which would increase sales. Outsourcing the development becomes a "sharing” strategy in that case.

Keep in mind that transferring a risk does not mean you have no further responsibility or actions to take. Would you abandon all driving safety measures just because your car is insured? Stop wearing a seat belt? Exceed the speed limit? Pass cars when you can’t see the oncoming traffic? Of course not, you’ll still take these precautions to avoid an accident because your insurance company will only cover the monetary costs of an accident, they can’t deal with the pain, suffering, or loss of life an accident may cause. Risk avoidance and mitigation strategies must still be monitored when a risk is transferred. Unit, function, and system testing must still be diligently done by the programming team even if you have transferred responsibility for QA testing to an external organization.

Contingency

Contingency planning requires an extra element that none of the other strategies employ: a trigger. The other strategies are designed to be implemented before the risk event occurs whereas a contingency plan is designed to be implemented as soon as the risk event happens (or the opportunity happens). The contingency plan requires a means of alerting the project manager to the risk event. The trigger should be something that the project manager will examine periodically to check for the risk event.

For this strategy, let’s use a construction project as an example. Your construction project is an office building and the dry wallers union contract ends August 31^st. That date occurs right in the middle of the installation of the interior walls for your building. You can’t do much to replace the dry wallers if there is a strike; employing non-union dry wallers would risk a walk-out of all the trades on the project and you can’t affort that risk. There is a product however, that can be installed in place of dry wall and can be installed by carpenters. The cost would be just about the same as dry wall making it an acceptable substitute. Your contingency plan is to order the substitute product and engage the extra carpenters. You would only do this in the case of a strike, it would be far too expensive to purchase the substitute product and engage the carpenters just in case there is a strike. You need to choose an appropriate trigger, one that will avoid unnecessary expense but will implement the substitution in time to preserve the project end date.

Unions must provide a strike deadline by law in most countries, states, or provinces. This deadline does not necessarily mean a strike will happen; there is still the possibility of a negotiated settlement at any time up to the last minute. It would be appropriate to define that strike notification as a trigger. You will issue a purchase order for the substitute product in case of the notification, in fact you could have your purchaser prepare the order in advance and then issue it to the vendor when you receive the notification. You will also issue the order for your carpenters to the appropriate union hall, etc. when you receive strike notification.

The key to implementing an effective contingency plan is to choose a trigger that will provide you with enough time to implement the plan and is cheap enough to make the plan cost effective. Let’s use an example from the software industry now. Let’s say you have a senior programmer working on an application on the critical path and that programmer is in the Reserves. They may be called up at any time and will be lost to the project if they are. The reservist will be given one week’s notice before they have to report (please keep in mind these are hypothetical situations) which would leave you one week to find a replacement. The skill set the programmer has is in short supply so you can’t identify someone in your organization to replace them. You could hire a contract programmer to fill the position. You would use the call-up notice as a trigger to implement the contingency plan. The trigger leaves you with a reasonable amount of time to implement the plan and won’t require you to pay a contractor while the reservist is still on the job.

Contingency Reserve

The strategies described above are all intended to deal with the risks identified with the project, but is it reasonable to expect every possible risk to be identified? The answer is no, it isn’t. The risks we don’t know about have the potential of de-railing our project even if we effectively avoid every risk we have identified. So how do we deal with the unidentified risks?

Unidentified risks are sometimes called the unknown unknowns. That term stems from the statement "I don’t know what I don’t know”. Since you don’t know anything about them, what the event is, how likely it is to happen, or what the impact would be if it does happen, none of the strategies described above will be effective in dealing with them. The only strategy available for dealing with the unknown unknowns is a contingency reserve. The contingency reserve can be either monetary or time.

When the contingency reserve is defined in terms of time the reserve may be called a buffer. You need to protect this buffer from the project stakeholders. There will be a strong temptation to fund requested changes from this buffer, resist this. The buffer should be monitored throughout the life of the project to ensure it is sufficient to carry the project through to completion. The buffer may be broken down into individual amounts for project phases, stages, or deliverables. The contingency reserve may also be calculated in this way. The reserve needed for the build phase of the project is likely to be greater than the reserve needed for design. The contingency reserve is depleted each time an unanticipated risk event occurs. The reserve will also be depleted if the avoidance or mitigation strategy for an anticipated risk proves ineffective.

The tips and tricks described in this article implement some of the best practices promoted by the PMI (Project Management Institute). These are taught in most PMP^® courses and other PMP^® exam preparation training products. If you haven't been certified as a PMP^® (Project Management Professional) by the PMI and would like to learn more about certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt, visit the three O website at: http://threeo.ca/aceit-features-c1288.php.