Guidelines: Risk List
Topics
"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.
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.
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.
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?
- Are there budget limitations such that the system must be delivered at a
fixed cost or be subject to cancellation?
- Are cost estimates accurate?
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"?
- 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?
- 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?
- 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.
- 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?
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].
| |
|