# Waiting *Count the waits before the work* --- Most of the time a piece of work spends inside a business, nobody is working on it. Stalk and Hout put a number on this in *Competing Against Time* in 1990, from Boston Consulting Group's research: a product receives value for at most 5% of the time it spends in the system, and often a small fraction of that, and the rest is waiting. They split the waiting three ways, roughly equal: for a batch to be complete before anything moves, for rework of one kind or another, and for a management decision to send the work forward. The third is the one I recognise. There was an operational process the team had been screaming about, and the right senior people agreed in principle inside a week that we could remove it and take a simpler approach. A month later I realised nothing had actually changed. Nobody disagreed. People were waiting for some further formalisation of the decision, and none of the functional managers felt they had the mandate to just go and operationalise it. I forwarded the original email round to say everyone's aligned, let's get on with it, and we were still stumbling along on a decision I thought we'd made. The work in that month was nil, and nobody in that room had been made responsible for the first step. Stalk and Hout argue that this is where competitive advantage was hiding. Their rules of thumb are memorable and should be held loosely: quarter the elapsed time of a process and productivity doubles while cost falls by about a fifth; companies that compete on time grow at three times the rate of their industry with twice the margin. They are consultants' numbers from the 1980s; hold the idea and let the ratios go. Speed lives in the waits, because nearly all the elapsed time is waiting, and working faster on the 5% barely moves it. ## What waiting costs Waiting looks free because nothing is being spent on it, and work that waits decays. A deal that takes three months to reach a decision spends three months exposed to everything that kills deals: the champion changes job, the budget gets reallocated, a competitor gets there first, the problem stops hurting. Nobody sold any worse; the deal died in the queue. It is the same shape as the problems that reach your own desk: the time it takes to fix one you have been told about is typically longer than the time it takes for the next to arrive, which is the whole of why a queue grows. A business with a hundred new leads a month, a win rate of one in four at the point of decision, an average deal of £20k, and a live deal's chance of dying while it waits of about fifteen per cent a month wins about 21 deals a month on a one-month cycle. Stretch the same process to three months, with the leads, the sellers and the win rate unchanged, and it wins about 15, because nearly two in five of the deals never reach a decision. From a standing start that's £6.4m of revenue over two years against £9.8m. And the pipeline report gets better while this happens, because a slow process holds more in it: about 260 deals in flight instead of 100. Fifteen per cent a month is a number your CRM's aged-pipeline report will give you for your own business, and it falls in long enterprise cycles where the buyer's calendar sets the pace; put your own in below, along with how much of that cycle is your queue rather than the customer's. <iframe src="https://anishshailpatel.github.io/instruments/the-cycle.html" title="A slow sales cycle: deals die while they wait and the pipeline swells" width="100%" height="1040" style="width:100%;border:0;display:block;margin:1.2em 0;" loading="lazy" sandbox="allow-scripts allow-same-origin"></iframe> Work in progress is arrival rate times time in the system, so a process that takes three times as long carries close to three times as much if nothing dies on the way, and about two and a half times once it does, and from the top that looks like a healthy funnel. A fat pipeline can't tell you whether it's demand or delay; divide it by the month's new leads and you get the cycle time, which can. It's the arithmetic behind [[Turnarounds|the row of boxes]]: the work per job didn't speed up, jobs stopped sitting, and everything in the queue waited less. ## Where to look I have a problem with the idea of marginal gains, which got popular off the back of British cycling in the 2000s and mostly gets applied wrongly in business, because what people take away is that they should make everything a bit better. Most systems in a business are multiplicative rather than additive, so a zero somewhere wipes out the marginal gains everywhere else. Find the longest wait and put the energy there. There is always a weakest link, and when it moves you follow it, sequentially rather than all at once. Batches, in a business that doesn't run a factory, are the meetings that only happen monthly. A decision that's ready on the third of the month and waits for the review on the twenty-eighth has spent most of the month in a batch, and the monthly cadence of most management is a batch size no one picked. The monthly review is for [[Reading the numbers|reading the numbers]]; decisions shouldn't have to wait for it, and a weekly session that decides things cuts the wait by three quarters, for the price of an hour of senior time and decisions taken on a week's information rather than a month's, which most businesses would pay. Rework arrives as the paper that comes back for the third time, the case rebuilt because the first version answered a different question, the estimate redone because the question was never asked. Most of it is a decision that wasn't clear enough the first time round. A decision isn't made until someone with the mandate has started doing it, so the meeting that agrees a thing should end with a name against the first step, and the person with the name shouldn't need a second meeting to feel entitled to take it. Some waits buy information, and the test is whether anything you'd learn would change the decision. And going fast on the wrong thing is faster waste; the book's fast companies were fast at the things customers were waiting for. There is a fourth place to look, and it is your own doing. I struggle with the start and end of change programmes in a business this size, because the people involved in the change are usually the same ones needed inside the machine, so the work goes into sequencing and unblocking rather than into contractors and branded initiatives. The failure mode I watch for in myself is lobbing out half-ideas too quickly: they clog up people's attention and the focus gets lost. Part of the job at this size is sitting on ideas and releasing them at a rate the business can absorb. ## The customer's clock Then there are the waits that aren't yours at all. The delivery report says four months late, on budget, amber, recovery plan in place, and the conversation it starts is about whether four months is acceptable. Nobody can answer that, so it runs for a while. I've sent a budget back over exactly this. The first cut of the plan for a business I'd just taken over had a delivery date in every assumption and nothing about what missing one would cost, and getting that in took proper pushback into the teams - it was never going to surface bottom up, because nobody had asked the delivery side to think about the customer's calendar. The number that would have settled the argument wasn't in the report: how often the customers could buy. Take a £1.2m build over nine months, worth £900k a year once the customer base is fully on it, which takes about two years from launch. Judge it over five years, the way a board will, so a delay pushes benefit off the end. That convention overstates every delay, and it takes "on budget" at its word, though four more months of a team on payroll rarely is. The shape is what to look at, and the shape survives both corrections. Leave the slip at four months and change only how often the customers can buy. <iframe src="https://anishshailpatel.github.io/instruments/what-a-slip-costs.html" title="What a four-month slip costs on different buying cycles" width="100%" height="1120" style="width:100%;border:0;display:block;margin:1.2em 0;" loading="lazy" sandbox="allow-scripts allow-same-origin"></iframe> When customers can buy in any month, a four-month slip costs four months of benefit, about £300k of five-year cash, and payback moves from month 36 to month 40. The pack said four months late, and for once the pack has it about right. The cost stays linear, because there's never a wait for the next chance to sell. When they buy once a year, the same slip costs £900k and pushes payback out by a year. The build is ready in month 13, the window was month 12, and the customers commit in month 24. One month past the window is the whole of it; the other three months of the slip cost nothing, because they were absorbed by slack that was already there. On a three-year cycle the slip costs nothing at all, with the next window in month 36 and 23 months in hand, and on that cycle the project doesn't pay back inside five years even on plan, so it's a different conversation. > [!note]- The working > £900k a year is £75k a month at full adoption, and adoption ramps: 40% of it in the first year on the customer, 75% in the second, full from the third. Selling from the month it's ready, the cumulative line crosses zero at month 36 rather than month 25, which is what the ramp costs you. The instrument runs the same arithmetic and draws the line. Months late against a plan is a real number, honestly produced, and it's linear: four months late is twice as bad as two. What it costs isn't. That is flat, then a cliff, then flat again, and where the cliff sits has nothing to do with the project team. I've run businesses whose customers could only really buy once a year, and a month late in the wrong month was a year late, which no good quarter recovers. The model is generous here, treating a missed window as pure deferral when customers who committed elsewhere in month 12 are often gone for a contract term. Plenty of businesses have no cliff at all, though: where renewal dates are spread across the base it flattens into a slope and a month late costs roughly a month, and that's worth checking before you assume you've got the harder problem. Ready isn't sellable, either. On an annual round the customer needs demos, procurement and a signed order before the window, so the real slack is a few months shorter than the gap between the build and the window, and it gets spent unless somebody's counting it. Two projects with the same slip on the report can carry very different risk. The one due three weeks before the renewal round deserves the attention, the contingency and the ruthlessness about scope, and the one due three weeks after it has eleven months in hand. The RAG report colours both the same. ## The two numbers to write down The delivery date is the least of it. You need the buying moment, which for many businesses is a real and knowable date: an annual budget round, a licence renewal, a fleet replacement, a maintenance contract. Then when the next one falls relative to when the build is ready, and how much slack that leaves, in months, written down where everyone can see how much of it has been spent. With that on the page the schedule meeting has a question the room can actually answer, which is whether the build still lands inside the window. When it's going to miss, the lever is scope: cut to what lands the round and backfill after it, and decide now who calls that, because in the week it's needed there won't be time. The right answer to "we've slipped a month" is sometimes that it doesn't matter yet, and you want to be able to say so with the months of slack written next to it. The work usually turns out to be a few days and the elapsed time a few months. The person who owns the outcome is the one to measure the second number, and in most businesses that measurement is no one's job. ---