Risk management can be defined as creating and maintaining plans for controlling real and perceived risks paired with monitoring the effectiveness of those plans.

DO NOT wait until a risk becomes reality before deciding what to do about it. A software development project contains many elements of uncertainty that manifest themselves as risks. And in most cases it will be too late to do anything about them if they become reality. You end up managing the consequences rather than the risk. Risk management allows you to be active in attempting to predict what could go wrong and in addressing those potential problems as early in the project as possible. Remember Smoky the Bear: You too can prevent forest fires. Or in this case, risks becoming reality.

Risk management needs to start at the beginning of a project to be of benefit. Risks feed into the project plan and help determine how you run your project while trying to address the risks in order of priority. Managing risk early is almost always less costly and painful than cleaning-up after the fact. However, introducing risk management at any point in your project will give you some benefit; it is better late than never.

The process of risk analysis and mitigation is comprised of three phases: risk identification, risk estimation and evaluation, and risk planning. These three phases allow one to identify the risks, judge their potential impact, and plan to avoid or minimize the risks. Identifying risks allows you to evaluate and plan for them, and to be prepared to respond when mitigation strategies fail. Much of learning to judge risks and planning ways to address them comes with experience; it is an acquired skill.

The Risk Management Plan

The Risk Management Plan details how to manage the risks associated with a project. It details the risk management tasks that will be carried out, assigned responsibilities and any additional resources required for the risk management activity. In a smaller scale project, this plan may be simply a “Top 10” risk list that is reviewed at regular project status meetings.

The first step in developing your Risk Management Plan is to brainstorm the current risks.

No matter what stage your project currently is in you need to know the kinds of risk you are faced with now, and most likely will be faced with throughout the rest of the project, before you start trying to decide upon strategies for managing those risks. Create an initial list of risks and use this list to prioritize and monitor the risks throughout the project. The risk list should be reviewed regularly to keep it up to date and to evaluate the effectiveness of risk mitigation strategies. You will find the results of these reviews can drive revisions to the project plan itself.

Next, you have to make someone responsible.

Someone on the project needs to be responsible for collecting and recording risks as they are identified, tracking status, and scheduling review meetings. Also a group of concerned stakeholders should be identified. These stakeholders are drawn from both managerial and technical personnel on the project, and should include the project manager, the leads for the test and development teams, and the product manager or customer representative. This group needs to consistently attend the risk review meetings.

Once you have your initial risks recorded and someone has taken responsibility for keeping track of those risks, identify an attribute of the risk that you can measure for each risk.

You can pair these measures with indicators, or thresholds, that tell you when each risk is about to (or has) become a reality. Tracking these trends will help take the guesswork out of whether your mitigation strategies are working. And they will allow you to see how much room you have. The approach that will be used to monitor and reduce each risk should be clearly documented and accessible to the project team. The approach should also outline a contingency plan in case the risk occurs despite any mitigation efforts.

Finally, you need regular reviews.

It is extremely important to realize that risk management is only effective if it is an on-going activity. All too often a project team will produce the initial risk list, update it once, and then put it on the shelf and forget about it, becoming embroiled in fighting the fire of the day. The Risk Management Plan should outline a schedule for regular risk status reports and risk review meetings.

Risk is often defined as the combination of the likelihood of a problem occurring and the impact of the problem if it were to occur.

• Risk concerns future happenings.
• Risk involves change in mind, opinion, actions, or places.
• Risk involves choice and all the uncertainty that that choice itself entails.

Risk is something with which we are all somewhat familiar. We know that it is risky to jump out of planes, or invest money in the stock market. But we don’t always think of software development as risky – particularly if our software is not mission critical (that is, people’s lives don’t depend on it). While insurance companies and actuarial analysts spend most of their days dealing with risk, software development teams often spend a mere fraction of their project schedule thinking about risk.

In this series, we introduce you to some basic concepts and principles of risk management, and how these concepts and principles can be applied to software development projects to increase the probability of success.

In everyday life a risk is an exposure to the chance of injury or loss – a thing or course of action involving uncertainty and therefore danger. A risk, in the software industry, can be anything that may threaten the successful completion of a project: increased costs, delayed completion, loss of quality, or loss of market-share.

Two factors can be used to determine the magnitude of a risk: likelihood of occurrence, and impact of occurrence. When combined into a single indicator the risk can be judged relative to other risks as High, Moderate, or Low.

Many organizations still do not identify risks at the beginning of a project, or review and update those risks throughout the course of the product lifecycle. Estimating and planning is done as if all variables are known, and outcomes certain.

The reality is that risk results from changes in development personnel, market conditions, customer expectations, and even business conditions for the development organization.

Experience shows that the large majority of risks have a direct or indirect impact on schedule, and therefore implicitly on cost. Some have a direct impact on cost. The rest may have no direct impact on cost or schedule, but affect other areas of the project such as quality.

Some common risks include: the technical requirements of the product or system, constraints placed upon the project or product by the customer(s), budget, or schedule.

Types of Risks

It’s important to distinguish between direct and indirect risks. A direct risk is one over which some degree of control is possible whereas an indirect risk is one that cannot be controlled.

While one should not be unaware of the indirect risks, they are of little consequence in a practical sense: since one cannot change them, there is little to be gained by worrying about them.

Sometimes, an indirect risk may actually be a direct risk. For example, you may be dependent on an external supplier for a component or platform for your product. This appears to be a risk that cannot be controlled. But, by having contingency plans for those components, you can take control of the risk: develop a relationship with the supplier so they listen to your needs, choose alternate suppliers, or choose to develop the needed components yourself.

With indirect risks, you either have to gain some degree of control, or you need to just make note of them. Having them documented will allow you to easily revisit the risk and the decisions that were made as necessary.

To help determine if your project would benefit from Risk Management, look at your project and ask yourself the following questions.

• Is the project scope firm or does the scope keep expanding?
• Are estimates accurate?
• Is there time to “do it right”?
• Has the technology been proven?
• Are the users of the system experienced with the type of system being developed?

These are just a few of the questions to ask yourself when looking for potential risks related to your project. If your answer was “No” or “Unknown” to any of them, it means that you are facing at least one risk to your project being a success.