Re: Risk Factor Adjustments
- Risks come in a number of flavours. Its probably best to give examples, so
here it goes:
1. An approach to a problem might not work.
2. A resource may not be available when needed.
3. A piece of hardware may not be compatible with the solution chosen.
4. A problem may be more complicated than first estimated.
5. A supplier may fail to meet a deadline.
6. Circumstance may require a last minute specifications change.
There are really two things you can do with a risk: mitigate or avoid. As
an example let's assume you have a PBI that can be solved one of two ways,
the first is potentially the best way (better results, easier to program,
easier to maintain) but you might have identified that there a number of
factors upon which it depends which are unstable. The second approach is,
for some reason, less attractive than the first, but contains very little
risk. You can avoid the risk entirely by using the second solution. You
can mitigate the risk from the first solution by taking any number of
actions, depending on what those risks are. For instance you might decide
that you should start working on the PBI earlier, in order to give extra
time to deal with problems as they arise, you might order required parts
immediately in order to avoid problems with the parts being backordered and
For risk number 6, above, the best way to avoid the risk might be to delay
work on it until the last possible moment. You could try to mitigate the
risk by identifying what part of the spec might change, and designing the
solution such that aspect is table driven, or that the design is modular
and isolates that part to minimize changes and restesting. In the latter
case, I'd be tempted to immediately create a PBI called "Item XX spec
change update" so that no one forgets we might need to go back and rework
I don't think you can come up with a formula like "Risk value for this PBI
is 5, so apply a 1.23 factor to the time estimate". The most important
thing, is that risks are identified, their likelyhood is evaluated and that
there is a concious decision about whether the risk can or should be
avoided, mitigated or ignored and how you'll do that.
What I'm not sure about is dealing (in a formal way) with risks that aren't
associated with a specific PBI. These are like non-functional specs.
Instead of "The system must be able to support 300 tps on a weekday", you'd
have, "Once the software is completed the hardware is found not capable of
supporting 300 tps on a weekday".
Lawyers' Professional Indemnity Company