Stop Ranking Projects by How Big They Are

Walk into most prioritisation meetings and you will see the same ranking logic at work. Projects are lined up by size. The biggest revenue, the strongest strategic fit, the highest score on the scoring model. The programme at the top of the list is the one that promises the most, so it gets the first call on the best people.

This feels like sound project prioritisation. It is not. Ranking work by its total value systematically promotes the projects that are the most expensive to run, and it does so precisely because they are large. To see why, you have to stop looking at the project and start looking at what it consumes.

The trouble with conventional project prioritisation

Every portfolio has a constraint. That is the specific team, skill or asset that actually limits how much the organisation can deliver, no matter how much other capacity is sitting around it. It might be your two senior integration engineers, your one regulatory specialist, or a single test environment everything has to pass through. Work that never touches the constraint can be scheduled freely. Work that does touch it is competing for the most valuable hours in the business.

Conventional prioritisation ignores this. It ranks projects by what they return, and stays silent on what they cost in constrained hours to get there. The result is a built-in bias. A flagship programme that returns a great deal but monopolises the constraint for months will always outrank a modest piece of work that returns less. On a total-value ranking, big beats small every time.

But the flagship is not just delivering value. It is holding the scarcest resource hostage while it does. Everything else that needs those same hours waits. And the cost of that waiting never appears on the flagship's business case, because a business case only ever prices one project at a time. Judging each piece of work as if it were the only claim on your people is what Flow Economics calls the Project Illusion, and it is exactly the illusion a total-value ranking encodes.

The number that actually orders the work

The fix is to rank work not by its value, but by its value per constrained resource hour: the economic value a piece of work produces divided by the hours of the constraint it consumes.

The idea comes from the economics of any bottlenecked system. When one resource limits throughput, the right thing to maximise is not output per project or how busy each person looks. It is value produced per hour of the constraint's time. Every other hour in the business is comparatively cheap. The constraint's hours are the ones you can never get back, so they are the ones your ranking has to be built around.

The calculation is deliberately simple. Take the economic value the work will produce. Divide it by the number of constrained hours it will consume. A high number means the work returns a lot for every scarce hour it uses. A low number means it is an expensive way to spend the constraint, however impressive the project looks in isolation.

A worked example

Suppose two projects are competing for the same scarce specialists.

The first is a flagship programme worth 1.2 million pounds. Delivering it will take 4,000 hours of your constrained team. That works out at 300 pounds of value for every constrained hour it burns.

The second is an unglamorous internal project worth 200,000 pounds. It needs only 400 constrained hours, because most of its work sits away from the bottleneck. That is 500 pounds per constrained hour.

On a total-value ranking, the flagship wins by a distance and takes the team first. On a value-per-constrained-resource-hour ranking, the modest project is worth two thirds more for every scarce hour it uses. Run it first and you free the constraint sooner, so the flagship can still follow, having lost far less time than the flagship would have cost the smaller project the other way round.

The numbers here are illustrative, not a benchmark. The point is the reversal. Rank by size and you get one order. Rank by return on the constraint and you often get the opposite, and the opposite is usually the one that delivers more total value, faster.

What the ranking changes

Once you order work this way, three things shift.

Small work that feeds or releases the constraint stops being an afterthought. A one-week task that removes a dependency choking your specialists can outrank a six-month programme, because it returns enormous value for a tiny number of constrained hours. Conventional ranking never surfaces work like that, because it is too small to score well on its own.

Sequencing becomes an economic decision rather than a political one. The question stops being whose project is most important and becomes which order of work returns the most per scarce hour. That is a question with a defensible answer, which is worth a great deal in a room where everything is claimed to be urgent.

And "just add it to the list" gets harder to say. When you can see the return every project makes on the constraint, adding another heavy consumer of scarce hours is visibly a decision to slow everything else down. That is the same discipline that keeps a portfolio below its coordination ceiling, the point past which more concurrent work reduces total throughput instead of raising it.

Where it breaks, and how to keep it honest

The metric is only as good as two inputs, and both take discipline.

The first is knowing your real constraint. Most organisations have a vague sense of where they are stretched but have never named the specific resource that governs delivery. Get this wrong and you will optimise the wrong hours. The constraint is wherever work queues longest and where relief would return the most, not simply wherever people feel busiest.

And the constraint will move. In a portfolio running many projects at once, the bottleneck is not a fixed point on the org chart. Add people to today's constraint and the limit can shift to the next resource in line. Lose a key specialist, bring a new programme onstream, or watch a risk you were carrying turn real, and a team that had slack last month becomes the thing everything now waits on. A ranking is only ever right for the constraint you have today, so treat it as a live reading rather than a settled fact. Re-check where work is queuing whenever the shape of the portfolio changes, and expect the order to change with it.

The second is attaching an economic value to each piece of work. Many organisations approve a project on a business case and then let the value side drop out of sight once delivery starts. Value per constrained resource hour forces that number back into the open, which is uncomfortable but healthy. Without a value, you cannot rank at all.

Finally, watch for gaming. Any metric that decides who gets the best people will be argued with. Keep the constrained-hour estimates honest and revisit them as work moves, or the ranking becomes a negotiation rather than a measurement.

None of this needs a new tool or more data than you already hold. It needs a change of denominator: from what a project is worth, to what it is worth per hour of the resource you can least spare. That single shift is what turns "everything is important" into an order you can stand behind.

If you want to see how this metric sits alongside the rest of the economic view of a portfolio, the Flow Economics framework lays out the full picture.