Defining Risk and its Componentshere.
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.
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
- 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.
- 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
- Reducing the probability of a collision
- Minimizing the effects of a collision
- 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
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:
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 CostsBuilding 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
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