Ask ten people to rank the same list of projects and you will get ten different orders, each defended with real reasons. A project scoring model exists to end that argument. It replaces "I think this one matters more" with a number that everyone agreed how to calculate, which is the only way a portfolio of competing initiatives gets ranked without the decision turning into whoever lobbies hardest. The math in these models is simple. Choosing the right one for your organization is the part people get wrong.
This guide compares the four scoring models a PMO actually encounters, RICE, WSJF, weighted scoring, and cost of delay, shows the formula for each, and gives you a plain rule for picking one.
Key takeaways
- A project scoring model converts competing projects into comparable numbers so a portfolio can be ranked consistently instead of politically.
- RICE (reach, impact, confidence, effort) suits data-rich product backlogs; WSJF (cost of delay divided by duration) suits time-sensitive, multi-team portfolios; weighted scoring suits mixed portfolios with many stakeholders and competing criteria.
- The best model is the simplest one your organization will actually run every cycle. A precise model nobody maintains loses to a rough one everybody trusts.
- Scoring ranks the candidates; it does not decide capacity. You still fund down the ranked list only as far as your resources reach.
What is a project scoring model?
A project scoring model is a defined method for rating each project against a fixed set of factors and combining those ratings into a single comparable score. Every project on the list runs through the same formula, so a cost-saving automation and a new revenue initiative end up with numbers you can line up next to each other. The score is not the decision. It is the input that makes the decision defensible, because everyone agreed on the factors and the weights before anyone saw the results.
The reason models matter is consistency across time and across people. When the same formula scores every request, this quarter's ranking uses the same logic as last quarter's, and the project that scored well did so for stated reasons a skeptic can inspect. That is the whole point: a good scoring model makes prioritization auditable. Scoring is itself one of the benefit-measurement project selection methods, alongside cost-benefit analysis and NPV; this page zooms in on the scoring family, and the mechanics of laying scores out in a grid are covered in the project prioritization matrix.
The four project scoring models compared
Here are the four models most portfolios choose between, side by side. Read the table for the shape of each, then the sections below for the formula and the fit.
| Model | What it measures | Best for | Main weakness |
|---|---|---|---|
| RICE | Impact per unit of effort, adjusted for confidence | Data-rich product backlogs, single team, large list of features | No explicit time or urgency dimension |
| WSJF | Cost of delay relative to job duration | Time-sensitive work, SAFe or multi-team portfolios | Cost-of-delay inputs are subjective and easy to game |
| Weighted scoring | Total of multiple weighted criteria | Mixed portfolios, many stakeholders, competing goals | Can launder gut feeling into numbers if weights are sloppy |
| Cost of delay | Economic loss per week of waiting | Sequencing a fixed set of ready initiatives | Hard to estimate in dollars for non-revenue work |
Swipe to see more →
RICE scoring model
RICE scores each project on four factors and combines them into one number. Reach is how many users or units the project touches in a set period. Impact is how much it moves the needle per unit, usually on a fixed scale (a common one runs 0.25 for minimal up to 3 for massive). Confidence is a percentage that discounts the estimate for how sure you are. Effort is the work required, in person-months.
The formula is:
RICE score = (Reach x Impact x Confidence) / Effort
A project reaching 5,000 users, with an impact of 2, at 80 percent confidence, needing 4 person-months, scores (5,000 x 2 x 0.80) / 4 = 2,000. RICE shines when you have real analytics behind reach and impact, which is why product teams managing an established, customer-facing product favor it. Its blind spot is time. RICE does not know that a compliance deadline makes a low-reach project urgent, so it can rank a must-do regulatory item below a flashy feature. For the full method, worked examples, and a scoring template, see the RICE scoring model guide.
WSJF scoring model
WSJF, weighted shortest job first, comes from the Scaled Agile Framework and sequences work by economic urgency. It scores the cost of delay, what you lose by not doing the work now, and divides by how long the work takes, so short, high-value, time-critical jobs float to the top.
The formula is:
WSJF = Cost of delay / Job duration, where cost of delay = user or business value + time criticality + risk reduction or opportunity enablement.
The time-criticality term is what sets WSJF apart. If a project loses value the longer you wait, because of a market window, a regulatory date, or a competitor's move, WSJF captures that where RICE cannot. It fits multi-team portfolios and SAFe environments where sequencing across teams is the real problem. Its weakness is that the three cost-of-delay inputs are relative estimates, so a team that wants a project moved up can quietly inflate its time criticality. For the economics underneath this, including the four delay profiles and the CD3 shortcut, see cost of delay. For the full WSJF method and worked examples, see the weighted shortest job first guide.
Weighted scoring model
Weighted scoring is the workhorse of portfolio management outside pure product teams. You pick the criteria that matter (strategic alignment, expected value, cost, risk, urgency are typical), assign each a weight that sums to 100 percent, score every project against every criterion, multiply, and total. The project with the highest weighted total ranks first.
The formula is:
Weighted score = sum of (criterion score x criterion weight) across all criteria.
Its strength is that it handles a mixed portfolio where a cost-saving project and a growth project compete, and it forces stakeholders to state up front how much strategic fit matters relative to cost. That negotiation over weights is more valuable than the arithmetic. Its weakness is the same as its strength: if the weights are set carelessly or the scores are gut calls dressed as data, it produces confident-looking nonsense, which is why choosing the right project prioritization criteria to weight matters more than the formula itself. The project prioritization matrix walks through building one with a worked example.
Cost of delay
Cost of delay is less a full scoring model than the economic idea underneath WSJF, used on its own to sequence a fixed set of already-approved initiatives. You estimate the money the business loses for each week a project is delayed, then do the highest-loss work first. It is powerful when the initiatives have real revenue or cost figures behind them and nearly useless when they do not, because putting a weekly dollar figure on an internal process improvement is mostly guesswork.
How to choose the right project scoring model
Pick the model that matches your data and your decision, not the most sophisticated one. Use RICE when you run a data-rich product backlog with a single team and real analytics for reach. Use WSJF when work is time-sensitive and you sequence across multiple teams, especially in a SAFe setup. Use weighted scoring when you run a mixed portfolio with many stakeholders and competing criteria, which is most PMOs. Use cost of delay to sequence a short list of ready, revenue-bearing initiatives.
The tiebreaker that matters most is maintenance. The best model is the one your organization will actually run every planning cycle. A precise model that goes stale because nobody updates the inputs loses every time to a rougher model the whole leadership team trusts and reruns. Start simpler than you think you need to, and add sophistication only when the simple version stops discriminating between projects. Whichever model you choose, remember it only ranks the candidates. It does not tell you how many you can afford; you fund down the ranked list only as far as your capacity reaches.
Where each scoring model breaks
Every scoring model fails in a specific, predictable way, and the failure has more to do with your organization than with the math. Choosing well means picking the model whose weakness you can live with, so it is worth being blunt about what each one does when the conditions are wrong.
| Model | How it breaks | What you see | What to do about it |
|---|---|---|---|
| RICE | Reach is unmeasurable for internal work | Reach becomes a guess, then a lever people pull to move rankings | Replace reach with a defined population count, or use a different model |
| WSJF | Everything is declared urgent | Cost of delay scores cluster at the top and stop separating anything | Force a ranking of delay costs against each other rather than scoring in isolation |
| Weighted scoring | Weights are set by negotiation in the room | Weights drift toward whoever argues hardest, and the result is preordained | Collect weights privately, reconcile the spread, then publish and freeze them |
| Cost of delay | The financial estimate is unavailable or invented | Confident dollar figures with no source anyone can name | Use bands rather than point figures, and record the assumption behind each |
Swipe to see more →
Two failures cut across all four. The first is scoring in isolation, where each project is rated on its own and everything lands in the top third, because a sponsor describing their own initiative rarely calls its impact medium. Score projects against each other and the spread returns. The second is the model that only runs once. A ranking produced in January and referenced all year is a ranking of what people believed in January, and by the third quarter it is defending decisions rather than informing them.
Pick the model by the data you can actually get
The most useful selection test is not which model is most rigorous. It is which model's inputs you can source without inventing them. A model that needs numbers your organization cannot produce will get those numbers produced anyway, made up under time pressure, and the precision of the formula then disguises the fact that its inputs are fiction.
| Input the model needs | Where it comes from | If you cannot get it |
|---|---|---|
| Number of users or transactions affected | Product analytics, CRM, operational reporting | RICE will not work here; use weighted scoring |
| Revenue or cost impact per period of delay | Finance, with the sponsor | Use delay bands rather than dropping the concept |
| Effort in comparable units | Delivery teams, sized the same way | Fix sizing first; every model divides by effort somewhere |
| Strategic fit against named objectives | The current strategy, if it is specific enough to score | Score against two or three explicit objectives, not "alignment" |
| Confidence in the estimates | The team that produced them | Ask for a range instead and use its width |
Swipe to see more →
The effort row is the one to fix before anything else. RICE, WSJF and most weighted models divide by effort, so inconsistent sizing corrupts every one of them equally. If one team sizes in ideal days and another in calendar weeks, the ranking is measuring estimation habits rather than value, and no choice of model repairs that.
Where an input is genuinely unavailable, prefer a coarse honest band to a precise invented number. A criterion scored as high, medium or low with a written definition of each level survives scrutiny. A dollar figure carried to three significant digits with no source collapses the first time a finance director asks where it came from, and it takes the credibility of the whole model with it.
The weight audit: has a criterion ever changed a ranking
Run this once a year. Take the last four scoring rounds, remove one criterion, recalculate, and see whether the funding decisions would have differed. A criterion that never moved a project across the line is doing no work, and it is not harmless, because every scored criterion costs debate time and gives the model an appearance of rigor it has not earned.
This is a different question from whether your criteria separate projects within a single round, which is the check covered in how to prioritize a project portfolio. A criterion can produce a healthy spread of scores every time and still never change an outcome, because the projects that score high on it also score high on everything else. That correlation is invisible inside one round and obvious across four.
Three results are worth acting on. A criterion that changed nothing across four rounds should be dropped or merged. Two criteria whose scores track each other closely are double counting the same thing and are silently worth twice their stated weight. And a criterion that flips outcomes constantly is either the most important one you have or the worst defined, so read the actual scores before deciding which.
Expect the audit to shrink the model. Most scoring models grow by accretion, because adding a criterion is how a stakeholder gets reassured their concern is represented, and nothing is ever removed. Four to seven criteria that each demonstrably change decisions beat twelve that mostly cancel each other out.
Who owns the scoring model and when it changes
A scoring model needs a named owner and a fixed review point, or it changes informally, mid-cycle, in the meeting where the change most benefits somebody. The rule worth holding is simple: criteria and weights can be changed between scoring rounds, never during one. A model edited while the results are visible is no longer a model.
| Decision | Who | When |
|---|---|---|
| Add, remove, or reword a criterion | Portfolio board, on the PMO's recommendation | Annual review, or after a weight audit |
| Change a weight | Portfolio board | Between rounds only, published before scoring opens |
| Rule on how a specific project is scored | PMO lead | During the round, recorded with the reason |
| Override the resulting rank | Named sponsor or board, on the record | Any time, provided the override is visible as an override |
Swipe to see more →
That last row is the one PMOs resist and should not. Overrides will happen, and a model that pretends otherwise just pushes them into the scoring itself, where someone quietly adjusts an input until the answer comes out right. Let the ranking stand and record the override next to it. Counting overrides over a year tells you whether the model reflects how the organization actually decides, and if a third of the list is being overridden, the criteria are measuring the wrong things.
Frequently asked questions
What is the difference between RICE and WSJF?
RICE measures impact per unit of effort and has no time dimension, so it is built for data-rich product backlogs where you rank a long list by value for the work. WSJF measures cost of delay divided by job duration, so it explicitly rewards urgent, time-critical work and short duration. Choose RICE when you have analytics and no hard deadlines; choose WSJF when timing and sequencing across teams drive the decision.
Which project prioritization model is best?
There is no single best model; the best one fits your data, your portfolio, and what your team will maintain. Weighted scoring suits most PMOs because it handles competing criteria and many stakeholders. RICE suits single-team product backlogs with real analytics. WSJF suits time-sensitive, multi-team work. The deciding factor is which model your organization will actually rerun every cycle rather than abandon after one quarter.
What is a weighted scoring model in project management?
A weighted scoring model rates each project against a set of criteria, such as strategic alignment, value, cost, and risk, where each criterion carries a weight that reflects its importance and all weights sum to 100 percent. You score every project against every criterion, multiply score by weight, and total. The highest total ranks first. It is the most common model for ranking a mixed portfolio because it makes the trade-offs between criteria explicit.
What is the RICE scoring formula?
The RICE score is (Reach x Impact x Confidence) divided by Effort. Reach is how many users the project affects in a period, impact is how much it moves each one on a fixed scale, confidence is a percentage that discounts uncertain estimates, and effort is the work in person-months. Dividing by effort means a smaller, high-value project can outrank a larger one, which is the point of the model.
How many criteria should a scoring model have?
Keep a scoring model to roughly four to seven criteria. Fewer than four and the score fails to distinguish projects; more than seven and the weights get so thin that no single criterion changes the ranking, while the model gets harder to maintain. Pick the handful of factors that genuinely drive your investment decisions, weight those, and resist the urge to add a criterion for every stakeholder's pet concern.
Once you have picked a model and scored the candidates, the ranking feeds the rest of the portfolio process: it should trace back to how work enters the pipeline in your project intake process, sit within the wider set of prioritization frameworks, connect to the broader method in how to prioritize a project portfolio, and be sanity-checked against real availability in resource and capacity planning. Scoring is the engine; governance decides what happens with the ranked list, and the checkpoints where a funded project is re-tested against its score are set out in the stage gate process.