christopher bischoff's List: Risk Management

• From the business investor’s perspective, there are three categories of risk[2].

   
   
  1. Delivery Risk. The risk that the software is NOT delivered on time, on budget, and to the required quality.
   
  2. Business Value Risk. The risk that the project does not deliver the value expected.
   
  3. Existing Business Model Risk. The risk that the project actually damages the existing organisation.
   
   

  Agile and Lean Software Development Techniques address the first category of risk. Feature Injection, Lean Start Up techniques and Business Value are starting to address the second category of risk. Real Options[3] can be used to manage all three types of risk.

• business investor’s perspective, there are three categories of risk[2].

   
   
  1. Delivery Risk. The risk that the software is NOT delivered on time, on budget, and to the required quality.
   
  2. Business Value Risk. The risk that the project does not deliver the value expected.
   
  3. Existing Business Model Risk. The risk that the project actually damages the existing organisation.
   
   

  Agile and Lean Software Development Techniques address the first category of risk. Feature Injection, Lean S
• Most established IT Risk Management literature focuses on delivery risk. The change control example above shows that delivery risk is intertwined with the other two. All three must be considered in a holistic manner.
• Existing business model risk is the risk that delivering on a commitment may cause damage to the existing business model. One of the most famous examples is Hoover’s free flight promotion[4]. Hoover announced a special offer of “Buy a washing machine and get a free flight to the USA” (from the UK). This promotion turned out to be so successful that it nearly destroyed the company

• Risk Assessment Questions

   
   
  1. Can the commitment be reversed?
   
  2. How long does it take to reverse the commitment?
   
  3. How long can the organization survive in a broken state?

• Commitments versus reversible decisions

   

  When implementing change into a system, consider whether the change is a commitment or whether it is a reversible decision. Let’s clarify this with some examples:

   
   
  1. Consider you are driving around an unfamiliar area. If you make a wrong turn: 
      
     • a) It’s a reversible decision when you are on a two-way street. You can always turn around and retrace your steps
      
     • b) It’s a commitment when you are going down a one way street as you can no longer retrace your steps.
      
      
   
  2. Consider you are lost in the woods and you come across a twelve foot drop. You can get down but there is no way back up. Players of video games like Tomb Raider will be familiar with this situation. 
      
     • a) It’s a reversible decision when you can set up a rope/vine/branch to help you climb back up[6].
      
     • b) It’s a commitment when you jump down and have not prepared a way of going back up.
      
      
   
  3. Consider changing the structure of the database so that the old code will not work against it. 
      
     • a) It’s a reversible decision if you have backed up your tables / database which can be restored in the event of a problem.
      
     • b) It’s a commitment if the structure upgrades are permanent and you are unable to create proper back-ups to restore.
      
      
   
  4. Consider you are about to pull your front door closed. 
      
     • a) It’s a reversible decision when you have your keys with you
      
     • b) It’s a commitment when you forgot your keys.

• Release timing

   

  When the timing is critical for the investor and other stakeholders and failure is more expensive to them, the time to reverse the change is also significantly reduced. A non-exhaustive list of times when the risk of a failure for the investor is increased:

   
   
  • At month end/year end for financial businesses.
   
  • Before Christmas /Eid for a retail or holiday company.
   
  • Before or during peak times.
   
  • At a time when key staff are unavailable.
   
  • When other significant change is going on in the organisation.
   
  • When the organisation is under increased scrutiny of some kind.

5 more annotations...

• Risk != uncertainty (unless you’re a Knightian frequentist, and then you don’t believe in measurement anyway), though if you were to account for risk in an equation, the amount of uncertainty would be a factor.
• risk != “likelihood” (to a statistician or probabilist anyway). Like uncertainty, likelihood has a specific meaning.

• What is risk? It’s a hypothetical construct, something we synthesize in our brains to describe the danger inherent in the various inputs we’re processing around a certain situation. Depending on the situation, it can be either very difficult to create an “immaculate” equation for risk (such as R = T x V x I), or in many cases, impossible.

   

  As an example, in IT, and especially for a large enterprise, we may have a complex adaptive system with characteristics of strong emergence. We see the same thing in medicine and various fields of biology. As such, point probabilities are pretty much impossible, or require so much simulation effort as to be difficult to produce.

   

  Also, because it is a hypothetical construct we create in our brains, risk is also subject to the perspective of the observer. It is poly-centric. And because humans have a very difficult time divorcing their own risk tolerance derived from their own internal ad-hoc assessment from the information they have and the way they’re required to use that information, the true nature of the inherent danger, the majority of the “risk” is left unexpressed.

• Bottom line, IT risk is something created without being understood. It is the most important concept in information security, and the most abused. Until we have data, evidence of significant quality (see evidence-based practices) we cannot derive sane models, we cannot begin to understand the problem space.

   

  As such, “risk” probably encompasses all of the above statements made in this thread, while in truth not resembling them at all (1).

2 more annotations...

• On that particular topic, I cannot better the words of Richard Feynman, from his famous minority report on the Challenger Space Shuttle disaster:

   

   

  It appears that there are enormous differences of opinion as to the probability of a failure with loss of vehicle and of human life. The estimates range from roughly 1 in 100 to 1 in 100,000. The higher figures come from the working engineers, and the very low figures from management. What are the causes and consequences of this lack of agreement? Since 1 part in 100,000 would imply that one could put a Shuttle up each day for 300 years expecting to lose only one, we could properly ask "What is the cause of management's fantastic faith in the machinery?"
• Ultimately, risk management is a numbers game; you multiply a wild-ass guess by a fudge factor. Worse, the potential cost of failure is estimated in as a factor, too. So you're trying to balance an unjustified estimate of cost of failure against a wild-ass guess multiplied by a fudge factor. Generally, what is really going on is that risk management is used as a sort of statistical shell-game to manipulate the perceived value of security when dealing with a clueless senior manager. Bluntly: it's lying with statistics. Those who engage in it do so because they think their managers are idiots. The fact that they are often right is sad, but should not surprise anyone.
• To summarize it: you can only play Las Vegas odds-maker when you're working on small numbers of variables and extremely well-understood conditions.

1 more annotation...