In How to prioritise digital transformation investment, I looked at the problem most transformation programmes eventually encounter: there are more worthwhile things to do than there is capacity to deliver them.
The answer isn’t a more detailed roadmap. It’s having a consistent way to compare opportunities, test the assumptions behind them and make conscious decisions about where to invest. The obvious follow-up question is what that looks like in practice.
I’ve been using a relatively simple scorecard approach to do this. It isn’t intended to turn transformation into a mathematical exercise, and a score of 31 doesn’t automatically mean something should be delivered ahead of something scoring 29. The purpose is to create a common basis for the conversation, and to update that view as we learn more.
Start by defining the unit of investment
Before scoring anything, it helps to distinguish between two different types of transformation work.
Capabilities
A capability is something reusable that can be deployed across multiple services.
For example:
- case management
- digital forms
- email triage and automation
- identity and authentication
- integration
- data and reporting
Building a case management capability doesn’t, on its own, transform a service.
It creates the capability to do so.
Services
A service work package applies one or more of those capabilities to a particular service problem.
For example:
- applying email triage to Planning
- introducing case management into Housing
- redesigning Waste service requests
- digitising Licensing applications
This distinction matters.
Capabilities create opportunities. Services usually create the measurable outcomes.
Without making that distinction, programmes can easily end up with a roadmap dominated by technology projects whose connection to actual service outcomes becomes increasingly difficult to explain.
It also helps identify the value of reuse.
An investment in a reusable capability may initially look expensive compared with solving a single service problem. But if that capability subsequently supports ten services, the economics can look very different.
A simple transformation scorecard
For each potential work package, I score five dimensions of benefit:
| Measure | Question |
|---|---|
| Resident experience | How much will this improve the experience of residents? |
| Employee experience | How much will this improve the experience of staff? |
| Service effectiveness | How much will this improve operational performance? |
| Risk & quality | How much will this reduce risk or improve quality? |
| Technology simplification | How much will this simplify the technology landscape? |
Each is scored from 1 to 5.
The important part isn’t the number itself. It’s having reasonably consistent guidance about what those numbers mean.
For resident experience, for example:
- 1 — little or no noticeable resident impact
- 3 — a noticeable improvement for some residents
- 5 — a significant improvement affecting a large number of residents
The same principle applies across each measure.
This makes scoring slightly less subjective, although it would be misleading to pretend subjectivity disappears completely.
The aim is consistency, not mathematical certainty.
Don’t just measure benefit
One of the easiest mistakes with prioritisation is to rank opportunities purely by their potential benefits.
That produces a list of attractive ideas, not necessarily a deliverable programme.
So I add two further measures.
Delivery readiness
How ready are the service and organisation to proceed?
Consider:
- sponsor engagement
- service commitment
- availability of resources
- understanding of requirements
- data and process maturity
- whether the service has the skills and capacity to adopt the change
A potentially valuable project where the service isn’t ready may be exactly the wrong thing to start.
A simple scale can be used:
| Score | Guidance |
|---|---|
| 1 | Significant barriers or resistance |
| 3 | Some preparation required before delivery |
| 5 | Service actively engaged and ready to proceed |
Delivery complexity
How difficult will this be to deliver?
Consider:
- process change
- number of teams involved
- supplier dependencies
- integration requirements
- dependencies on other work
Again, a simple scale is sufficient:
| Score | Guidance |
|---|---|
| 1 | Major transformation with significant complexity |
| 3 | Moderate complexity requiring coordination |
| 5 | Simple change with limited dependencies |
I’ve deliberately made a higher complexity score mean easier to deliver.
That way, all of the measures point in the same direction: higher scores are generally more favourable.
Separate financial savings from capacity
Alongside the scorecard, I record some more conventional benefit measures.
Cashable benefit
The estimated annual financial saving that could realistically be removed from the organisation’s budget.
Examples might include:
- software licences removed
- supplier costs reduced
- agency spend avoided
- posts no longer required
Non-cashable benefit
Benefits that improve services, outcomes or ways of working but are unlikely to result directly in a budget reduction.
For example:
- improved resident satisfaction
- reduced complaints
- better data quality
- improved accessibility
- reduced risk
- improved staff experience
Capacity released
Staff time potentially released through reduced manual effort, automation or process improvement, expressed as an FTE equivalent.
For example, saving 18.5 hours each week equates to approximately 0.5 FTE of released capacity.
But it doesn’t automatically mean the organisation can remove half a post from its budget.
Calling all efficiency improvements “cashable savings” undermines the credibility of transformation business cases.
Released capacity can still be extremely valuable. It might reduce backlogs, improve response times, absorb increasing demand or allow staff to concentrate on higher-value work.
It just needs to be described accurately.
Add confidence to the benefits
There is another number I find particularly useful:
How confident are we that these benefits will actually happen?
I use another 1–5 scale:
| Score | Evidence |
|---|---|
| 1 | Assumption only, with little supporting evidence |
| 2 | Limited evidence or benchmarking available |
| 3 | Some evidence from discovery or comparable implementations |
| 4 | Strong evidence from data, pilots or previous deployments |
| 5 | Benefits already demonstrated or supported by robust evidence |
This addresses a significant weakness in many transformation roadmaps.
Two projects might both claim a £250,000 annual benefit.
But those numbers shouldn’t carry equal weight if one is an early assumption and the other has been demonstrated through a successful pilot.
Recording confidence makes that uncertainty visible.
Discovery should change the score
The initial score isn’t the final score. When somebody proposes a new piece of work, we make a reasonable first assessment based on what we know and ask whether there is enough potential value to justify spending time investigating it.
If there is, the work moves into Discovery or Proof of Concept. The purpose isn’t simply to prepare a project for delivery, but to produce evidence about things such as:
- how much demand actually exists
- how much staff time the existing process consumes
- what residents currently experience
- whether the technology works
- how difficult integration will be
- what implementation is likely to cost
- whether the service is capable of adopting the change
- whether the claimed benefits are realistic
At the end of Discovery, we score the opportunity again. The score may go up or down, and either can be useful. Discovering that an apparently attractive project isn’t worth pursuing is not a failed Discovery; it may have prevented considerably more money being spent on the wrong thing.
The process can be very simple
The governance process I’ve been using looks broadly like this:
1. New work package
Anyone can identify an opportunity and add it to the programme backlog.
2. Initial benefit assessment
The programme team discusses the opportunity and agrees an initial “best guess” scorecard.
The question at this point isn’t:
“Should we deliver this?”
It’s:
“Is there enough potential value to investigate this further?”
3. Discovery or Proof of Concept
A small amount of resource is assigned to understand the problem, test assumptions and gather evidence.
4. Update the scorecard
Discovery evidence is used to revise the original:
- benefit scores
- cost estimate
- readiness
- complexity
- financial benefits
- capacity released
- benefit confidence
5. Board review
The work package can now be considered alongside other opportunities using a reasonably consistent evidence base.
The board can agree to:
- proceed
- defer it
- request more evidence
- stop the work
6. Schedule for delivery
Approved work enters the delivery roadmap when the appropriate capacity is available.
This creates a useful separation between having an idea, investigating an idea and committing to deliver it.
Those are three different investment decisions.
A worked example
Imagine a council receives a large volume of emails into a shared service inbox.
Someone proposes introducing automated email triage.
Initially we might score it like this:
| Measure | Initial score |
|---|---|
| Resident experience | 3 |
| Employee experience | 4 |
| Service effectiveness | 4 |
| Risk & quality | 3 |
| Technology simplification | 3 |
| Delivery readiness | 3 |
| Delivery complexity | 4 |
At this stage, these are informed assumptions.
A short Proof of Concept might then analyse actual email volumes, categorisation accuracy, staff handling time and potential automation.
Suppose it demonstrates that:
- 2,000 emails arrive each week
- staff spend approximately 70 hours each week manually reading and routing them
- around 75% can be categorised reliably
- automated acknowledgement and routing significantly reduces handling time
- integration with existing systems is relatively straightforward
We can now revisit the scorecard.
Service effectiveness might move from 4 to 5.
Delivery readiness might move from 3 to 4 because the service has participated in the pilot and wants to proceed.
Benefit confidence might move from 2 to 4 because we now have evidence from real transactions.
We can also estimate the capacity released using actual operational data rather than an assumption.
The board is now making a materially better investment decision than it could have made when the idea first appeared.
Use the scorecard comparatively
A scorecard becomes more useful as the programme builds up examples.
Instead of asking:
Is a resident experience score of four correct?
Ask:
Is the resident impact of this work greater or smaller than the other things we’ve scored as four?
That comparative judgement is often easier.
Over time, the programme develops its own calibration.
It is also why I wouldn’t spend too much time designing complicated weighting algorithms.
There will always be judgement involved.
A statutory requirement may need to proceed despite a relatively low score.
A small piece of work might be worth doing simply because it can be completed quickly.
Another project may have strategic importance that isn’t adequately captured by the scorecard.
The scorecard informs the decision. It doesn’t make the decision.
Keep the tooling boring
You don’t need specialist portfolio management software for this.
The scorecard can live alongside whatever you’re already using to manage the programme.
For each work package, record:
- work package name
- capability or service
- short description
- estimated cost band
- five benefit scores
- delivery readiness
- delivery complexity
- cashable benefit
- non-cashable benefit
- capacity released
- benefit confidence
- assumptions and supporting evidence
For cost, even broad bands can be sufficient initially:
| Band | Estimated cost |
|---|---|
| £ | Under £10k |
| ££ | £10k–£50k |
| £££ | £50k–£150k |
| ££££ | Over £150k |
Early estimates don’t need spurious precision.
They need to be good enough to compare the scale of investment with the potential return.
A few rules make the approach work
There are some simple disciplines worth applying.
Use evidence from Discovery wherever possible
If something is still an assumption, label it as an assumption.
Don’t score everything four or five
If every initiative is transformational, the scorecard isn’t helping you prioritise anything.
Compare scores with previous work packages
Consistency matters more than debating whether something is objectively a 3 or a 4.
Record uncertainty
An uncertain £500,000 benefit shouldn’t quietly become a £500,000 saving in the programme business case.
Don’t allow the total score to become the decision
A spreadsheet can calculate a number.
It can’t understand political priorities, statutory obligations, organisational capacity, dependencies or whether now is simply the wrong time to disrupt a particular service.
Those remain management decisions.
From a list of projects to an investment portfolio
This is ultimately what the approach is trying to achieve.
A transformation roadmap shouldn’t just be a list of projects the organisation has agreed to deliver.
It should be a portfolio of investments that is continually being reassessed as new evidence becomes available.
Some opportunities will progress quickly.
Some will need further investigation.
Some will become more attractive as reusable capabilities become available.
And some should stop.
That last category matters.
A healthy transformation programme should be able to say:
“We investigated this, the evidence wasn’t strong enough, so we’re not investing further.”
That is prioritisation working properly.
The scorecard itself is deliberately simple.
The value comes from the discipline around it: consistent measures, explicit assumptions, evidence from Discovery and regular comparison between competing investments.
That’s what turns prioritisation from an annual roadmap exercise into an ongoing part of managing transformation.