Loading ...
Sorry, an error occurred while loading the content.
 

Re: Risk Factor Adjustments

Expand Messages
  • David A Barrett
    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
    Message 1 of 2 , Jun 11, 2004
      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
      so on.

      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
      that part.

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


      Dave Barrett,
      Lawyers' Professional Indemnity Company
    Your message has been successfully submitted and would be delivered to recipients shortly.