Don't buy umbrellas in July for rain in November

The Management of Risk is a huge topic. Getting the balance right between being too risk averse or just "winging it" is a challenge. Risk can often become the headliner and star of the show when really it should be the benefits and business value being delivered that hog the limelight on the main stage.

In my experience of working in multiple industries and businesses is each one will take their own unique approach to the management of risk. Tech businesses for example will tend to seek forgiveness and not approval, super lightweight risk logs with basic 1-3 probability and impact analysis anything more than this and the Product Development Rockstars and Software Engineer Ninjas rebel, regressing to their PlayStations and coffee bars completely disengaged.

Public Sector however is at the other end of the spectrum, initiatives move slower than Brexit, progress hamstrung by a cottage industry of risk paralysis and risk logs more densely populated and complex than Spaghetti junction on the M6.

The right answer is, as always, somewhere in the middle. The balance of risk analysis against quality of requirements, depth of project planning, available budget, size of scope and organisational drive is tricky to get right as evidenced in the numerous articles on why projects fail.

One technique I find extremely useful in risk management is the concept of proximity. Basically when do you predict the risk might develop into an issue.  With so many potential risks ahead projects will develop impact versus probability matrices which help guide us on what to focus on by applying a RAG status of green, amber or red (depending on how your risk framework is set up). 

Now you are clear on what the potential impact might be and have an idea of the likelihood it will occur, the next step is to ascertain the "when". You can use project phases (analysis, architecture, development, test business acceptance or release as examples) or a scale of months for example 1-3 months, 3-6 or 6-12. Armed with this data and applying this to the risk log, you can now focus efforts on mitigating actions for the risks in months 1-3 or if using project phases analysis or architecture. 

It could be you have a risk around incomplete requirements specification impacting development time and quality. This risk will be almost right in front of your face and must be swiftly dealt with otherwise the whole way down the chain timelines and quality are going to be impacted. What mitigating actions can you think of ? Implement business analyst peer review meetings, insist on Executive sign off on requirements or force an agile approach where analysts, SMEs , developers and testers work together in close teams collaborating daily and working on requirements together.

Risk proximity helps you focus on what matters and not wasting time during a long hot summer worrying about rain in winter time. Whilst I am not advocating ignoring the long game and being proactive with a forward looking view it is back to balance and ensuring blockers in the near future are removed. Personally, I do buy sun cream in winter that ultimately will help me mitigate sunburn in summer, but that's because I am a Yorkshireman so I can pick it up on the cheap.