Are Your Project Risks a Dripping Tap?
09/08/2017
It's always a conundrum isn't it? What to do with that tap that leaks just a little, give it an extra hard twist or just feather it till the water stops? Reality is, rushing for the door in the morning it really doesn't get your attention. There is some mind-boggling statistic about the amount of clean water that is wasted every day, purely through failing faucets. However that's for another day.
What I'm drawing parallel to are project risks and how to manage them. Keeping with the tap analogy, when does a few drips become significant enough for us to take action? It's an easy decision if the whole fitting fails and you've got water hitting the ceiling, your risk is now an issue of immediate importance. Call the plumber! But when does that drip, drip, drip become a faster and require some mitigating steps, and more importantly do we notice the subtle change.
A risk is something that hasn't happened yet, but if it does it will have an impact on our project. On this basis – every project has risks, whether they are talked about or not. Based on this, how should we go about identifying risks and keeping them at the centre of the project? We all know about the delivery constraints of time, cost and quality - but how much time do we devote to risk and agreeing how to handle them should they occur?
Underpinning the Project Management Institute's PMP certificate is PMBOK, the Project Management Book of Knowledge, this devotes a whole (large!) chapter to the topic. There's heaps in there to go at, super large projects with multi-million dollar budgets and multiple suppliers will invest heavily in this space; completing quantitative risk analysis, leaning on industry knowledge, mathematical models, and predictive analysis culminating in a separate budget just for the mitigation of risks.
However the majority of projects we work on don't warrant that level of spend or investment, and would torpedo the benefit case before it began. So what to do I hear you ask?
The other way is to complete risk analysis in a qualitative way - that is assess risks on a relative basis. Assigning weightings against other risks to determine which items are the ones that warrant our attention. Lets break that down a bit more;
Firstly we need to identify project risks, what are the things that if they occur will impact our project; while this is typically done in a planning meeting or project kick off there is no wrong format to do this. The key is to capture it and have it ready for assessment.
Assessing the risk; risk register templates will ask you for the probability (or likelihood) of the risk occurring and also what the impact to the project would be if it did. Think in terms of time/cost/quality to do so. The simplest way to record this is in a 3x3 matrix, see below. Multiplying the likelihood by the impact score gives us a risk rating. Do this for all risks, and remember each risk is scored relative to the others.
a. Risk rating values of 1 or 2 can be accepted, no action needed - the project can absorb these
b. Risk rating values of 3, 4, 6 need a mitigation action and owner identified in readiness
c. Risk rating of 9 needs an action taken immediately and an owner identified for the risk
Respond. Now we have a relative view on the risks a response is now required. Working as a project team or at least with the project lead or product owners, formulate a response for each risk with scores greater than 2. These have various flavours, think back to that dripping tap;
a. Accept; these risks have such low probability or low impact if they happen that no action is required.
b. Mitigate; what are the steps that I can identify now and have ready to implement should the risk occur, or the risk rating increase.
c. Avoid; the project can't afford for these risks to occur so immediate steps are required to ensure this risk doesn't occur
d. Transfer; think contractually outsourcing your testing activity or changing your hosting solution to a cloud based offering to transfer ownership of the risk to a 3rd party
OK, done that. Let's tick that box and move on with project delivery. Well, not quite. Drip, drip, drip …. Reflecting on our current risk practises suggests that we do manage risks pretty well, but this is done at an implicit level - almost continually by team members. However the challenge with that is the risk being addressed is not necessarily validated across the project and can be a narrow response, or indeed a response that would be different when weighed against other risks
So my take out is to make this practise habitual within our projects and capture risks explicitly in a medium that best suits; risks can then be re-reviewed, re-assessed, re-responded to and re-reviewed again and again. What was last week's accepted risk requiring no response could be this week's top ranked risk requiring immediate action - a lot can happen in a project in a week.
As boring as it may sound we love talking all things project related, from how to manage risks and beyond so if you have had some success in this area, we’d love to hear your comments. If you’d also like to recommend a topic for another post – leave your comments below.
Written by Matt Varley
