Guidelines: Risk List

Risk List

A sorted list of known, open risks to the project, sorted in decreasing order of importance, associated with specific mitigation or contingency actions.

Topics

• Introduction
• Risk Management Strategies
• Types of Risks
  • Resource Risks
    • Organization
    • Funding
    • People
    • Time
  • Business Risks
  • Technical Risks
    • Scope Risks
    • Technological Risks
    • External Dependency Risks
  • Schedule Risks

Introduction

"The readiness is all."  - Hamlet V:ii:215

A project, like life, is uncertain. We identify risks not for their own sake, but to anticipate and mitigate them, if possible, or to respond to them when our mitigation strategies fall short.

Risk drives the iteration plans; iterations are planned around addressing specific risks, attempting to either bound the risk or reduce it. The risk list is periodically reviewed to evaluate the effectiveness of risk mitigation strategies, which in turn drives revisions to the project plan and subsequent iteration plans.

The key to managing risk is not to wait until a risk materializes (and becomes a problem or a failure) to decide what to do about it. Just as a change of a few degrees in the path of a transcontinental flight has a large effect on where the plane lands, managing risk early is nearly always less costly and painful than cleaning-up after the fact.

Risk Management Strategies

There are three main strategies [BOE91]:

• Risk avoidance. Reorganize the project so that it cannot be affected by that risk.
• Risk transfer. Reorganize the project so that someone or something else bears the risk (customer, vendor, bank, another element, and so on).  A specific strategy of risk avoidance.
• Risk acceptance. Decide to live with the risk as a contingency. Monitor the risk symptoms and decide on a contingency plan of what to do if a risk emerges.

If you decide to accept the risk, you still may want to mitigate the risk, i.e., take some immediate action to reduce its impact.

Types of Risks

It’s important to distinguish between direct and indirect risks. Simply put, a direct risk is one which we have some degree of control over; indirect risks are ones which we cannot control.

While one should not be ignorant of the indirect risks, they are of little consequence in a practical sense: since one cannot change them, there is little to be gained by worrying about them. Despite the fact that the world may end tomorrow, it also may not end, and if it does not we had better get on with the work at hand!

Sometimes, an indirect risk may really be a direct risk in disguise. For example, we may be dependent on some external supplier for a component or set of components. This appears to be an indirect risk, but by having contingency plans for those components, we can take control over the risk: we can choose alternate suppliers, or we can choose to develop the functionality ourselves. In many cases, we have more control than we think!

With indirect risks, you either have to figure out how to gain some degree of control over the risks, or you simply make note of them and move on. There is little point agonizing over what you cannot change.

Resource Risks

Organization

• Is there sufficient commitment to this project (including management, testers, QA, and other external but involved parties)?
• Is this the largest project this organization has ever attempted?
• Is there a well-defined process for software engineering? Requirements capture and management?

Funding

• Is the funding in place to complete project?
• Has funding been allocated for training and mentoring?

People

• Are enough people available?
• Do they have appropriate skills and experience?
• Have they worked together before?
• Do they believe the project can succeed?
• Are user representatives available for reviews?
• Are domain experts available?

Time

• Is the schedule realistic?
• Can functionality be scope-managed to meet schedules?
• How critical is the delivery date?
• Is there time to "do it right"?

Business Risks

• What if a competitor reaches the market first?
• What if project funding is jeopardized (the other way to look at this is to ask "what can assure adequate funding")?
• Is the projected value of the system greater than the projected cost? (be sure to account for the time-value of money and the cost of capital).
• What if contracts cannot be made with key suppliers?

Technical Risks

Scope risks

• Can success be measured?
• Is there agreement on how to measure success?
• Are the requirements fairly stable and well understood?
• Is the project scope firm or does the scope keep expanding?

Technological risks

• Has the technology been proven?
• Are reuse objectives reasonable?
• An artifact must be used once before it can be re-used.
• It may take several releases of a component before it is stable enough to reuse without significant changes.

External dependency risk

• Does the project depend on other (parallel) development projects?
• Is success dependent on off the shelf products or externally-developed components?
• Is success dependent on the successful integration of development tools (design tools, compilers, etc.), implementation technologies (operating systems, databases, inter-process communication mechanisms, etc.). Do you have a back-up plan for delivering the project without these technologies?

Schedule Risks

Experience shows that 85% of the risks have a direct or indirect impact on the schedule, and therefore implicitly on cost. Maybe 5% have only a cost impact. The rest have no direct impact on cost or schedule, but on quality for example.

If a deadline is the enemy, approach it smoothly with incremental deliveries. Avoid having one massive delivery in an attempt to make the schedule.

Some projects have real "drop-dead" deadlines. Software to analyze "live" the result of an election during election night, for example, has little value if it comes the week after the election. Or your software may be leap-frogged by competitors: they launch a product better than yours while you're still in the middle of construction. Suddenly, you're not in the game anymore - and you can't do much about it. In general, however, few projects have such a critical deadline. Delays mostly affect cost.

In general, make your schedule commitment equal to your best estimate, plus some reasonable contingency.

commitment = estimate + contingency

Others have advised setting schedule expectations to be equal to your fallback strategy, that is, to base them on your contingency plans, but this is a little too pessimistic because not all risks will actually materialize.

Schedule risks are integrated in some estimating and costing tools. For example in the COCOMO model, many of the cost drivers such as:

• complexity (cplx)
• real-time constraints (time)
• storage constraints (stor)
• experience (Vexp)
• availability of good tools (tool)
• schedule pressure (sced)

are actually risk factors.

More sophisticated techniques for risk management involve the use of Monte Carlo simulation, in which huge numbers of "scenarios" are run by a simulation tool to compute overall risks and contingencies [KAR96].