Now, with two iterations and pilots complete, we were ready to discuss making commitments. We had a good idea as to the team velocity and pace. We had a good idea as to benefits. We could now commit to both dates and benefits. We still needed to manage the remaining work and make sure that we were not developing nebulous or overly complex rules or trying to read minds. In other words, we still had a big project to deliver but we were now able to make a commitment when we knew something.
“Purchasing” Options to Reduce Risks
There is another compelling advantage of using Proactive Risk Manage-ment. When we are brainstorming the actions we can take to reduce risks,
ptg12441863
we can also identify actions or information we can “purchase” to reduce risks faster or sooner. For example, we might determine that we can, for a price, allocate a person from the team to do a deep investigation of—
perhaps even set up and run—a new technology. This might cost us the work of that one team member, but if doing so quickly gets a yes or no answer regarding technical uncertainty, it might be well worth the price.
Once we have profiled the risks, risk-reduction options are more visible.
We were doing a large and critical analytics project. This project would predict customer retention based on a relatively small set of parameters. If this project worked, we would know which customers were trending away for us. Knowing this, we could then do an intervention to retain those cus-tomers. As a second phase of the project, we could categorize customers into their potential for leaving us and do things, proactively, to make sure they never even started to trend away from us. But this entire predictive FIGURE 7.5 Iteration three risk profile
Technical Uncertainty
Uncertain
Benefits Manual Process
Complexity
Lack of
Standardization
Rules Engine Complexity
ptg12441863 Proactive Risk Management 129
model assumed we had access to information about our customers that we simply did not collect. Thus, the enabler of this entire project came down to gathering that information. To make matters worse, there was no single way to collect the data.
As a team, we brainstormed various methods we could use to get this information. We identified four ways that would cause the least pain and two ways that would cause us to make big changes across our systems.
Always wanting the easiest way out, we agreed to try the four less painful methods. Given the critical nature of this project, we agreed to pursue all four in parallel. In effect, we “paid” for parallel development as a way to reduce project uncertainty as quickly as possible. We allocated a team to each method and set them free. And, for once, we got it right. Infor-mation for some customers was available with only one method while information for different types of customers came via a different method.
FIGURE 7.6 Iteration four risk profile
Technical Uncertainty
Uncertain
Benefits Manual Process
Complexity
Lack of
Standardization
Rules Engine Complexity
ptg12441863
Paying the “price” of parallel development reduced our project uncertainty sooner than a serial approach would have done.
Proactive Risk Management works extremely well if we get close to the truth when we profile the risks, are realistic about the actions we can take to reduce the risks to an acceptable level, somehow resist the pres-sure to make commitments until we know enough, and make it all visible to everyone—including the people who want that premature commitment.
Making Proactive Risk Management Visible
Proactive Risk Management is not only a way to consciously mitigate risks while taking a more sensible approach to commitment making, it is also a powerful management tool for tracking team progress and communicating status and success—by making them visible.
We can sum up our passion for making everything visible with the fol-lowing motto:
It is better to see than it is to read.
What does that mean? It means that we should find ways to make all of our work more picture dense than word dense. In fact, making work visual is one of the fundamental principles of iterative development. Using itera-tive principles, we prefer working software to comprehensive documenta-tion. Why? Because no one knows what they want until they “see” it, and they can read but can’t “see” requirements documents.
This ability to “see” is critical in Proactive Risk Management. Imagine the power of a set of risk level/acceptable risk level radar diagrams on a project dashboard. In the set, we show how we are iterating toward risks being at the acceptable level and our being able to make a specific commit-ment. Such a visual shows not only our commitment-making target but also that we have profiled the risks and implemented a plan that proactively reduces these risks, all at a glance.
Let’s apply this to our method of Proactive Risk Management. Imagine the power of a visual that shows the risk profile radar diagrams, the level of acceptable risk (prior to making a commitment), and the progress the team is making toward acceptable risk and commitment making. For a project dashboard, consider a series of these radar diagrams that demonstrate your progress. In the preceding example, we showed our progress with a series of radar diagrams that marked the shrinking risk. Figure 7.7 shows how we iterated toward acceptable risk.
ptg12441863