I remember being a technical lead on a project and working with our project manager and his newly introduced risk register.  Something bothered me about that risk register and the way it was being used and I’ve recently managed to figure out why – it wasn’t effective.  The process was good, identifying risks and planning mitigation strategies and contingency are some of the most important tasks of a project manager, so why didn’t it work?

I think the issue was in the identification of the risks themselves.  Whilst you can define a risk as anything that could affect the progress or outcome of a project, I think this definition is too broad.  Seriously, anything that could affect the project? The bubonic plague making a comeback would seriously affect the team, but probably isn’t worth tracking on a risk register or making contingency plans for – unless of course you happen to be working with infectious diseases!

So that was the first issue – identifying risks is hard as the risks need to be relevant, not just a big list.  Quality is definitely more important that quantity.

The second issue was in the plans he made to mitigate the risks.  A major risk identified was staff leaving and taking their knowledge with them.  Not only did this fail the first criteria of not being likely (the team had been together for years, and no-one had left in that time), the mitigation plan was harmful to the progress of the project.  People weren’t allowed to specialise, areas of the product were constantly moved between developers, extra (unread) documentation was produced, and presentations were performed to uninterested participants.

Now maybe I’m just lucky, but reading other team members code is not hard.  If someone left, the team would take a hit, but we’d soon be back up to speed.  Before a single line of code was  written on the project, the team discussed coding standards and agreed on a way of writing the software.  This common style made the code a lot easier to read and understand as even previously unknown areas felt a little familiar and welcoming.

So, the risk of someone leaving should have been classified as unlikely (even 8 years later the same people are still on the team).  The impact should have been classified as low with no need to change the working behaviour at that time.  It is ok to monitor the risk to make sure that these classifications stayed the same, maybe people would be more likely to leave, maybe the code being written becomes to specialised and key people start to emerge, maybe retention plans need to be put in place to encourage certain people to stay.  It is also ok to have thought about how to deal with a risk before it occurs (contingency planning) so that the way of dealing with it has already been considered.  A plan that covers how to transfer areas of knowledge if someone hands in their notice is a good one.

Overall we need think about how it helps the team progress.  A risk register in itself is not enough.  It must be used correctly, it should take the panic out of projects, both in avoiding risky areas that are unnecessary (some risky areas may be needed for the success of the project) and in dealing with issues as they occur (as they have already been thought through).  It should help set realistic expectations; instead of guaranteeing certain deliverables the project manager can identify a range of outcomes based on the risks to the project.  A risk register that isn’t helping the team should not be used.  A risk register that is helping the team can be a great tool.