Risks

All projects involve risk; the risk that something will go wrong. Risk is not necessarily a bad thing, as no progress is made without taking some risk. However, there is a difference between unmanaged risk, e.g., gambling, and managed risk where the probabilities are well understood, and contingencies made. Risk is only a bad thing if the risks are ignored and they become problems. Risk management is assessing which risks are most likely to apply to the project, deciding a course of action if they become problems, and monitoring projects to give early warnings of risks becoming problems.

A specification should contain a list of the most likely and the most serious risks for a project. Against each risk note the probability of that risk becoming a problem. The following are examples of serious risks:

• Inaccurate metricsInadequate measurementExcessive schedule pressureManagement malpractice Inaccurate cost estimating Silver bullet syndromeCreeping user requirementsLow qualityLow productivity
• Cancelled projects

It is also useful input to project management if you include the impact on the schedule, or the cost, if the risk does become a problem.

Risk can be defined as "A measure of the uncertainty of attaining a goal, objective, or requirement pertaining to technical performance, cost, and schedule."

Risk always is present in the life cycle of a system. The system may be intended for technical accomplishments near the limits of the state of the art, creating technical risk. System development may be rushed to deploy the system as soon as possible to meet an imminent threat, leading to schedule risk.

All systems are funding-limited so that cost risk is present. Risk can be introduced by external constraints or can develop from within the program, since technical risk can create schedule risk which in turn can create cost risk.

There is no alternative to the presence of risk in system development. The only way to remove risk is to set technical goals very low, to stretch the schedule, and to supply unlimited funds. None of these events happen in the real world. No realistic program can be planned without risk. The challenge is to define the system and the program which best meet overall requirements, which allow for risk, and which achieve the highest chances of program success.

Fundamentals
Risk has two components - the likelihood that an undesirable event will occur and the consequence of the event if it does occur. The likelihood that an undesirable event will occur often is expressed as a probability. The consequence of the event is expressed in terms which depend on the nature of the event (e.g., pounds, performance loss). These two components are illustrated in the diagram below. The combination of low likelihood and benign consequences gives low risk, while high risk is produced by either high likelihood, severe consequences, or both.

Air transport provides two examples of events and their consequences - the event of arriving at the destination 15 minutes late usually has benign consequences, while the event of an airplane crash has harsh consequences and possible loss and injury. Most people would judge both of these events to have low risk; the likelihood of arriving 15 minutes late is high but the consequences are not serious. On the other hand, the consequences of a crash are very serious but are offset by the low likelihood that such an event will occur.