Adapted from War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age by Mark Schwartz.
It turns out that people are pretty terrible at assessing probabilities and risk. In my last book, A Seat at the Table, I cited several examples to make this point—examples that I love because even knowing the right answer I still can’t convince myself it is right.
The first example had to do with the TV game show Let’s Make a Deal, in which the contestant is asked to choose one of three doors. Behind one, the contestant is told, is a car the contestant will win if he or she guesses correctly. Once the contestant guesses, the host opens one of the other doors to show that there’s no car behind it. He then points out that two closed doors remain—the one the contestant chose and the third one—and asks if the contestant wants to switch doors. Since there are now only two doors, each seems to have a 50% chance of hiding the car, so it doesn’t matter, right? But the correct strategy is always for the contestant to switch doors—doing so doubles his or her chances of winning. Our intuition hesitates to accept that, even when it’s carefully explained.
Another example that I cited looks at probability in the world of disease. Let’s say you’re tested for a rare disease that occurs in one out of every one thousand people. The doctor informs you that the test is 99% accurate: that is, if you have the disease, the test will be positive 99% of the time, and if you don’t have it, the test will be negative 99% of the time. Unfortunately, the test comes back positive. How worried should you be? Not very, it turns out. With these parameters, the chance that you actually have the disease turns out to be only about 9%.
We have a strong tendency to identify risk in all the wrong places and miscalculate the likelihood of outcomes. Traditional project management, for example, leads us to believe that projects have cost, schedule, and scope risks. A project manager following Project Management Body of Knowledge (PMBOK®) best practices will keep a risk register and make plans for mitigating those risks.
But these delivery risks are not the right risks to be concerned about. The real risks are (1) the risk of not accomplishing our business objectives, and (2) the risk of not accomplishing them in the quickest, most cost-effective way. To those I’ll add (3) the risk of unintentionally exceeding the budget. Cost, schedule, and scope are at best only proxies for these real concerns.
(1) The Risk of Not Accomplishing our Business Objectives
If your goal is to increase the number of cases each employee can process in a day, say from seventy to one hundred, and you’re willing to spend a million livres to achieve that objective, then the risk is that you’ll spend your million livres and not achieve the objective.
If you take that objective and translate it into a set of requirements for technologists to implement, then you’ve added another risk—the risk that the requirements you’ve chosen won’t actually accomplish the objective. Yet that’s exactly how the traditional model proceeds; it does little to mitigate this risk, since you don’t find out whether your requirements have succeeded until the project is over and you’ve spent all your money.
You can reduce the risk by taking the Lean startup approach and treating the so-called requirement as a hypothesis: “I believe that if we implement these features, then the result will be to increase cases from seventy per day to one hundred.” Then you’ll test the hypothesis, often with only a fraction of the total spend of the project. Based on the results of your test you can either modify the requirement or abandon it altogether. That is risk mitigation.
You can further mitigate this risk by using DevOps to quickly release one capability at a time to users. You can then see the objectives being accomplished as development proceeds; in the prior example, you can see the number of cases continually increase from seventy. With every released feature, you’re decreasing the risk of not accomplishing your objective. What better risk mitigation could you ask for?
(2) The Risk of Not Accomplishing Them in the Quickest, Most Cost-Effective Way
With the old waterfall approach, it was almost certain that you were not accomplishing objectives in the quickest, most cost-effective way. The waterfall, remember, actually increased risk by encouraging feature bloat. It required costly upfront time to prepare the requirements and to plan the project before delivering any value. And it increased costs because testing came at the end, when it was the most time-consuming to fix problems.
Fortunately, your toolkit now includes a better way to manage this risk as well. With an Agile approach you can begin delivering value right away, evolving the plan as you proceed. You reduce cycle times and eliminate waste by looking at the entire value stream, both inside and outside of IT. All of these reduce the risk that you won’t accomplish your objective in the quickest, most cost-effective way.
(3) The Risk of Inadvertently Exceeding Budget
In the waterfall approach, we treated scope as fixed (“required”) and continued a project until either the scope had been completed or the project had been terminated as a failure. Because the project had to continue until the scope was complete, there was a high risk of exceeding budget. That was precisely what happened on many projects.
When you use the Agile approach, you get results constantly through-
out the process, prioritized by their effect on the desired outcome. As a result, if the budget runs out you can simply stop the project—it has already delivered most of its value. Or you could decide to increase the budget and produce more impacts. You have the choice.
Leave a Reply