Last week we published Seven systemic interrupts, seven patterns mined from five months of core team meetings. The one that started the longest conversation afterward was the least dramatic: administrative latency on the critical path. An approval waiting on someone out of office. A purchase order sitting for a month. Hardware held in customs with no ETA. These have an FTTM name: host interrupts, the drag a team experiences where it meets the host, everyone outside the project team whose job is to help the team go fast. Legal, procurement, finance, quality, facilities, and the executive staff are all host, and the host’s full job description is a paper of its own.

Start with why the host is slow, because it is not laziness and it is not malice. The host is measured on control. Legal is measured on risk avoided. Procurement is measured on price and compliance. Quality is measured on defects caught. In their minds, speed comes at the expense of control and quality, and is to be avoided. Nothing in their measurement system pays them to make your critical path shorter. Blame the scoreboard, not the people playing to it.

The second reason is arithmetic. Host departments are staffed lean, so requests back up in them the way work backs up at the slowest machine in a factory. The queue is set by the department’s processing speed, not by your urgency. Goldratt built a whole management philosophy on this in The Goal (1984): an hour lost at a bottleneck is an hour lost for the entire system. A fully loaded department delivers everything late, no matter how loudly each requester yells. And everyone yells, because nearly every request arrives already late.

Diagram of requests queuing at a bottleneck department that is staffed lean and measured on control, processing one request at a time
Why the host feels slow. The queue is set by the department’s processing speed, not by your urgency.

The two levers

There are exactly two ways to get the host to move faster, and yelling is not one of them.

Card showing the two ways to move the host: give them warning, and show them the impact
The only two ways to move the host.

Give them warning. The host will act if it has warning, and it appreciates getting one, because most people ask the host to deliver immediately, and the host rarely finds out about the request until it is already late. The practice is simple: for anything that touches procurement, legal, customs, or any other host function, the program manager preps everyone involved ahead of time that something is coming their way, and asks them to raise issues now, not when it arrives. This is before-the-fact leadership applied to the host. Ownership travels with the warning: the name on an activity in the schedule is not just a name that reports updates. It is a task they own.

Show them the impact. Once the host sees how their task lands on your schedule, they tend to be responsible and help. Most people are yelling at the host for things they needed yesterday, but never show them the impact. The chart does what the yelling cannot: it turns a request into a consequence.

The approval that moved in a day

The best example we have involves the slowest host imaginable: a government. We were helping manage the whole program for the Chengdu joint-venture foundry fab between GlobalFoundries and the Chinese government: the construction, the installation of the tools, and the start-up of the fab into production. The joint-venture partner, the local government, was delaying the Environmental Impact Statement (EIS) approval, and the approval sat on the critical path. Every week our client at GlobalFoundries presented the major project milestones on the wigglechart. The partner watched the forecast line climb and asked why the line was going up. The answer was the critical path with the EIS approval sitting on it, shown honestly, in days. The report was approved the next day, and site work could start.

Nobody escalated harder. Nobody wrote a sterner letter. The impact was shown once, on one chart, to the people who owned the delay. If a chart can move a government, it can move your legal department.

Three-step strip: the wigglechart is presented weekly, the critical path with the delayed approval is shown, and the approval is granted the next day
The approval that moved in a day: the Chengdu joint-venture fab and the EIS approval.

Make it a system

Warning and impact are habits. Four steps make them a system. Start an interrupt log for each project. Capture interrupts in real time, as the team hits them, not from memory at the end of the month. Set a bi-weekly meeting to review the log and action the fixes. And mine the interrupt logs across all projects quarterly, because the cross-project patterns, the systemic interrupts, are where one fix accelerates every program at once. The mining does not need to be manual: we use Otter.ai to record the refresh and pull-in core team meetings and Claude, integrated with the Otter database, to scrape the transcripts for systemic interrupts. The instructions live in a Claude skill, so a team can run the same analysis on its own, on a schedule. The example table from that analysis is the download below: seven interrupts, the evidence across a portfolio, and the one fix for each.

Not the enemy, not the weather

Teams treat host delay like rain: something that happens to them and cannot be changed, only endured. It is not weather. The host responds to exactly two signals, warning and impact. Give the warning early, show the impact honestly, and the department everyone swears is the slowest in the company will surprise you. A government approved in one day what it had held for weeks. Your procurement group is not harder to move than a government.

Related reading: Seven systemic interrupts, Provisioning Host, IBM’s “Provisioning Steering Committee”, Freedom to Act, Cost-of-Delay, The weekly schedule refresh, Targets and Trends, and Reward performance. Don’t incentivize it.

Downloads