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.


About Big_GH

Currently employed as a Software Development Consultant with over 30 years experience with computing. Started writing BASIC programs on the Commodore VIC 20, C64 and Amiga before switching to C and C++. Now spends more time helping others with their software and looking after the "bigger picture".
This entry was posted in planning, process, Project Management, software development and tagged , , , , , , . Bookmark the permalink.

1 Response to Risks

  1. Pingback: What Makes a Good Manager? | The Big GH

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s