Most portfolio teams have a project prioritization matrix somewhere: a two by two grid with value up the side, effort along the bottom, and every candidate project placed as a dot. The top left box says quick wins, the top right says major projects, the bottom left says fill-ins and the bottom right says avoid. A board understands it in 30 seconds, and it is right about the thing that matters most.
It is also wrong in two specific places, and in a busy portfolio those two places decide the order in which your work gets done.
What is a project prioritization matrix?
A project prioritization matrix is a grid that plots each candidate project by its expected value against the effort it needs, then groups projects into quadrants, usually quick wins, major projects, fill-ins and avoid, that suggest what to do first.
That is sound. A ranking by value alone promotes the biggest project every time. The matrix asks what each project costs to get, and weighing value against cost is ratio thinking, which is the right instinct.
The trouble is where the matrix draws its boundaries, and which effort it counts. Fix both and a project prioritization matrix becomes a ranking by value per constrained resource hour: the value a project produces for each hour it uses of the constraint, the one team or skill whose capacity limits how much the whole portfolio can finish. And because the real question is which project to finish first, value has to be stated as drag cost: the value your organization loses for every week a project is not yet live.
Why do the quadrant lines give the wrong order?
The matrix draws one horizontal and one vertical line through the middle of the grid. But if what you care about is return for cost, two projects deserve the same priority when they have the same ratio of value to effort. The set of points with the same ratio is not a box. It is a straight line running out from the bottom left corner, and steeper lines are better. A project scoring 9 for value and 6 for effort lands in major projects. One scoring 6 and 4 lands in quick wins. Their ratios are identical, yet the grid gives them different instructions.
The reverse case does real damage. A large project with a steep slope sits in the top right box and gets labeled as something to plan carefully and start later, while a quick win with a shallow slope, just inside the boundary, gets started now. Nor do the quadrants order anything inside a box. When 11 projects land in quick wins, whoever asks loudest decides which comes first.
Which effort belongs on the effort axis?
The second problem is less visible. The effort axis almost always counts total effort: person-weeks across every team, or a 1 to 5 score standing in for it.
Most of those hours are not scarce. Most teams could absorb more work and one cannot: the integration engineers, the regulatory specialists, the group every project ends up waiting on. That group is the constraint, and its hours are the only ones that limit how much you deliver this year. A project needing 120 person-weeks, of which 2 fall on the constraint, costs the portfolio less than a project needing 10 person-weeks, of which 8 fall on the constraint. The conventional matrix ranks them the other way round.
So the effort axis should measure one thing: time at the constraint. If you have not identified yours, How to Find the One Resource That Sets Your Delivery Speed sets out the method.
What does a corrected project prioritization matrix change?
An illustrative example. Ridgeway has four projects waiting on its integration team, which works on one at a time. Each shows its drag cost (benefit per week once live), total effort and integration weeks.
1. CRM upgrade. $10,000 a week. 10 person-weeks in total, 8 of them integration. Slope: $1,250 per constraint week.
2. Pricing engine. $15,000 a week. 120 person-weeks in total, 2 of them integration. Slope: $7,500 per constraint week.
3. Reporting rebuild. $4,000 a week. 6 person-weeks in total, 1 of them integration. Slope: $4,000 per constraint week.
4. Warehouse link. $20,000 a week. 30 person-weeks in total, 4 of them integration. Slope: $5,000 per constraint week.
On the conventional matrix, the CRM upgrade and the warehouse link are quick wins, the pricing engine at 120 person-weeks is a major project, and the reporting rebuild is a fill-in. So the board runs the CRM upgrade, then the warehouse link, then the pricing engine, then the reporting rebuild.
Now count the cost of waiting. The CRM upgrade goes live at week 8, the warehouse link at week 12, the pricing engine at week 14 and the reporting rebuild at week 15. Each project's drag cost runs until it is live: 8 × $10,000, plus 12 × $20,000, plus 14 × $15,000, plus 15 × $4,000. That is $590,000.
Sequence by slope instead: pricing engine, warehouse link, reporting rebuild, CRM upgrade. They go live at weeks 2, 6, 7 and 15. The drag cost is 2 × $15,000, plus 6 × $20,000, plus 7 × $4,000, plus 15 × $10,000. That is $328,000.
Same 4 projects, same team, same 15 weeks, and $262,000 less value lost. The major project the matrix told Ridgeway to schedule later was the best use of its scarcest team, and the most obvious quick win was the worst.
Why can't project-by-project scoring see this?
Because each dot on the matrix is scored as if it were the only claim on your people. Flow Economics calls that assumption the Project Illusion: the belief that if every project is assessed and run well on its own terms, the portfolio will perform well. A project's total effort is a fact about that project. Its draw on the constraint, and the delay it imposes on everything queued behind, are facts about the portfolio, and a grid of independent dots has nowhere to record them.
Isn't this just weighted shortest job first?
The objection you are already forming: this is weighted shortest job first, or cost of delay divided by duration, and agile frameworks already use it.
It is the same family, and the credit is deserved. The difference is the denominator and the units: weighted shortest job first usually divides by job size, which brings back the total-effort problem, and often scores cost of delay in relative points. Dividing a dollar figure by constraint weeks does two things a points score cannot: it ranks work by what it consumes of the one resource that is actually scarce, and it produces a number your finance director can check.
How do you rebuild your matrix?
You can keep the slide. Change what is on it.
1. Name the constraint. One team or skill: the one most projects queue for.
2. Replace the effort axis. Estimate each project's weeks or hours at the constraint, and nothing else.
3. Replace the value axis. Estimate drag cost, what each project is worth per week once live, in dollars. Rough is fine. You need the ranking, not the decimals.
4. Drop the quadrants. Rank by slope, drag cost divided by constraint time, and give the constraint to the steepest project first.
5. Re-rank when something changes. A new project, a revised estimate or a shift in the constraint changes the slopes. The ranking is a sequence, not a verdict.
The matrix was always asking the right question. It measured cost in the wrong currency and drew the answer in boxes. Measure cost in constraint time and value in drag cost, and the answer becomes a single ordered list, the same one argued from the other direction in Stop Ranking Projects by How Big They Are.
Leave a Reply