Intake queue prioritization when every show director says theirs is first

Three show directors are in the capacity meeting and each has an argument for going first. March has the earliest date. Frankfurt has the biggest rebooking exposure. The new launch has nothing at all in market and needs six weeks of lead time to have a chance.

All three are telling the truth. That is the part most intake queue prioritisation schemes get wrong: they are built as though somebody in the room is exaggerating, when the actual situation is three correct statements that cannot all be acted on. What is missing is a shared rule for turning three correct statements into an order.

Every show director is right, which is the problem

A queue with no published rule gets ordered by whoever asks most persistently, and persistence correlates with seniority and proximity to the studio. That produces a ranking, it is just a ranking nobody would defend out loud.

The instinct is to score importance. Give each request a rating from one to five for strategic value, average the ratings, sort. This fails predictably, because importance has no denominator. A request worth 5 that takes nine weeks and a request worth 4 that takes two days both sit near the top, and the studio spends its quarter on the nine week item while eleven two day items age behind it.

Donald Reinertsen's The Principles of Product Development Flow, 2009, makes the economic case in a form that transfers directly. The sequence that maximises value ranks jobs by their cost of delay divided by their duration, which means a short job with moderate value routinely beats a long job with high value. Ranking by value alone gets the order wrong in a way that costs real money, and the loss is invisible because nobody ever sees the counterfactual queue.

Cost of delay divided by effort

Two inputs per request. Both are estimates and both can be wrong by a wide margin without breaking the ranking, which is the property that makes this usable by people who are not analysts.

Cost of delay is the value lost for every week the request waits. For event work it usually comes in one of four currencies: studio hours saved per edition, media spend that gets wasted without it, revenue at risk on a rebooking or sponsorship deadline, or registrations lost from a campaign that starts late. Pick one currency per portfolio and stick to it, because comparing hours against pounds across a queue produces arguments about the exchange rate instead of the order.

Effort is the studio time to complete, in weeks, at the granularity your team actually plans in. Half weeks are fine. Days are false precision.

Both numbers only make sense for work that still needs doing at all, so run this after the routing pass. Anything triage sent straight to production because it reuses an approved decision never reaches the ranked list, and on most weeks that removes more than half the board before any arithmetic starts.

Divide the first by the second. Sort descending. That is the whole mechanism, and the reason it survives contact with a portfolio is that both numbers are visible and arguable, so a show director who disagrees with the ranking has somewhere specific to push.

What is the cost of delay for an event request?

The question people stall on, because most requests do not obviously lose money by waiting a week.

Three workable ways to get a number. First, recurring saving: if the request removes 40 hours of production per edition and editions come round every six weeks on average across the portfolio, each week of delay costs about 6.7 hours of studio time. Second, exposure: if a sponsor renewal pack is late, the sales team loses a week of a nine week window, so the cost of delay is roughly a ninth of the revenue at risk in that window. Third, wasted spend: if paid media starts without the landing page, the cost of delay is the media spend running against a worse page, which finance can price to the pound.

Requests that produce nothing under any of the three have a cost of delay near zero, and that is a genuine finding rather than a failure of the method. Roughly a fifth of a typical queue turns out to be work nobody loses anything by never doing, and surfacing that is worth the exercise on its own.

Two requests, one week each, and the order that saves hours

Here is the arithmetic worked all the way through, because the sequencing effect is the part people find counterintuitive.

Request A rebuilds the exhibitor manual template. It saves 40 hours of studio production per edition. With eight editions a year, one comes round roughly every six weeks, so each week of delay costs 40 divided by 6, about 6.7 hours. Effort: one week.

Request B fixes the speaker submission form. It saves 12 hours per edition, so each week of delay costs 12 divided by 6, about 2.0 hours. Effort: one week.

Ranking is obvious here since the durations match: 6.7 beats 2.0, so A goes first. What is worth seeing is the size of the difference the order makes.

Do A first. A finishes at the end of week one, so it waited one week and cost 6.7 hours. B finishes at the end of week two, so it waited two weeks and cost 4.0 hours. Total delay cost 10.7 hours.

Do B first. B waited one week and cost 2.0 hours. A waited two weeks and cost 13.4 hours. Total delay cost 15.4 hours.

The difference is 4.7 hours of studio time, produced by nothing except the order of two jobs of identical length. Scale that across a queue of thirty items with durations from half a week to four weeks and the sequencing effect becomes the largest single lever a production lead has, larger in most quarters than hiring another designer.

One caution on the denominator. When durations differ, the ranking flips more often than intuition suggests. A request with a cost of delay of 3.0 and a duration of half a week scores 6.0 and beats our request A, despite being worth less than half as much per week. That is correct and it is the point of the denominator, and it is also the result that makes people argue, so publish the arithmetic and let them.

Where the edition date sits in the ranking

Outside it. The edition date is a constraint that schedules work before the ranking runs.

Anything whose value goes to zero if it misses a date gets placed against that date first, working backwards from the deadline with the studio time it needs. Only the remaining capacity is ranked by cost of delay divided by effort. Trying to express a hard date as a very large cost of delay looks tidy and behaves badly, because a large number still trades against other large numbers and a deadline does not trade at all.

Goldratt and Cox set out the reason in The Goal in 1984, and it applies here directly. An hour lost at the bottleneck is an hour lost from the whole system, and in a studio the bottleneck is usually one reviewer rather than the designers. If your dated items all funnel through the same approver in the same week, the schedule you built from the dates is fiction, and the fix is upstream of any ranking rule. Sizing that properly means knowing how many briefs a month the team completes, which is a capacity planning question rather than a queueing one.

Why does publishing the ranked queue end the argument?

Because it moves the argument from eight private conversations into one public one, and public arguments about a shared rule converge.

Publish four columns: the request, the cost of delay with its currency, the effort, and the resulting score. Sort by score. Anyone who wants to move up the list has two honest routes, which are to argue the cost of delay number up or to argue the effort number down, and both are checkable claims about the world.

What disappears is the corridor conversation, where a request moves because somebody caught the production lead at the coffee machine. That conversation was never about the merits and everybody knew it. Its replacement is a five minute item in the weekly call where two numbers get challenged, which is a better meeting and a shorter one.

The queue needs a home where requesters can see their own position without asking. That is a small feature with a large behavioural effect, and it is one of the things a shared request and brief workspace is for. It also depends entirely on the queue being complete, which means every request has to arrive through the intake form rather than a direct message, since work that is not in the list cannot be ranked and will quietly consume the capacity you allocated to things that were.

Where this stops

The ranking is only as good as the cost of delay estimates, and those estimates are produced by the people asking for the work.

There is an obvious incentive to inflate. In practice inflation is self limiting when the numbers are public, because a show director claiming 60 hours saved per edition on a template rebuild will be asked by another show director where the 60 comes from. It is much less self limiting when only the production lead sees the inputs, which is the strongest practical argument for publishing them.

The deeper limit is that this ranks requests against each other and says nothing about whether the portfolio should be attempting all of them. A queue perfectly ordered by cost of delay divided by effort, running at 130 per cent of capacity, delivers the top items on time and everything below the line late, every quarter, for ever. Ordering does not create capacity. It decides which promises you break, and doing that deliberately is the entire benefit.

This week, take the ten items currently in your queue and write two numbers against each: the value lost per week of waiting, in whatever currency fits, and the studio weeks to complete. Sort by the ratio. If the resulting order looks nothing like your current order, the gap between the two is what the ranking is worth.