Uncertainty and Risk in Software Development (2 of 3)

Defining Risk and its Components

Part 1 of 3 is here.

There are future events whose impact can have a negative outcome or consequence to our project. A future event can only be risky if the event is uncertain. If an event is certain then it is no longer a risk even if the entire team does not perceive the certainty of the event.

Risks always apply to a measurable goal that we are trying to achieve; if there is no goal there can be no risk, i.e. a project can't have schedule risk if it has no deadline.

Once a goal has been impacted by a risk we say that the risk has triggered. The severity of the outcome depends on how far it displaces us from our goal. Once triggered, there should be a mitigation process to reduce the severity of the possible outcomes.



Before looking at software project risks tied to these goals, let's make sure that we all understand the components of risk by going through an example.

Risk Example: Auto Collision

Let's talk about risk using a physical example to make things concrete. The primary goal of driving a car is to get from point A to point B. Some secondary goals are:

• Get to the destination in a reasonable time
• Make sure all passengers arrive in good health.
• Make sure that the car arrives in the same condition it departs in.

There is a risk of collision every time you drive your car:

• The event of a collision is uncertain
• The outcome is the damage cost and possible personal injury
• The severity is proportional to the amount of damage and personal injury sustained if there is an accident
• If there is loss of life then the severity is catastrophic

A collision will affect one or more of the above goals. Risk management with respect to auto collisions involves:

• Reducing the probability of a collision
• Minimizing the effects of a collision

There are actions that can reduce or increase the likelihood of a collision is:

• Things that reduce the chance of collision

• Understanding safe driving techniques  
• Driving when there are fewer drivers on the road
• Using proper turn signals
• Things that increase the chance of collision
• Drinking and driving
• Driving in heavy fog 
• Wearing sunglasses at night

By taking the actions that reduce a collision while avoiding the actions that increase it we can reduce the probability or likelihood of a collision.

Reducing the likelihood of a collision does not change the severity of the event if it occurs. The likelihood of an event and its consequence are independent even if there are actions that will reduce the likelihood and consequences of an event, i.e. driving slowly.

If an auto collision happens then a mitigation strategy would attempt to minimize the effect of the impact. Mitigation strategies with respect to auto collision are:

• Wear a seat belt
• Drive a car with excellent safety features
• Have insurance for collisions
• Have the ability to communicate at all times (i.e. cell phone, etc)  

Having a mitigation strategy will not reduce the chance of a collision, it will only lessen the severity.

Goals of a Software Project

The primary goals of a software project are:

1. Building the correct software system
2. Building the system so that its benefits exceed its costs (i.e. NPV positive)

Building the Correct Software System

What is the correct software system? Cartoons similar to this one are easily found on the Internet:

The correct system is shown in the last frame of the cartoon; so let's define the  correct system as what the customer actually needs. To build the correct system we will need to have correct requirements. 

How Long Will The Project Take?

Let's assume we have complete and consistent requirements for a correct system. How long will it take to build this system?  One approach is to take a competent team and have them build out the system without imposing a deadline.  Once the system is built we would have the actual time to build the system (T_build) .

T_build  is theoretical because unless you are using an Agile methodology you will want to estimate (T_estimate) how long it takes to produce the system before you start.  Nonetheless, given your resources and requirements  T_build does exist and is a finite number; as one of my colleagues used to say, "the software will take the time that it takes".

Most executives want to know how long a project is going to take before the project starts.  To do this we take the requirements and form an estimate (T_estimate) of how long the system will take to build.  The key point to note here is that the actual time to build,  T_build, and the estimated time to build the system, T_estimate , will be different.  The key thing to keep in mind is that T_estimate is only valid to the extent that you use a valid methodology for establishing an estimate.

Building the System so that its Benefits Exceed its Costs 

Building a system so that its benefits exceed its costs is equivalent to saying that the project puts money on the organization's bottom line. We hope that an organization will do the following:

1. Define the system correctly (project scope)
2. Assess the financial viability of the project (capital budgeting)
3. Establish a viable project plan

Financial viability implies that the available resources will be able to produce the desired system before a specific date (T _viable). If T_build < T_viable then the organization will have a financially successful project, if T_build > T_viable then the organization will have a financial failure.

The problem is that we don't know what T_build is unless we build out the software system first, but we don't want to build the project if it is not viable, i.e. T_build > T_viable and that we have a financial failure. We need to have a reasonable expectation that the project is viable BEFORE we build it out. Therefore we use a proxy by estimating the time (T_estimate) it will take to build the software from our project plan.

Once we have a time estimate then we can go forward on the project if T_estimate < T_viable. The estimate, T_estimate, for a project can be done in multiple ways:

1. Formal cost estimation techniques
2. Senior management declared deadlines
3. SWAG  estimates  

Software Project Risks

There are several primary risks for a software project:

• Schedule risk
• Estimation risk
• Requirements risk
• Technical risk

We often confuse schedule risk and estimation risk. Schedule risk is the risk that the tasks on the critical path have been under estimated and the project will miss the end date (i.e. T_build > T_estimate). A project that takes longer than the estimate is not necessarily a failure unless T_build > T_viable.
You can only talk meaningfully about schedule risk in projects where:

• formal estimation techniques are used
• proper task dependency analysis is done
• project critical path is identified

Most of us do not work for organizations that are CMM level 4+ (or equivalent), so you are unlikely to be using formal methods. When the project end date is arbitrary (i.e. method 2 or 3 above) it is not meaningful to talk about schedule risk, especially since history shows that we underestimate how long it will take to build the system, i.e. T_estimate <<<  T_build. When formal methods are not used (i.e. method 2 or 3 above) then the real issue is estimation risk and not schedule risk.

The real tragedy is when an IT departments attempt to meet unrealistic dates set by management when a realistic date would still yield a viable project (below). Unfortunately, unrealistic deadlines will cause developers to take short cuts and usually cripple the architecture. So that when management gives you additional time after their date fails, the damage to the architecture is terminal and you can't achieve the initial objective.

Requirements risk is the risk that we do not have the correct requirements and are unable to get to a subset of the requirements that enables us to build the correct system prior to the project end date. There are many reasons for having incorrect requirements when a project starts:

• The customer can not articulate what he needs
• Requirements are not gathered from all stakeholders for the project
• Requirements are incomplete
• Requirements are inconsistent

Technical risk is the risk that some feature of the correct system can not be implemented due to a technical reason. If a technical issue has no work around and is critical to the correct system then the project will need to be abandoned.

If the technical issue has a work around the:

• If the technical issue prevents the correct system from being built then we have requirements risk
• If the technical work around takes to long it can trigger schedule risk

Next blog:

• Discuss other risks and how they roll up into one of the 4 risks outlined above
• Discuss how risk probability and severity combines to form acceptable or unacceptable risks
• Discuss risk mitigation strategies
• Discuss how to form a risk table/database
• Discuss how to redefine victory for informal projects