Uncertainty and Risk in Software Development (2 of 3)
[In case you missed it, part 1 of 3]
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
Things that increase the chance of collision
- Drinking and driving
- Driving in heavy fog
- Wearing sunglasses at night
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.
- 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)
Goals of a Software ProjectThe primary goals of a software project are:
- Building the correct software system
- Building the system so that its benefits exceed its costs (i.e. NPV positive)
Building the Correct Software SystemWhat 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 (Tbuild) .
Tbuild is theoretical because unless you are using an Agile methodology you will want to estimate (Testimate) how long it takes to produce the system before you start. Nonetheless, given your resources and requirements Tbuild 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 (Testimate) of how long the system will take to build. The key point to note here is that the actual time to build, Tbuild, and the estimated time to build the system, Testimate, will be different. The key thing to keep in mind is that Testimate 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:
- Define the system correctly (project scope)
- Assess the financial viability of the project (capital budgeting)
- Establish a viable project plan
Financial viability implies that the available resources will be able to produce the desired system before a specific date (Tviable). If Tbuild < Tviable then the organization will have a financially successful project, if Tbuild > Tviable then the organization will have a financial failure.
The problem is that we don't know what Tbuild 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. Tbuild > Tviable 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 (Testimate) 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 Testimate < Tviable. The estimate, Testimate, for a project can be done in multiple ways:
Software Project Risks
- Schedule risk
- Estimation risk
- Requirements risk
- Technical risk
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
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.
- The customer can not articulate what he needs
- Requirements are not gathered from all stakeholders for the project
- Requirements are incomplete
- Requirements are inconsistent
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
- 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
[In case you missed it, part 1 of 3