Scoring frameworks fail when every project scores well, which is most of the time. The score then transfers the decision to whoever set the weights, and the argument never happens where people can see it.
This guide covers how to force a ranking instead, how to separate what you know from what you believe, and why saying no with a date attached is what makes the exercise credible.
Key takeaways
- Rank, do not score: Scores cluster and get adjusted until the expected answer appears; a forced order makes the trade-off visible.
- Separate known from assumed: Marking which figures are evidence and which are belief usually reorders the list on its own.
- Name the cheapest test: A week of customer calls frequently reorders a list that took a month to score.
- Say no with a date: A prioritisation that leaves everything alive has prioritised nothing, and teams keep spending on unfunded work.
Look for the business signal behind the technology
The signal that prioritisation is broken is a list where everything is important and nothing is sequenced. Every project has a sponsor, a business case and a score above the threshold, and the delivery team is quietly deciding the order by picking what is ready.
Scoring frameworks can make this worse. A weighted model that produces similar scores for every candidate transfers the decision to whoever sets the weights, and it does so without the argument happening where people can see it.
Take the five candidates and rank them one to ten with no ties allowed, in a room with the people who fund them. The argument that happens while you force the order is the valuable part, and a scoring sheet is a way of avoiding it.
Use four lenses to understand the opportunity
Business Value
State the money or risk attached as a figure someone in finance would recognise, not as a benefit statement. A project described as improving efficiency competes badly against one described as removing eleven hours a week from a named team.
User Impact
Record how many people are affected, how often, and whether they asked for this or you inferred it. A request that came from a customer carries different weight from one that came from a planning workshop, and the ranking should reflect that.
Feasibility
Write what has to be true for this to work and which of those things is outside your control. Dependency on another team's roadmap is the most common reason a well-scored project delivers nothing in the year it was approved.
Evidence
Separate what you already know from what you believe, and name the cheapest way to test the difference. A week of customer calls frequently reorders a list that took a month to score.
Assess the current state without buying software first
For each candidate, write the money or risk attached as a figure somebody in finance would recognise, and note whether that figure is known or assumed. The split between known and assumed usually reorders the list on its own.
Decide what useful measurement looks like
Record the one fact that would most change each ranking, so the order can be revisited honestly when that fact arrives. A list that cannot be reopened is defended rather than improved.
Track what you decided not to do and when it will be reconsidered. A prioritisation exercise that leaves everything alive has prioritised nothing, and teams carry on spending effort on work that was never going to be funded.
When software is likely to help
A tool helps once the method is agreed and the list is long enough that keeping it in a document has become the bottleneck. At that point software provides history and visibility, which are genuinely useful.
It does not help when the problem is that nobody will say no. A portfolio tool applied to an unwillingness to choose produces a well-organised list of everything, and the same team keeps deciding the order by availability.
For the operating model these priorities have to fit inside, see How to Build a Digital Operating Model for Your Business.
Start with a bounded improvement
Fund the top item, tell the sponsors of the others when they will be reconsidered, and record the decision. Saying no out loud, with a date attached, is what makes the next prioritisation exercise credible.
Read the opportunity from the outside in
Begin from the people affected rather than from the project list. Which customers or staff are losing time today, how much, and how often? Then work inward through business value, user impact and feasibility until the ranking is built from observation rather than from advocacy.
Name the cheapest test for the top candidate: a week of customer calls, a day reading the support queue, a manual trial. Running one of those before committing frequently reorders a list that took a month to score.
Risks to make visible
| Lens | Common risk | Early response |
|---|---|---|
| Business Value | Value is stated as a benefit, not a figure | Write the money or risk in a form someone in finance would recognise. |
| User Impact | Impact is inferred rather than asked | Record whether the people affected requested this or you assumed it. |
| Feasibility | Dependencies sit outside your control | Name what has to be true and who else has to deliver it. |
| Evidence | Belief is recorded as evidence | Mark each figure as known or assumed and name the cheapest test. |
A 30-day validation plan: Digital project prioritization
Days 1 to 5: force the list into an order. Take the candidate projects and rank them one to ten with no ties allowed. Do it in a room with the people who will fund them. The argument that happens while you are forcing the order is the valuable part, and a scoring sheet lets everyone avoid it. Do the ranking before anyone presents a business case, because a well-argued paper changes the order for reasons that have nothing to do with value.
Days 6 to 15: find the cheapest test for the top three. For each of the first three, write down what you believe and the smallest thing that would prove you wrong. A week of customer calls, a manual trial, a day reading the support queue. Run one of them and see whether the order changes. Set a limit on what the test may cost, since a cheap test that grows into a discovery project has become the project it was meant to assess.
Days 16 to 30: commit to one and say no to the rest out loud. Fund the top item and tell the sponsors of the others when they will be reconsidered. A prioritisation exercise that leaves everything alive has not prioritised anything, and the teams will keep spending effort on work that was never going to be funded this year. Put the date in writing, as a project that was deferred without a date is treated by its sponsor as one that was cancelled quietly.
A practical worksheet: Digital project prioritization
Scoring frameworks fail when every project scores well. Take the five candidates on your list and complete these rows for each, using the same evidence standard for all of them.
| Decision area | What to record |
|---|---|
| Business Value | The money or risk attached, stated as a figure someone in finance would recognise rather than as a benefit statement |
| User Impact | How many people are affected, how often, and whether they have asked for this or you inferred it |
| Feasibility | What has to be true for this to work, and which of those things is outside your control |
| Evidence | What you already know as opposed to what you believe, and what the cheapest way to test the difference would be |
| Measurement | The score, plus the one fact that would most change it, recorded so the ranking can be revisited honestly |
Rank the list rather than scoring it. Scores tend to cluster and then get adjusted until the expected answer appears, while a forced order makes the trade-off visible and forces the argument to happen in the room.
Related guides
- If the constraint turns out to be elsewhere, read Digital Transformation Roadmap: A 7-Step Business Guide.
- The related commercial question is covered in Paperless Workflow: How to Digitize Paper-Based Processes.
Should Digital Project Prioritization: A Practical Scoring Framework turn into a plan with owners and dates attached, Discuss Your Digital Roadmap.
Ali Boran Gazel