Managing Software Risks - Part 2

For a young project manager, starting work on a new project can be exciting. It represents an opportunity to show them what you can do! The euphoria associated with starting new projects often doesn’t last very long (a week or two is about average). Soon, reality sets in and you realize that the “aggressive schedule” you were handed is not even remotely achievable, the 3rd party software the project team is depending on is way behind schedule, and you don’t have the requirements defined or the resources you’ll need. Talk about being bummed out...

The software industry is known for many things - incredible technology, cowboys, ever-changing jargon, and what has been referred to as testosterone-driven decision-making. No matter how ridiculous the schedule is, no matter that there are several people on the project who all have the same initials (TBH - To Be Hired), no matter that product marketing hasn’t figured out what customers want..., we are expected to carry on as if everything will magically fall into place. When we are young and inexperienced, we naively believe that everything will fall into place. It is only through failure that we eventually learn that no amount of testosterone can change reality.

As we get older and hopefully wiser, we become more skeptical and more risk averse. This is why, in my opinion, the best project managers tend to be older and more mature. And, that’s why DeMarco and Lister [1] refer to Risk Management as “project management for grown-ups.” Only inexperienced, naive project managers act as if risks will not negatively affect their projects. Their more experienced peers know better. In fact:

“Software has long been regarded as one of the most risk-prone of all engineering activities. Risks such as schedule slips and cost overruns tend to occur on more than 50% of all large systems. Even more severe risks, such as cancellation of the project prior to completion or serious quality deficiencies are not uncommon.” [2]

In my June newsletter, I began a discussion on Managing Software Risks by identifying several different types of risk and introducing the notion of proactive risk management. In this month’s issue, we continue this discussion and look at some examples of techniques to manage different types of software risks.

Note to readers: For those of you who work in regulated industries such as medical devices, NASA, nuclear power, avionics, etc., you are probably very familiar with rigorous risk management processes. The process described here is intended for unregulated industries and as a result, is not as rigorous. However, it uses some of the same principles routinely applied in regulated industries.

Risk is something we deal with every day. In fact, it’s been drilled into our heads that projects with little or no risk are not worth doing. What this means is that every project we undertake probably has a considerable amount of risk.

On some software projects, we may acknowledge that risks are present but we fail to deal with them in a proactive manner. As a result, many software projects are negatively affected by known risks that were simply ignored. On other software projects, we may not even acknowledge that there are risks and proceed under the naive assumption that somehow, things will work themselves out. What a way to run a business!

What is Risk Management?

• Risk is defined as a possible future event that will lead to an undesirable outcome. [1]

• Risk management is the process of thinking out corrective actions before a problem occurs, while it’s still an abstraction. The opposite of risk management is crisis management, trying to figure out what to do after it happens. [1]

Risk management is a proactive process that attempts to identify as many potential risks as possible, assess the potential impact of each of these risks, rank them in priority order, and then manage those that are the most critical.

Risk management is a set of planned actions that can effectively reduce the impact of risks on most software projects. Some training in basic risk management techniques is necessary in order for these techniques to be applied effectively.

Learn more about risk management for embedded systems...

Learn more about risk management training for project managers...

Effective risk management has become increasingly important, given the exponential increase in software complexity as illustrated below. [3] The more complex your software is, the more critical it is that you have an effective risk management process.

Cultural Barriers

In far too many organizations, Management makes it more difficult, if not impossible, to manage risk. DeMarco and Lister [1] identify cultural barriers to risk awareness present in these organizations. These barriers are often in the form of “unwritten rules” that make it difficult to even discuss potential risks. For example, have you ever heard your boss say:

• “Don’t be a negative thinker.”

• “Don’t raise problems unless you have a solution.”

• “Don’t raise a problem unless you can prove it is a problem!”

• “Don’t raise a problem unless you are willing to take responsibility for the solution.”

If you have heard these words, then it’s likely that risks are being swept under the proverbial rug. People in these organizations who try to identify risks may be accused of being a whiner, not being a team player, or of negative thinking. Ironically, it is precisely this negative thinking that can often prevent an organization from experiencing costly and embarrassing failures. In some organizations:

“The very term, risk, often has negative connotations and the consequent cultural pressure to deny its existence thus exposing the project to unwanted surprises leading to difficulties and failures.” [4]

Clearly, a prerequisite for effective risk management is a culture where open and frank discussions of risk are encouraged.

Dealing With Risk

DeMarco and Lister [1] identify four ways to deal with risk:

• You can avoid risk

You avoid risk when you decide not to do a project or a part of a project that has risk. You may decide to cancel a project or remove risky features.

• You can contain risk

Containing risks means you plan to deal with them when they occur. You may set aside additional time and resources to deal with an internal risk, for example.

• You can mitigate risk

Mitigating risk means that you take proactive steps to minimize the impact of a risk, should it occur.

• You can evade risk

Evading risk means you take no action at all - other than hoping that the risk doesn’t materialize. Of all ways of dealing with risk, this is clearly the least expensive, but also the least effective.

A Simple Risk Management Process

For those of you who’ve never done this before, the most fundamental risk management process includes these activities:

• Identify risks

• Assess and prioritize risks

• Monitor and control risks

In order to realize the most benefit, the best time to start worrying about risk is obviously at the beginning of a project. Like most things worth doing, it’s never too late to start, and you can apply this process to projects already underway.

Identify Risks

The effectiveness of any risk management process is based in large part on how good a job you do at identifying risks. Being able to spot risks is a skill that can be learned from experience. If you have never done this before, the first place to look is the last project. Conduct a project retrospective and gather information from problems identified during the retrospective. It’s likely these problems were caused by risks that were ignored. To find out, use root cause analysis to identify the real root cause of the problem.

Training in Project Retrospectives...

Training in Root Cause Analysis...

The next place to look is the project team. Create an environment where risks can be openly discussed and debated. Ensure that everyone on the team has an opportunity to contribute in a manner that is safe and non-threatening. The people doing the work usually know what the biggest risks are since they are likely to be directly affected by them.

Lastly, look at the taxonomy of software risks assembled by the Software Engineering Institute. [4] This is a list of potential risks that you can review and then determine if any of these risks apply to your project.

In the SEI taxonomy, risks are grouped into three categories: Product Engineering, Development Environment, and Program Constraints. In each category, there are several risk areas and for each risk area, there are questions that you can ask about that area in order to assess whether or not it is likely this risk is present on your project.

For example, one of the areas of risk identified is Schedule. Here is a sample of the questions you can ask in order to determine what risks, if any, are present...

Schedule - Is the schedule inadequate or unstable?

• Has the schedule been stable?
  
  
• Is the schedule realistic?
  
  • (If yes) Is the estimation method based on historical data?
  • (If yes) Has the method worked well in the past?
    
    
• Is there anything for which adequate scheduling was not planned?
  
  • Analysis and studies
  • QA
  • Training
  • Maintenance courses and training
  • Capital equipment
  • Deliverable development system
    
    
• Are there external dependencies likely to impact the schedule?

Read more about the SEI Taxonomy of Software Risks...

Once you have done a thorough job of identifying risks, the next task is prioritizing them.

Assess and Prioritize Risks

Assessing and prioritizing risks involves assessing the likelihood that a risk will occur and understanding the potential impact to the project if the risk does occur. The purpose of the assessment is to:

• identify early warning signals - signs that give you time to act proactively rather than reactively
  
  
• assess likelihood - how likely is it this risk will occur
  
  
• assess impact - to the project should the risk occur
  
  
• identify a Plan B - a mitigation strategy if the risk does occur

There have been many schemes for doing this assessment, and if you are doing this for the first time, I recommend using a very simple tool...

An example of a simple risk assessment tool...

Once the assessment is completed and the risks are prioritized, the next task is to monitor and control those that do occur...

Monitor and Control Risks

Monitoring and controlling risks means that you are constantly watching the Early Warning Signals for the highest priority risks. It also means that you have a Plan B in place for each of these risks. Should you need to use a Plan B, you have to make sure that it is effective in reducing the impact to an acceptable level. If it’s not, you need to find a more effective mitigation.

It’s at this stage of the process where you will reap the fruits of your hard work. Risks will occur, but if you have done your job, you will have early warning and you will be prepared to deal with them. In many cases, the Plan B you have will work and the project impact will be minimal. Remember the Boy Scout motto: Be Prepared! That’s what risk management is all about. - being prepared for the inevitable risks that do occur.

Summary

Proactive risk management is a critical skill for successful organizations. Being able to anticipate and deal with risk is essential to avoid disaster.

And the disasters are still happening. A very recent article [5] on IT software project failures identifies several reasons that IT software projects were cancelled. Each of the reasons in the list below could be a potential risk on your project.

Remember that the biggest risk on any software project is n ot knowing what the risks are!