There will always be more services that could be redesigned, systems that could be replaced, processes that could be automated and new technologies that could be explored than there is money, time or people available to do the work. The difficult part isn’t generating a transformation pipeline. It’s deciding what should happen first, what should wait and what shouldn’t be done at all.
Too often those decisions are driven by whoever has the strongest business case, the loudest sponsor or the most urgent-looking problem. A better approach is to make prioritisation an explicit part of transformation management.
Start with value, not projects
Transformation portfolios have a tendency to become lists of projects: replace the CRM, implement a new website, introduce automation, migrate a system, build an integration.
But projects are proposed solutions, not reasons to invest. Before deciding whether something belongs in the transformation portfolio, I want to understand the problem it is trying to solve and the value of solving it.
That usually means looking at several different dimensions.
Strategic value
How strongly does the work support the organisation’s priorities?
Some initiatives are necessary because they enable a wider strategic change. Others may be worthwhile in isolation but contribute relatively little to where the organisation is trying to go.
Resident or customer impact
How many people are affected and how significant is the problem for them?
Volume matters, but so does severity. A relatively low-volume service can still deserve attention if the existing experience is particularly poor or affects vulnerable people.
Operational value
How much unnecessary effort, duplication or complexity exists in the current service?
High-volume manual processes, repeated data entry, avoidable contact and complicated hand-offs can all indicate substantial opportunities for improvement.
Financial value
Will the work reduce costs, avoid future expenditure or generate additional income?
This matters, but it shouldn’t become the only definition of value. Some worthwhile changes improve outcomes without creating a directly cashable saving.
Then consider whether you can actually deliver it
High potential value doesn’t automatically make something the right thing to do next. An initiative may have a compelling case but depend on technology that isn’t ready, data that isn’t available, another programme that hasn’t delivered or a service that simply doesn’t have the capacity to participate.
This is where prioritisation needs to consider more than benefits.
Complexity
How difficult is the change likely to be?
That includes technical complexity, integrations, procurement, data, organisational change and dependencies.
Complexity isn’t necessarily a reason not to proceed, but it changes the investment required and the likelihood of success.
Organisational readiness
Is the organisation actually in a position to make the change?
A technically straightforward project can fail because the service cannot commit people to it, leadership isn’t aligned or the operating model isn’t ready. Readiness is often underestimated because it doesn’t appear on a technical architecture diagram.
Confidence
How confident are we that the predicted benefits are real?
Some opportunities are supported by good data and a well-understood problem. Others are based largely on assumptions. Those shouldn’t be treated as equivalent.
Low confidence doesn’t necessarily mean rejecting an idea. It may mean the next investment should be a discovery, prototype or pilot rather than a full implementation.
Don’t turn prioritisation into a mathematical answer
It is tempting to turn all of this into a scoring exercise: score each initiative against a set of criteria, apply weightings and produce a ranked list.
That can be useful, particularly when there are many competing initiatives. It makes assumptions visible and gives people a common basis for discussion. But the score shouldn’t make the decision.
A prioritisation framework is a decision-support tool, not an algorithm for deciding strategy. Two initiatives can receive similar scores while presenting completely different choices. One might deliver a modest improvement quickly and with little risk, while another might be difficult and expensive but create a capability the organisation will depend on for years.
A simple numerical ranking can hide that distinction. The value of the framework is that it forces those trade-offs into the open.
Think about the shape of the portfolio
Prioritisation shouldn’t simply result in doing the highest-scoring initiatives until the money runs out. A healthy transformation portfolio usually needs a mixture of work.
Some initiatives will be relatively quick improvements that can deliver value without major organisational change. Others will be larger strategic investments that take longer but address more fundamental problems or create important new capabilities. There may also be exploratory work where the potential value is significant but confidence is currently low.
This is particularly relevant with emerging technology such as AI. A promising AI opportunity with uncertain benefits may justify a small pilot, but it probably doesn’t justify building a major programme around an assumed saving that hasn’t yet been demonstrated.
The question therefore isn’t only, “Which initiatives have the greatest potential value?” It is also, “What is the right level of investment given what we currently know?”
Dependencies can change the answer
Transformation initiatives rarely exist independently. Replacing a website may create the foundation for redesigning online services. Introducing a common case-management approach may make subsequent service transformation faster. Improving organisational data may unlock automation or AI opportunities that weren’t previously practical.
The reverse is also true. An apparently attractive initiative may depend on capabilities that don’t yet exist, which means looking at individual business cases in isolation can produce the wrong sequence of investment.
Sometimes the most important thing to do first isn’t the initiative with the largest immediate benefit. It’s the one that makes several subsequent improvements possible.
Prioritisation should be continuous
Annual prioritisation exercises are useful for setting direction, but transformation portfolios shouldn’t become fixed for twelve months.
The portfolio needs to be able to respond to that evidence. This doesn’t mean constantly changing direction. It means periodically revisiting the assumptions behind investment decisions and being prepared to change those decisions when the evidence changes.
A discovery may show that an expected benefit isn’t realistic. A pilot may demonstrate substantially more value than anticipated. A supplier contract may create an unexpected deadline, a dependency may slip, or a service problem may become significantly more important.
Stop things as well as starting them
This is one of the harder disciplines in transformation. Organisations are generally much better at approving initiatives than stopping them.
Once a project has a team, governance structure and senior sponsor, momentum develops. Continuing can become easier than asking whether the original case still makes sense, particularly once significant time and money have already been committed.
Good portfolio management therefore needs explicit points where that question can be asked. Has the evidence strengthened or weakened? Are the expected benefits still realistic? Has the problem changed? Is this still a better use of capacity than the alternatives?
Money already spent isn’t a reason to spend more.
Being willing to stop or reshape work is part of prioritisation. It doesn’t necessarily mean the original decision was wrong, only that the decision should be based on what we know now rather than what we believed when the work started.
Use evidence from previous transformation
Over time, prioritisation should become less dependent on prediction. If an organisation measures what happens after transformation is delivered, it begins to build its own evidence about where investment actually produces value.
That can answer practical questions. Which types of service redesign reduce demand? Where does automation genuinely remove manual effort? Which changes improve online completion? How much organisational effort does a particular kind of implementation really require?
That evidence should feed back into future investment decisions. The relationship between prioritisation and benefits measurement is therefore important: prioritisation asks where we think investment will create the greatest value, while benefits measurement tells us whether it actually did.
The answer should influence what gets prioritised next.
A practical approach
I tend to assess potential transformation work across a relatively small number of dimensions:
-
strategic value
-
resident or customer impact
-
operational value
-
financial value
-
complexity
-
organisational readiness
-
confidence in the expected benefits
The purpose isn’t to create a perfect formula. It’s to make competing initiatives comparable enough to have a useful conversation about them.
A simple framework also exposes disagreements that might otherwise remain hidden. If one person believes an initiative will create substantial operational savings and another has very little confidence in those savings, that’s useful information. The conversation about why their assessments differ is usually more valuable than the resulting score.
Prioritisation is really about choices
Transformation strategies often contain sensible ambitions: better services, lower costs, improved digital access, greater use of data, automation and AI. The difficult part comes when all of those ambitions compete for the same delivery capacity.
That’s where prioritisation becomes meaningful. It should make clear what we are choosing to invest in, what we are choosing not to do yet, why we believe this is the better use of our capacity, and what evidence would cause us to change that decision.
A prioritisation framework can help structure those conversations.
But the framework isn’t the strategy. The quality of the decisions it helps you make is what matters.