Artifacts > Project Management Artifact Set > Risk List > Guidelines


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 To top of page

"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 To top of page

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, that is, take some immediate action to reduce its impact.

Types of RisksTo top of page

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 To top of page

Organization
Funding
People
Time

Business Risks To top of page

  • 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 To top of page

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?
  • Are the project development time scales short and inflexible?
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.
  • Are the transaction volumes in the requirements reasonable?
  • Are the transaction rate estimates credible? Are they too optimistic?
  • Are the data volumes reasonable? Can they be held on currently available mainframes, or, if the requirements lead you to believe a workstation or departmental system will be part of the design, can the data reasonably be held there?
  • Are there unusual or challenging technical requirements that require the project team to tackle problems with which they are unfamiliar?
  • Is success dependent on new or untried products, services or technologies, new or unproven hardware, software, or techniques?
  • Are there external dependencies on interfaces to other systems, including those outside the enterprise?  Do the required interfaces exist or must they be created?
  • Are there availability and security requirements which are extremely inflexible (for example, "the system must never fail")?
  • Are the users of the system inexperienced with the type of system being developed?
  • Is there increased risk due to the size or complexity of the application or the newness of the technology?
  • Is there a requirement for national language support?
  • Is it possible to design, implement, and run this system? Some systems are just too huge or complex to ever work properly.
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, and so on), implementation technologies (operating systems, databases, inter-process communication mechanisms, and so on). Do you have a back-up plan for delivering the project without these technologies?

Schedule Risks To top of page

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].

Copyright  © 1987 - 2001 Rational Software Corporation


Display Rational Unified Process using frames

Rational Unified Process