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

Pages: 1 2 3