Risk Management isn't about being a 'Deer in the Headlights'

Image Credit - T HallI recently came across that picture on Flickr and I thought it could be a nice title shot for my post today. As a company that values Entrepreneuralism, you'd assume that ThoughtWorks would be a fast moving, risk embracing mean machine. In more cases than one, that's absolutely true. In some less than ideal situations we do end up freezing up in the face of risk - much like deer in the headlights. The only difference is that deer eventually move on, but we often get stuck worrying about risk. Why does it happen at ThoughtWorks? Well, we're human after all - and frankly it's commonplace to fear possible loss than embrace possible gain. You've perhaps already read about in the 9x endowment effect and the sunk cost fallacy. Now don't get me wrong, I don't believe in being a cowboy - risk management is a crucial project management skill. I find extreme risk averseness however to be a deterrent in moving a project forward at a motoring pace. It hurts innovation, and obsessing over risks takes away a lot of energy and momentum from real, productive work. At the end of the day, risk management isn't a deliverable - real work is. Risk management is only a tool to facilitate work. I don't claim to be a great project manager, but I do have some thoughts I want to share with you today, about risk management.

You don't know how big it is

Last week we had a challenge. We needed to close out a legacy knowledge repository in view of the fact that we have new social business platform in place. As a team, we wanted to give the company 30 days before we archived the old system. Now for any medium or large sized company this brings about a set of risks. What if we lose data? What if we upset people? What if people need help and we can't support them? Are all these risks real? They probably are. How big are they however? We don't know. Now we can either freeze up and do nothing or ask ourselves - what's the minimum we need to know to move ahead.

Here's what we did. To check whether we'd lose data, I tried out an experiment on a test domain. Turns out that you lose no data whatsoever, you can turn the service back on and retrieve data whenever you need to. A quick, dirty experiment is often all you need to gauge the impact and mitigation for a specific risk. For the other two risks, no matter what we analysed, we would only be conjecturing as to how big the risks were. We've made the announcement and ever since, less than 15 people have reached out to us - most for tips to migrate their data, some for thorough guidance and just three who wanted us to actually assist the migration. Turns out, that no one really was hugely fussed about the move. In the worst case, if when we do shut down the service someone comes back saying they were on vacation and completely missed our warning, we can pop the service back on a weekend and help the individual move over. Risks addressed, we move ahead.

All risks are not equal

Risks are these little mystery balls. Some have a large impact, others have a negligible effect. Some might have a high likelihood and others are highly unlikely. Your plan is really conditional on how you evaluate these risks. The key in my view is not to over evaluate. In my world, risks have three parameters - the likelihood, the impact and the mitigation plan if the risk does manifest itself. The key however is to not over analyse. If the impact is low and the likelihood is bleak, then do you really want to spend all the time in the world analysing what you will do about it? The cost of analysing the risk far outweighs the cost having to respond to it without a pre-defined mitigation strategy. On the other hand, if it's a high impact, highly likely risk, then you want to do what you can to avoid it and not even have to get to the point of mitigation. The key is to look at likelihood and impact as a balance with mitigation strategy. From that point, it's about incremental changes, iterating and moving fast. Keeping everyone aware of how you percieve the risks just ensures that everyone knows what to do when you move ahead. Finally, risk management is conjecture - the key is make this systematic conjecture than just pure obsession. Also, sometimes it's important to just know what you can do and what your options are. The moment to act may not be until much later - Chris Matts calls this the last responsible moment.

---

You may ask why a blog on learning and social business has a post on risk management. I think it's a crucial competence when dealing with change and managing projects. Also, it's not as complicated as we'll often make it out be. I hope this short post helps you see my perspective on why I like to be pragmatic about risks and why I like to keep pushing forward with projects I am on. Not to say that I don't have things blowing up in my face - I've had an experience of that last week! That said, I would take that any day as long as I have the ability to respond quickly and to keep the pace of innovation high. I think that's a fair trade-off. What do you think?