Previously I wrote that a great way to manage risk is to design it out of the system. But what if our system—our project—is already set up and running?

The traditional project management approach to risk management is to list so-called risks and handle them separately, with risk workshops, risk owners, and so on. But “risks” are not individual things that can identified separately. Risk is highly fluid, and it’s better to look at the bigger picture surrounding each so-called “risk” and consider it as a wider area of uncertainty.

For example, we might be presented with a “risk” that “Our security expert might leave the company”… but that’s probably more a wider matter of staff engagement and skills sharing. You might be presented with a “risk” that the client won’t pay on time… but that’s probably more a wider matter of client relationships, payment incentivisation, and company cash health. We can look at these uncertainties and seek to change the system: improve our staff engagement, skills sharing, client relationships, and so on.

But if we’re mid-project and presented with so-called “risks” then our opportunity to change the system is more limited. However, we shouldn’t overlook the possibility that our system doesn’t need to change, and that it already accommodates these things. I recently worked on a project where one stated “risk” was “Developer velocity varies and we might not be able to achieve all we want,” to which the correct response was “That’s why we continually re-calculate our burn-up and continuously re-prioritise”. Another example, from another project, was “We may not be able to scale the system to meet the demands required,” but in fact that particular project ran regular performance and scale testing and acted accordingly.

In both cases—and many others—it is just a case of pointing out to the concerned colleague how the matter is accounted for in the current governance process.

Sometimes the matter is not so much part of the project governance process but part of the organisation’s own governance process. For example, a concern about a team member’s skill level is an issue for the relevant line manager, and a concern about aligning stakeholders often falls squarely to the relevant product manager.

If a concern is actually not handled by our governance processes then it’s a good opportunity to consider adjusting them. Ideally, designing it out of the system.

Not all concerns, worries, or uncertainties are handled by existing mechanisms, of course. But if we’re working in a reasonably stable organisation then it’s likely that lots of incoming “risks” can be dealt with promptly by pointing people in the right direction, or checking the relevant person is dealing with that as part of their usual responsibilities. This shows how good risk management isn’t a distinct process—it’s just good management.

Photo by Sam Howzit