How can we measure risk?First, why do you want to measure risk?
Here’s an interesting question: How can we measure risk?
Well first, what is “risk”?
As always, there are various definitions. But let’s use this one for today:
Risk is the probability and magnitude of potential loss.
“Loss” is still pretty broad. When we’re talking about software development, or more broadly business, there are countless forms of loss we might encounter:
- Loss in sales
- Loss in productivity (due to turnover, inadequate training, or countless other reasons)
- Loss due to damage of equipment
- Opportunity cost
- Literal loss (Bob misplaced his iPhone)
Some of those can be pretty tricky to measure. Productivity Loss and Opportunity Cost in particular, are hard to measure, because we don’t always know the baseline.
But it’s worse than that, becuase we’re trying to measure risk, not loss. Now we need to know the probability of such a loss, as well. How on earth do we do that?
Well, that depends. Classic consultant answer.
It depends on why we’re measuring the loss.
When insurance companies calculate risk to insure against potential loss, they typically look at historical data. How often are iPhones lost or stollen? With this information, they can calculate the risk of Bob losing is iPhone, and provide a concrete price for an iPhone insurance policy.
But when I hear people ask things like “How do we measure risk?” I think they’re rarely looking to calculate an insurance premium. More often, they’re interested in marking progress toward a goal, such as reduced down time, or better customer retention.
If these are our goals, measuring becomes fairly straight forward. If we’re trying to reduce down time, all we need to do, really, is measure down time over time (perhaps per week or per month), and see if the number improves.
This isn’t exactly the same as risk. If we have a 10% chance of monthly downtime, for instance, some months we’ll have 0 downtime, and other months we may have 20% downtime. But if our goal is to reduce the risk of downtime, reducing actual downtime is a pretty close proxy.
The first step I always like to take when answering “How do we measure X?” is asking “Why do we want to measure X?” This helps us both focus on the problem at hand, as well as know the precision our measurement needs. For more on this topic, I highly recommend the book How to Measure Anything: Finding the Value of Intangibles in Business by Douglas Hubbard.
Maybe you have a more nuanced reason to measure risk? Let me know what it is.
Nobody ever got fired for buying IBM
If this claim is true, there are only two possible explanations. Neither one is very convincing.
The uncertainty of software development bites again
A task I expected would take an hour has taken 10, with no end in sight.