Upcoming Event Announcement: QA Labs, Software Productivity Center, and Momentum Technologies will be presenting a breakfast seminar August 21st in Downtown Vancouver on ways to increase your ability to succeed with outsourcing engagements. If you manage outsource vendor relationships, work with outsource firms in your projects, or would like to learn the tips and tricks that can make or break an outsourcing engagement, this presentation is for you.

This seminar is by invitation only. For an invitation, please email services@qalabs.com.

Risk in Software Development Series

Risk Management

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.