|
"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?
-
A work product 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 made obsolete 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].
|
