Effective risk-based project management strategies will help you make informed decisions when things are urgent, ultimately ensuring quality and successful project outcomes in dynamic environments.
There’s a famous saying about acting in haste and repenting at leisure – essentially meaning that if you’re always acting too quickly, there’s far greater scope for mistakes.
For most project professionals, that’s a nice thought but somewhat difficult to translate into meaningful action. After all, many of us are operating in an environment where things seem to change on a daily (if not hourly) basis, and everything is always high priority. You may even feel like you kind of have to act in haste, or risk being left behind.
Here’s the thing: in the world of project delivery, sometimes you have no other choice but to take urgent action. You might have a significant vulnerability that you need to remediate quickly, whether that be deploying out a mission critical software patch; or rolling out a major vaccination program in the face of a global pandemic.
While most of us will have to make urgent decisions numerous times in our professional careers without significant known consequences, every so often there will be an action or decision that sends shockwaves through your project or your organisation. In a worst case scenario, there may even be a wider impact on your industry or perhaps even the world (just ask CrowdStrike about that).
In many cases, the difference between success and failure almost always comes down to whether or not the program has adopted a risk-based delivery approach. Always consider the risk/reward ratio of delivering your project.
Ask yourself, ask your team: If we’re right, what do we stand to gain? If we’reI’m wrong, what do we stand to lose? And most importantly, how do we balance risk and reward to make meaningful decisions?
Don’t avoid project risk – balance it
There’s no such thing as a perfect project – in fact, every business transaction you undertake is essentially a transfer of risk from one party to another. Rather than setting out to avoid all risks, a healthier approach is to accept that it is a fundamental part of what you are doing, and balance the risks accordingly. This could be as straightforward as mapping out various pathways the project could take against the time/cost/quality triangle to understand the associated risks of each. For example:
- Option A is faster and far more cost-effective, but quality may be impacted significantly.
- Option B will be cost-effective and deliver a high-quality outcome, but it’s going to take longer to get there (therefore making it less risky than Option A).
- Option C can be delivered quickly and with higher quality, but it’s going to cost more (it may present significant risks; albeit different risks than Option A).
Once presented with these options, and with full transparency on the risks and opportunities of each option, leaders can then make a decision on which path to pursue based on the organisation’s current risk appetite against each of these parameters.
If there’s a burning platform to address, for example, then there is likely to be low tolerance for a longer delivery time or lower quality output, so Option C might be the most acceptable path. On the other hand, if budget is the top priority and you have some scope to tolerate adjustments and rework at the conclusion of the project, then Option A may tick all the risk boxes.
At this stage of the project, it’s relatively straightforward to capture what we call “special cause risks” (being highly irregular and impactful events such as unexpected regulatory changes or the breakdown of critical tools or processes). More thought may need to be given to the danger of “common cause risks” (those that can be reasonably expected, such as personnel availability and minor technical issues).
The reason for this is that as humans we tend to normalise common cause risk; therefore making it less identifiable. Explore our deeper dive into common cause v special cause risks for more on this topic.
Making reasonable, contextual assumptions
Assumptions are our greatest weapon when it comes to managing risk and reward. All projects start with assumptions. In fact, it’s a sign of a healthy project to have many starting assumptions.
In our experience, the ideal project delivery profile should capture many assumptions upfront, while your team has minimal experiential knowledge. Working on the principle that progress creates knowledge, those two parameters (assumptions and knowledge) should shift as the project progresses, to become inverse to each other. Assumptions will fall as the project is delivered, and you’ll gain knowledge through progress, experience and achievement.
This is the crux of a truly risk-based approach. A plan is just a big set of assumptions – if we do this, we think this will be the outcome. Each step has risks and opportunities. It’s only by balancing them that you’re likely to ensure overall success.
The importance of quality control
If risk management protocols are one side of the “risk-based approach” to project management, then quality control is the other side of the coin. At the end of the day, you can risk manage your project all you want; however, if you’re not factoring in how you’re going to assess and manage quality – your efforts may all be for nought.
We sometimes think of quality control as being a bit like hindsight: it’s all 20/20 (meaning, it’s easy to see your errors after they’ve been picked up by someone else – again, just ask CrowdStrike). It’s always preferable not to be on the receiving end of this treatment, so make sure you read our practical strategies to ensure you’ve factored quality control into your project from initiation through to completion.
Quay Consulting is a professional services business specialising in the project landscape, transforming strategy into fit-for-purpose delivery. Meet our team or reach out to find out more about how Quay Consulting can help your organisation, please contact us.
We believe that quality thought leadership is worth sharing and encourage you to share with your colleagues. If you’re interested in republishing our content, here’s what’s okay and what’s not okay.