Whenever we introduce change, we introduce risk. However, whilst most transformation risk registers document the activity risks, few consider the planned benefits risk that may arise from the change itself.
Delivering a project – or a program – is about implementing deliberate change to the status quo for the purpose of creating a benefit to an organisation. Change, by its nature, introduces inherent risk to an organisation and when we kick off a project, one of the first steps is to create a risk register.
However, risk registers are typically concerned with of the types of risk that concern activity. Few consider the impact of change on the planned benefits or that risk is a multi-layered challenge.
Defining risk in transformation – or any project introducing change
There are three critical points for the executive to understand ahead of undertaking any form of project or transformation:
- Understanding the difference between delivery risk and benefits risk
- Why this distinction is important, and
- Why benefit risk is more important in transformation and how it links to assumptions
Delivery risks are reasonably well understood as those which have the potential to affect project execution – considerations such as the availability of or access to resources, or the potential for re-work or underestimation in the project. Put simply, these are the risks that could impact time and money and have the potential to impact the progress toward outcomes.
In fairness to project management professionals, most of their time is spent on planning, tracking, task assignment, resource allocation, and reporting. When a project is in full swing, the focus is on progress and being a few steps ahead of those issues that could derail that progress.
It’s not to say the delivery risk and benefit risk are mutually exclusive. Delivery risk can impact project benefits when time is an outcome – such as being first in market with a new product, for example.
The challenge good project professionals must manage well is juggling the often urgent nature of risks that may impact progress and the important risk that may impact the outcome which we call benefit risk.
Benefit risk is not always in line of sight
Benefit risk can sometimes go unnoticed because the full consequences of managing more immediate progress risks may not always be obvious to the project team and sponsors at the time. The devil is often in the detail, for example, when the scope hasn’t changed yet the requirement has been met on paper, and the solution may be sub-optimal as a consequence of decisions made to keep the project on time and in budget.
These are the trade-offs and decisions that are made to keep to the project moving, but what if we pause for these moments and considered them to be flag indicators for the potential impact to benefits and treat them as a risk.
Would the risk vs reward trade-off look different if a project took an extra week to reevaluate its design to ensure that the benefit wasn’t compromised or reduced? Would we consider it a good use of time?
The answers to those questions are specific to each project, its sponsor’s needs, and the situation. However, what’s important is that the question is asked. It puts potential benefit risk in view and then an appropriate risk response can be decided (avoid, accept, transfer, or mitigate).
Revisiting the business case and its assumptions
Often the biggest source of benefit risk is the business case itself and this is prevalent in transformative work. Most business cases have degrees of assumptions that is formed by a lot – or, oftentimes, little – analysis, depending on the availability of data or research and the risk appetite of the decision-makers.
Naturally, the greater the appetite and the more transformative the change is, it’s generally true that there will be greater benefit risk.
As projects progress, those leading the project will learn and the assumptions that have been made about the project can be tracked, reviewed, and re-evaluated in terms of the potential impact they may have on the calculated benefits.
It’s important to ask if the assumptions remain true as the project moves forward. For example, what if customer adoption isn’t as strong as we estimated? What can the project teams do to treat that risk? Are we nimble or agile enough in the transformative thinking and understanding of the benefit risk to be able to adapt if the original assumptions don’t prove to be the right ones?
It’s an important conversation to have early to ensure that the team can course correct if they identify that the risk is significant early enough to reduce negative impacts. However, our view is that if project teams are tracking benefits from inception through to post-implementation via a straightforward RAG rating, the endgame can be kept in focus for both the project team and stakeholders.
Consider emergent strategy as a risk mitigator
Benefit risk isn’t always the negative impact to planned benefits; it can have positive outcomes too when opportunities to try something new or innovative arise. This is something Quay calls emergent strategy and typically happens when the planned strategy – successful or not – creates new opportunities or branches that weren’t planned.
As the project progresses along the planned pathway the assumptions may be challenged or confirmed and these are the opportunities to refactor. The goal is always to maximise the value your project creates and sometimes how you achieve those results will change and as the team learns through progress, new opportunities will reveal themselves. At that point, use your risk tools to assess the risk, the cost, and the benefit of pursuing those opportunities to maximise your project’s return.
To find out more about how Quay Consulting can help your team manage benefit risk in 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