The Expedite Tax: Why Rushing One Project to the Front Delays Everything Behind It
Somewhere this week, someone with enough authority to be obeyed will say "drop everything and get this one done." A project that was sitting patiently in the queue will jump to the front of your scarcest team, and everyone will treat the instruction as free, because moving a job up a list costs nothing to say. It is one of the most expensive sentences spoken in portfolio management, and almost nobody prices it before they say it.
The reason it feels free is that an expedite does not add work. The hours are the same; the team is the same; the total amount to be done has not changed by a single day. All that has changed is the order. And because nothing was added, it looks like nothing was spent. But in a constrained portfolio the order is where the money is, and reordering the queue moves cost around in a way that is very real and almost never counted. This piece is about that cost. I am going to call it the expedite tax: the value destroyed when you push one piece of work to the front of a constrained resource, paid entirely by the work it jumped.
An expedite is a reordering, and reordering is never free
Start from the thing that makes an expedite possible at all: a queue. If your scarcest resource, the constraint that sets your delivery speed, had spare capacity, there would be no queue to jump and nothing to expedite; the urgent job would simply start. Expediting only means something because the constraint is loaded, which means there is a line of work in front of it, which means moving one job forward pushes every job it passes backward by exactly the time the expedited job occupies the constraint.
That backward push is not a metaphor. Each job that gets leapfrogged now finishes later than it would have, and later finishing is not neutral. Every one of those jobs has a cost of delay, a rate at which value drains away for each week it is not done. So the moment you expedite, you start three separate meters running against the portfolio at once. The expedited job's meter stops sooner, which is the benefit you can see. The meters of every job it jumped run longer, which is the cost you cannot. And the act of putting down whatever the constraint was working on and picking up the urgent thing carries a switching cost of its own, the setup and re-establishment that interrupting mid-task always demands.
The expedite is worth it only if the first meter saves more than the other two spend. That is a specific, checkable arithmetic condition, and the striking thing about how expedites actually get ordered is that nobody checks it. The decision is made by looking at one job, the urgent one, and never at the queue behind it. You are shown the value of stopping one meter and never the bill for starting the others.
Why the tax is invisible
The expedite tax has every property that guarantees a cost gets ignored.
It lands on the wrong project. The benefit of the expedite is credited to the urgent job, which visibly speeds up and whose sponsor is delighted. The cost is charged to three or four other projects, which each slip by a bit, on separate plans, owned by separate managers, none of whom can see that their shared slippage has a single common cause sitting at the top of the queue. No one project's slip is large enough to raise an alarm. Added together they dwarf the saving, but nobody adds them together, because no report is drawn on the axis where the sum would appear.
It is a delay, not a spend. The tax is paid in value that arrives later, not in money that leaves the account, so it never shows on a budget line and never triggers a variance. A project that finishes three weeks later for £18,000 of delayed benefit looks, on every financial system you own, exactly like a project that finished on time.
And it is self-concealing, because expediting works. The urgent job does go faster; the promise is kept; the sponsor's confidence in "drop everything" is confirmed and reinforced. The method looks vindicated precisely because you only ever measure the meter it stopped, never the meters it started. Success on the visible half of the ledger is what funds the invisible losses on the other half.
A worked example
Put numbers on one expedite. Illustrative rather than exact; the shape is the point.
Your constraint is a single integration team that can work one project at a time. Four projects are waiting on it, and you have sensibly sequenced them, so the queue reads A, then B, then C, then H. Each of A, B and C needs two weeks of the team's time; H needs three. In the planned order, H waits through six weeks of A, B and C before it starts.
Now the instruction arrives: H is urgent, move it to the front. H has a cost of delay of about £5,000 a week. By jumping six weeks of queue, it finishes roughly six weeks sooner, so the expedite saves about 6 x £5,000 = £30,000 of delayed value. That is the number the room sees, and on its own it is a good number.
Here is the number the room does not see. Inserting H's three weeks ahead of A, B and C pushes each of them back by three weeks. Their costs of delay are not identical: A runs at £4,000 a week, B at £6,000, and C at £7,000. So the three weeks of slippage you just handed them costs 3 x (£4,000 + £6,000 + £7,000) = £51,000. And because the team was already part-way into A when the order came, putting A down and picking it back up later spoils some in-progress integration work and re-establishes context that was already paid for once, burning something like a further week of your scarcest capacity to no output at all.
Tally it. The expedite saved £30,000 and imposed at least £51,000, before the switching cost. "Drop everything" destroyed on the order of £21,000 of portfolio value, and every actor behaved reasonably throughout. Notice what did not change: the total makespan. The same four projects still take the same nine weeks of the constraint to clear. No work was added and no work was removed. All that moved was the order, and the order alone cost twenty-one thousand pounds.
Now look at the detail that makes the whole thing sting. H was expedited at £5,000 a week and, in doing so, jumped C, which was losing value at £7,000 a week. Week for week, C was the more urgent project the entire time. The expedite did not promote the costliest job to the front; it promoted the loudest. Urgency, as it was actually measured in that room, was a volume of voice, not a rate of value.
Why single-project management is structurally blind to this
If the loss is this clear once you write it down, why does it happen every week? Because the frame most organisations manage in has no place to record it.
Managed as a set of independent projects, each one is tracked against its own schedule and its own budget. The expedite tax is neither. It is not the urgent project's cost, that project only benefited. It is not fully any single victim's cost either, because each victim absorbs only a slice small enough to look like ordinary slippage. The tax exists only in aggregate, across projects, and a single-project frame has no instrument that reads across projects. The number lives in the space between the plans, and there is no plan for the space between the plans.
Worse, everyone inside the frame is behaving well by their own lights. The sponsor of the urgent job is fighting for their project, which is their job. The executive who grants the expedite is being responsive to a real business need, which is theirs. The delivery team is doing exactly as instructed. Every local action is defensible, and the destroyed value emerges from the sum of defensible local actions, belonging to no one who could be said to have made a mistake. This is the Project Illusion in one of its most reflexive forms: a portfolio can honour every urgent request, keep every promise it makes to the loudest voice, and be measurably worse off for it, because the thing being optimised was the responsiveness of each decision and never the economics of the queue those decisions rearranged. Being asked to sequence a shared constraint by cost of delay, and instead sequencing it by who asked most forcefully, is not a failure of effort. It is a failure to notice that when a job runs, relative to the others, is an economic variable, not a courtesy to be handed to whoever is most senior in the room.
What to do instead
The remedy is not to stop expediting. It is to expedite on the rate of value rather than the volume of the voice, and to make the tax visible at the moment the decision is taken. A few rules do most of the work.
1. Price the queue-jump before you order it. Before any "drop everything," run the two-sided sum the worked example ran: the delay saved on the urgent job against the delay imposed on everything it jumps, plus the switching cost of the interruption. If the second number is larger, the expedite is destroying value and the honest answer is no. This calculation takes minutes and is almost never done, which is precisely why the tax is so reliably overpaid.
2. Rank the queue by cost of delay per constraint-hour, not by urgency. The stable fix is upstream of any individual expedite: sequence the work on your constraint by what it returns per hour of that scarce resource, exactly as you would rank the portfolio by its return on the constraint. A queue ordered by value per constrained resource hour rarely needs expediting, because the genuinely most valuable work is already near the front. Most expedites are corrections to a queue that was ordered by something other than value in the first place.
3. Keep one expedite lane, and cap it at one. If you must have a mechanism for genuine emergencies, make it a single, formal, visible slot: one expedited job at a time, no more. A limit of one forces the organisation to choose, which surfaces the truth that everything cannot be top priority, and it bounds the tax to one job's worth of disruption instead of letting the whole queue churn. An expedite lane with no limit is not a lane, it is just the queue reordered continuously by whoever spoke last.
4. Full-kit the thing you expedite. There is no sense paying the tax to rush a job to the front of the constraint only for it to stall there waiting for a decision, a dependency or a missing input. Apply the same discipline you would apply to starting a project only when it can actually run, and to the decisions it will need on the way. If the urgent job is not genuinely ready to run start to finish, expediting it buys disruption and no speed.
5. Treat frequent expediting as a symptom, not a tool. If "drop everything" is a weekly event, the problem is not any single decision, it is that your constraint is carrying far too much work in progress, so the queue is long enough that things routinely age into emergencies. Chronic expediting is the fever, not the illness. Lower the amount of work in flight and the queue shortens, jobs reach the constraint before they turn urgent, and the need to expedite disappears.
The objection you are already forming
"This is fine in theory, but some things genuinely are urgent. A regulatory deadline, a customer about to walk, a live incident. Are you seriously telling me to leave those sitting in the queue because the arithmetic is inconvenient?"
No. Read the argument again. It does not say never expedite; it says never expedite blind. A real regulatory deadline or a churning customer does not have a vague, rhetorical urgency, it has a large and specific cost of delay per week, often far larger than anything else in the queue. That job will win the exact comparison this piece asks you to run, decisively, and moving it to the front is then not a favour to a loud sponsor, it is the correct economic call. The framework does not forbid expediting the genuinely urgent. It forbids expediting on the basis of who is most senior, most persistent or most recently in your office, when their job's actual cost of delay per constraint-hour is often lower than that of the quiet, unglamorous work it tramples on the way to the front.
The distinction the objection misses is the one between urgency and volume. The regulatory deadline and the pet project can be argued for with identical force in the room; they are worlds apart on the meter. All the discipline here does is replace the volume with the meter. Where the urgency is real, the numbers will say so and you will expedite with a clear conscience and a defensible sum. Where it is theatre, the numbers will say that too, and you will have declined to destroy twenty-one thousand pounds to reward the person who shouted loudest. Before you next say "drop everything," do not ask how urgent it feels. Ask what it costs the work you are about to interrupt, and let the two numbers, not the two volumes, decide.
If this changed how you hear the word "urgent," the two ideas it rests on are worth reading next: what a day of lateness actually costs, in Drag Cost, and the single number that should have ordered your queue before anyone ever needed to jump it, in ranking your portfolio by its return on the constraint.