Often when I talk about unhelpful entries in risk registers there is some disbelief from the people I’m talking to. I present some examples, and people’s first reaction is “but these don’t make sense”. Nevertheless, there are plenty of sensible people putting unhelpful entries into risk registers. People so sensible, in fact, that perhaps you or I are among them. We need to look at these project warnings dispassionately and see if they are presented in a helpful way. And if not, then we need to devise practical actions, because otherwise we won’t have any means of tackling those very real concerns in our projects.
Here are some examples of real risk register entries I’ve encountered, why they’re not helpful, and how we might change that.
Risk: Supplier may be insufficiently skilled. Action: We have chosen best-in-class supplier.
I’ve seen this several times in real business proposals, but it’s peculiar. Either it’s saying we’ve already addressed the problem (because we’ve already made the choice of supplier), in which case this shouldn’t be on the risk register. Or it’s saying we might discover once they start work that the supplier is insufficiently skilled, in which case the (historical) action isn’t going to help us.
How might we address it? Perhaps we might contract a number of suppliers, each addressing different aspects of the work, and with the opportunity to shift responsibilities if one seems lacking. Perhaps we should start off slowly with our chosen supplier and ramp them up as they prove themselves. Perhaps there are other approaches. The original concern is well-placed, but we can come up with more helpful actions.
Risk: Competitor launches before us. Action: Monitor competitor.
Again, the problem is genuine, but the action is unhelpful. It’s passive, and no amount of monitoring will change when our competitor delivers.
How might we address it more practically? I think there’s lots going on here, and not all of it is about our competitor. For one thing it’s significantly down to our ability to deliver rapidly and effectively. For another, how much time one company launches ahead of another is significant. For a third, there are many more factors than launch date which influence product success.
The action as stated positions us as a helpless victim of external forces, and yet two of those three alternative perspectives put control back in our hands.
Risk: Delivery rate of software teams is variable, and we may deliver less than needed. Action: Increase velocity.
This is a real entry from a real risk register, put together by an experienced project manager. And yet it isn’t realistic. The problem is real, but it seems implausible that if the project manager said to the team “We’re not going to make the deadline, can you go faster?” they would say “Oh, that’s a good idea, we hadn’t thought of that.”
Thirty years ago there wasn’t a well-recognised solution to that problem. Today we have agile software development. We know we can restructure our work to prioritise value, we can genuinely deliver frequently, we can continually adjust course, and we have tools to help. This solution is difficult to implement, but where it is implemented it changes the game so much that the problem has virtually vanished.
So what does this mean?
Unhelpful risk register entries are genuinely problematic because they don’t help us address potentially real project problems. They might even trick us into thinking we are dealing with them because they’re on the risk register.
These examples show that ordinarily sensible people, involved in very serious projects, can easily overlook real project dangers. The alternative actions I presented relate to the concept of “zooming out” that I wrote about last week. Hopefully this is a reminder that we should be careful when reviewing risk registers, and there are often practical actions that are helpful.
niksilver.com 