Quality check in Monza
It was a Tuesday in November, somewhere in an industrial zone north of Milan. I had been invited by a family business that manufactured metal components — good clients, third generation, proud of their machines. The factory manager's name was Marco. He wanted to show me everything. First the intake, then the production line, then packing, then dispatch. He walked fast, with the kind of pride you see in people who built something themselves.
At each station he named the capacity. Eighty units a day at intake. Sixty-five at processing. Ninety at packing. Seventy at dispatch.
He said it in the tone of someone presenting good numbers. I asked him what the quality check could handle.
A short silence.
"Thirty," he said.
"And how many do you ship per day?"
"Thirty."
I said nothing.
He looked at the floor.
We walked back to his office. On his desk was a proposal from a supplier — new packing machines, plus forty percent capacity, ninety thousand euros. He had already requested a quote.
"Marco," I said, "if you buy those machines, how many units will you ship per day?"
He thought for a moment. "Thirty," he said quietly.
That was the moment he saw it. Not as an accusation — just as a fact.
A chain delivers what its weakest link allows. Everything before and after can run as fast as it likes: the quality check decided what came out at the end. The new packing machines would simply wait faster.
We spent that afternoon on the quality check alone. Not the whole factory — just that one step.
Two additional inspectors, a different table layout, a simpler checklist.
Four weeks later: fifty-two units a day. The rest of the line had been capable of that for years.
He didn't buy the machines.
What I learned that day: it's not about the average -> it's not about the sum. It's about the one place where everything piles up, waits, and stalls.
That place determines what the system delivers — not what it could theoretically produce if everything were ideal.
Improve the wrong step, and you work harder for the same result. Improve the bottleneck, and the whole chain moves with it.
Find it first. Then fix it.
Six months after Monza
Six months after the quality check in Monza, Marco sent me an email. Output had stabilised at fifty-two units a day. The team was pleased. He was pleased. He had framed the results for a board presentation.
He also mentioned, almost as an aside, that delivery times had started slipping again.
I drove back down in March.
The quality check was no longer the problem. It was running well — the reorganised workflow had held, the new checklist was embedded. But now packing was struggling to keep up. Orders were sitting finished and approved, waiting for boxes, labels, shipping documents. Two people doing a job that had quietly become a three-person job when output went up by nearly a third. Nobody had noticed because the attention had stayed on the quality check, which was now fine.
I pointed this out to Marco. He looked at the floor again — the same way he had six months earlier.
"We fixed the thing," he said. "I thought we were done."
That is the assumption that costs people the most. The bottleneck does not disappear when you solve it. It moves. The chain shifts, the pressure finds a new weak point, and if you are not looking for it, you will not see it until the results start slipping and nobody can say exactly why.
There is also a second problem, quieter and harder to see. When you fix a bottleneck, you often put rules in place to protect it — priorities, schedules, workarounds, agreements. Those rules made sense for the old problem. Once the Bottleneck moves, the rules stay. They accumulate. People follow them out of habit, or because they were never told they no longer applied. After a year, an organisation can be running on half a dozen procedures designed for problems it no longer has.
We spent that afternoon on packing. Three weeks later, delivery times were back to normal.
But what I told Marco before I left was more important than anything we did with the packing line.
"Set a date," I said. "In three months, walk the floor and ask the same question you asked six months ago. Where is it slowing down? Where are people waiting? Where is the work piling up? The answer will be different. It always is."
Continuous improvement is not a project with an end date. It is the same five steps, repeated. Every time you finish, you start again.
The bottleneck never disappears. It just moves to somewhere you are not looking yet.
The plant manager
It was February, grey in the way only the Ruhr can be grey. I was visiting a mid-sized manufacturer — automotive components, second generation, good engineers. They had a problem they had diagnosed correctly: one inspection station was holding back the entire line.
The plant manager was called Werner. Sixty, methodical, the kind of man who kept a notepad in his breast pocket and actually used it. He had already drawn up a plan before I arrived. A new inspection machine, sixty-eight thousand euros, delivery in ten weeks. He showed me the quote with the quiet confidence of someone who has already decided.
I asked him how many shifts the inspection station currently ran.
One, he said.
I asked how long the operators spent waiting for parts to arrive at the station.
He looked at his notepad. About forty minutes per shift, he said. Sometimes more.
I asked whether the inspection procedure had been reviewed recently — whether every check was still necessary, or whether some steps could be combined.
He was quiet for a moment. "Not recently," he said.
We spent the next two hours on the station itself, without buying anything. We reorganised the workflow. Eliminated two redundant checks that a process change three years earlier had made unnecessary. We talked to the shift supervisor, who had been quietly solving the wrong problems for months because no one had asked him what was actually slowing things down.
By the end of the week, output from that station had increased by thirty-one percent. No new machine. No new hire. One extra evening shift, three days a week.
Werner didn't cancel the quote immediately. But he put it in a drawer.
What the experience showed me was something I've seen confirmed many times since: the instinct, when you find your bottleneck, is to spend. Buy a machine. Hire people. Outsource. These options exist and sometimes they're the right answer. But they're expensive, they take time, and they lock you into a decision before you've understood the problem.
The cheaper levers come first. Use what you have, fully. Remove what's in the way. Align everything else around the Bottleneck. Only when those options are truly exhausted do you open your wallet.
Elevate is the last resort. Not the first instinct.
Numbers on the wall
The CFO had printed the figures on A3 paper and taped them to the meeting-room wall. Cost per unit, by product line, over four years. Most lines were moving down. He pointed at the charts with pride.
The company made industrial valves. Forty employees, one factory near Lyon and customers across southern Europe. It had been profitable for years. During the previous eighteen months, it had started losing money.
“What changed?” I asked.
“Price pressure,” he said. “A competitor from Eastern Europe.”
Their answer had been larger batches: longer production runs, fewer changeovers and lower unit costs. The charts showed that the plan was working.
“How much finished stock do you have?”
He checked a folder. Around four months on average. Some products had been sitting there for almost seven months.
“And how quickly do customers pay?”
“Sixty days.”
The company was paying to produce valves, storing them for four to seven months, and then waiting another sixty days for payment. Unit costs were falling, but the cash had stopped moving.
That is the danger of using cost per unit as your main compass. It measures what happens inside production. It does not show whether the product has been sold, whether the customer has paid or how much money is trapped in stock.
A batch stored for six months can have the same unit cost as a batch shipped next week. On the cost report they look equal. For the business, they are completely different.
We replaced the wall charts with three numbers:
Throughput: the rate at which the company generates money through sales—not production.
Inventory: the money invested in products and materials that have not yet been sold.
Operating expense: the cost of running the company and turning inventory into sales.
The direction was simple:
- Increase throughput.
- Reduce inventory.
- Reduce operating expense.
Every important decision was tested against these three measures, in that order.
By this test, the larger-batch strategy was failing. Sales had not increased. Inventory was growing. Operating costs had not fallen enough to make up for the cash tied up in the warehouse.
We reduced the batch sizes. The factory needed more changeovers and the reported cost per unit increased. The CFO took the charts off the wall, reluctantly.
Six months later, inventory had fallen by half. Cash flow was stable again. Two customers who had left because of long delivery times returned.
The theoretical unit cost was higher.
The business was healthier.
Measuring the wrong thing precisely is still measuring the wrong thing.
The warehouse
It was a Thursday in October. The warehouse smelled of cardboard and cold concrete.
I was there to examine a flow problem. The distributor had been in business for thirty years but could not understand why dispatch was always behind while the pickers were ahead of schedule.
The operations manager, Johan, had run the warehouse for eleven years. He knew every corner of it.
He had recently invested in a faster picking system. Picking output had increased by twenty percent.
Dispatch was still three days behind.
“Show me how an order moves through the warehouse,” I said.
Orders came in. The pickers collected the products. Packed boxes then moved to dispatch, where one person added labels and documents before handing them to the carriers.
Picking was fast. Dispatch had one employee, fixed working hours and a carrier collection time that could not be changed.
Between the two stations, boxes filled the corridor. Eighty on a quiet day. Sometimes more than a hundred and twenty.
“The pickers are doing well,” Johan said. “I don’t understand the problem.”
But that was exactly the problem.
Dispatch was the bottleneck: the step that controlled the actual output of the entire warehouse.
Picking worked as fast as possible. Dispatch also worked as fast as possible.
The difference in speed did not create more deliveries. It created a corridor full of boxes and a dispatch team that started each morning already behind.
We introduced a simple method: Bottleneck–Buffer–Release Signal.
The bottleneck sets the pace. Every other step must follow that pace, including the steps before it.
In front of the bottleneck, you create a small, controlled buffer. This is not an accidental pile of unfinished work.
It is a planned queue that protects the bottleneck from delays earlier in the process.
The release signal connects the bottleneck to the start of the flow.
New work is released only when the bottleneck has capacity—not because the first station is free or because another batch is ready.
Johan’s warehouse had no release signal.
Picking continued releasing orders simply because it could.
The boxes in the corridor were not a buffer. They were evidence that the flow had no control.
We changed the release schedule. Picking began working in cycles based on dispatch capacity.
By eleven each morning, the corridor was clear.
We did not make picking faster. We did not add staff to dispatch. We only changed what controlled the flow.
Making every step work faster does not make the whole process faster.
Before a bottleneck, extra speed only creates a larger pile.
The bottleneck sets the pace. Everything else follows.
The efficiency report
The production manager had prepared a professional presentation. Twelve slides showing efficiency improvements at four of the plant’s five stations.
Station A: up eighteen percent.
Station C: up eleven percent.
Station D: up seven percent.
Station E: up twenty-two percent.
The figures were correct. The methods were sound. He had spent six months achieving them.
“What about Station B?” I asked.
Station B was the bottleneck: a surface-treatment process limited by its equipment. It could handle forty units per hour. No more.
It had processed forty units per hour six months earlier. It still processed forty units per hour now.
Total plant output had not changed.
“But we improved four stations,” he said, looking back at his slides.
An hour lost at the bottleneck is an hour lost for the entire plant. Stop it for sixty minutes and sixty minutes of output disappears. The other stations cannot recover that loss by working faster.
The opposite is less obvious.
An hour saved at a non-bottleneck is not automatically an hour gained. Station A may produce faster, but Station B still processes only forty units per hour.
The extra units do not reach the customer sooner.
They wait on the factory floor and increase work in progress.
The efficiency report was accurate. The problem was the question behind it.
The team had asked, “Which stations can we make faster?”
They should have asked, “What is limiting total output, and how can we improve it?”
The answer was Station B. Yet it did not appear in the presentation.
We spent the next month working only on that station. Its maintenance had always been scheduled for Monday morning.
This stopped the bottleneck for ninety minutes at the beginning of the busiest day of the week.
We moved the maintenance to Sunday evening.
That single change recovered seven hours of bottleneck capacity each month.
Total plant output increased by six percent. Nothing changed at the other stations.
The presentation showed local improvements. Moving the maintenance created a result for the entire plant.
They are not the same.
A company can improve many separate activities and still make no real progress. Only improvements at the bottleneck change what comes out at the end.
Annual review
The meeting had been scheduled for two hours. It ran four.
The CEO had prepared a detailed summary of the year. Sales had exceeded target by twenty-two percent — a record. Production had increased machine utilization by eighteen percent. Purchasing had driven unit costs down by nine percent through consolidated buying. Logistics had cut cost per shipment by fourteen percent by consolidating loads. Every department head in the room had delivered. Every metric had moved in the right direction.
The company had lost three major customers.
I had been brought in after the third one left. Before the meeting I had spent two days on the floor and another day on the phone with the customers who had cancelled. The pattern was straightforward: lead times had doubled over eighteen months. Orders were booked faster than production could process them. Production ran machines in long batches to maximize utilization, which meant orders waited. Purchasing bought in volume to get unit cost down, which meant components arrived in bulk and sat in a warehouse waiting for production to need them. Logistics held shipments until trucks were full, which added days at the end of an already-extended process.
Every department had been optimized. The flow between them had not.
The problem with local efficiency targets is not that they are wrong in isolation. Lower unit costs are genuinely better than higher unit costs, all else equal. The issue is that all else is never equal.
When sales books faster than production processes, the excess becomes a backlog.
When production runs long batches, work-in-progress accumulates between stations.
When purchasing buys in volume, capital sits in stock.
When logistics waits for full loads, finished goods wait at the dock.
Each department had minimized its own cost.
The company's total cost — including the working capital tied up in the queues between departments, and the revenue lost from customers who stopped waiting — had gone up.
After the meeting, one of the department heads asked me what they should have measured instead.
The answer is simple but uncomfortable: measure the delivery performance to the customer. One number, measured at the end.
If that number is good, the internal processes are working together.
If it is not, the question is where flow breaks down — and that question cannot be answered by looking at each department separately.
You cannot optimize a chain by polishing each link in a different room.
The consultant
He had worked for the company for eleven years when they finally solved the problem.
I met him at a conference in Vienna. He was the quality manager of a mid-sized manufacturer in Linz producing industrial filtration components.
For three years, the coating station had been the main bottleneck.
Delivery times were unpredictable. Customers complained and pressure from management increased.
The company eventually bought a second coating unit, hired two operators and changed the production schedule.
The bottleneck disappeared.
He told me this as if the story had ended.
“What happened next?” I asked.
He paused.
“The problem moved. Coating produced almost twice as much, but quality control still had the same capacity.”
So they hired more inspectors and reorganized the quality process. Output increased again.
“And then?”
He smiled. “Packaging became the problem. After that, raw material intake. Eventually it was sales—we could produce faster than we could sell.”
The company had not completed an improvement project. It had completed one cycle in a process that never ends.
Every system has a bottleneck: one machine, process or handover that limits total output. When that bottleneck is improved, capacity increases until the system reaches its next weakest point.
That is not a failure. It is how real improvement works.
The aim is not to remove every bottleneck permanently. That is impossible. The aim is to find the current bottleneck, improve it and then look for the next one.
The quality manager had experienced these as separate problems. In reality, they were different stages of the same process.
Many companies treat a bottleneck as something unusual—an error that must be fixed and forgotten. They feel relieved when it disappears and frustrated when another one appears.
But the next bottleneck was already there. It simply did not matter yet because something else was limiting the system first.
Experience does not prevent the next bottleneck from appearing. It helps you find it faster.
He took out his phone and made a note.
“We thought we were finished,” he said.
“You were,” I replied. “With that one.”
The dashboard
The CFO had built the dashboard herself. It had taken three months.
It contained forty-seven KPIs across six tabs: finance, operations, sales, HR, logistics and strategy.
The strategy tab held fourteen additional metrics that did not fit anywhere else.
Everything was colour-coded. There were trend arrows and comparisons with budget, the previous year and the rolling twelve-month average.
Technically, it was excellent.
After three months, the management team had stopped looking at it.
I was asked to help the company improve its decision-making.
The real problem was more specific: it had good data but made decisions too slowly.
On my first day, I asked every management team member the same question:
“What decision did you make last week, and what information did you use?”
I received eight answers.
Six decisions were based on information that was not in the dashboard—conversations, emails, customer calls and experience.
The other two used dashboard data, but only after someone found and extracted the relevant figure. In one case, that took forty minutes.
The dashboard answered questions nobody had asked.
It did not answer the questions managers actually faced.
Information overload does not mean the data is wrong.
The problem is that data without a decision behind it has no practical purpose.
If a metric does not affect what you do, it is decoration.
Forty-seven well-organised decorations still do not make a management system.
We brought the management team together and asked a different question:
“What decisions do you make regularly, and what is the minimum information needed to make each one?”
The session produced eleven information requirements. Eight were already available in the company’s systems. Three required some simple new tracking.
None required forty-seven KPIs.
The new report was one page. It was generated automatically every Monday morning and arrived before eight o’clock.
The team reviewed it during the first fifteen minutes of its weekly meeting and used it to make decisions.
The CFO later asked whether her dashboard had been a waste of time.
“No,” I said. “It was a good answer to the wrong question.”
The wrong question was: “What data do we have?”
The right question was: “What do we need to decide?”
Start with the decision. The information you need will follow.
Start with the data, and you will always end up with more than you can use.
Price of an idle hour
The operations director had a clear view:
“If a machine is not running, it is costing money.”
It sounds logical. In some situations, it is also wrong—and can seriously damage a business.
I was working with a mid-sized manufacturer in Nantes. The company produced custom seating for commercial vehicles: moderate volumes, many configurations and everything made to order.
It used standard cost accounting. Overhead was divided across the units produced. Efficiency was measured by machine use, and supervisors received bonuses for keeping their stations busy.
There was one problem: the system treated every production hour as equally valuable.
At the centre of the line was a welding station. It was always the slowest step. The queue in front of it never disappeared. Stations before welding kept producing, while stations after it regularly waited for work.
When I compared the cost reports with the actual production flow, the cause became clear.
Upstream stations worked at full speed to maintain their efficiency scores.
This created more unfinished products waiting for welding.
Downstream stations sometimes had nothing to do and were reported as underused.
That worried the supervisors, so they pushed upstream to produce even more.
The queue grew. Total output did not.
The cost system valued an hour at welding in the same way as an hour at every other station. In reality, those hours had very different values.
Welding was the bottleneck. An hour lost there meant an hour of output that the entire company could never recover.
An idle hour at a downstream station had little real cost. That station was already waiting for welding. Keeping it busy would not increase sales. It would only move work earlier than needed and create another queue.
The accounting system could not see this difference. It saw machine-use percentages and allocated overhead. It did not see that only time at the bottleneck had a direct effect on total output.
We changed the schedule to protect welding.
Upstream production was deliberately slowed.
This was difficult for supervisors whose bonuses depended on machine use.
Downstream stations were allowed to wait. Welding received priority for maintenance and materials, and the most experienced operators were assigned to it on every shift.
Within six weeks, total output increased by eleven percent.
No new equipment was purchased. Nothing was added to the production line.
After two months, the operations director told me that the idle downstream machines still bothered him.
I explained that they were not idle because the system had failed. They were idle because welding controlled the pace.
Running them unnecessarily would only create more unfinished work and tie up more cash.
He understood the logic.
It still felt wrong.
That instinct—to keep every machine running—is why this way of thinking is so difficult to change. A running machine looks productive. The activity appears on reports, and efficiency figures improve.
But activity is not the same as progress.
The real question is not whether a station is busy. It is whether the decision increases throughput, reduces inventory or lowers operating expense.
If it does none of those things, keeping the machine running is not productive. It is simply expensive movement.
Sales priority
The commercial director knew which product the sales team should push.
Product A generated forty euros of throughput per unit.
Product B generated twenty euros and Product C twenty-four.
Sales targets, distributor incentives and trade-show stands all focused on Product A.
I met him during a factory visit arranged by the Polish subsidiary. The company had faced the same problem for two years: demand was strong, but output would not increase.
I spent the morning on the production floor.
At the centre of the process was a heat-treatment station. Every product had to pass through it, and increasing its capacity would require a major investment.
It was the bottleneck.
Product A needed ten minutes at this station. Product B needed two minutes. Product C needed four.
When I combined those times with the financial figures, the ranking changed completely.
- Product A: €4 per bottleneck-minute
- Product B: €10 per bottleneck-minute
- Product C: €6 per bottleneck-minute
Product A had the highest return per unit but used the most scarce production time.
Product B, seen as the weakest product, generated the most money from each minute at the bottleneck.
The company had been pushing the wrong product.
Margin per unit is useful when capacity is available. In that situation, selling more of the highest-margin product makes sense.
The logic changes when the bottleneck is full.
Every minute spent producing one product is a minute that cannot be used for another.
The real choice is no longer between products with different margins.
It is between different ways of turning limited bottleneck time into money.
The commercial director studied the numbers.
“So we have been improving the wrong thing for two years?”
“Yes.”
The sales team had done exactly what management asked. The problem was that its targets did not reflect the company’s production constraint.
We changed the product-mix targets. Product B received priority in markets where bottleneck capacity was limited.
Product A remained available, but the sales team focused on it only when volumes were low enough not to block more valuable production.
Within one quarter, weekly throughput increased by more than thirty percent.
No new machines. No additional employees.
Later, the commercial director made an observation that stayed with me.
“The margin was correct,” he said. “It told us the truth about each product separately. It just did not tell us what the product did to the whole system.”
That was exactly the problem.
A number can be accurate and still lead to the wrong decision. What matters is whether it answers the question the business actually faces.
The map
The consultant had worked with the company for four months before I arrived.
His report was eighty pages long. It covered every department, process and handover and identified thirty-two opportunities for improvement.
The analysis was thorough.
But the company was still missing delivery dates, and he could not explain why.
I spent the morning asking a different question.
Not, “What is inefficient?”
But, “What shape does this operation have?”
The company made industrial ventilation systems from shared modules: motors, housings, control units and filter frames. These could be combined into hundreds of final configurations.
Many products used the same components. One motor appeared in forty percent of all products. One control board appeared in sixty percent.
This made it a T-plant: a process in which shared components branch into many different finished products.
The main risk in a T-plant is not the speed of an individual station. It is how shared components are allocated.
A control board used for one order is no longer available for another.
If planning does not consider demand across all open orders, several orders can appear to have the same component available.
The conflict is discovered only when assembly starts. By then, one order receives the component and another misses its delivery date.
The consultant’s thirty-two improvement opportunities were real. But most had little to do with this problem.
They focused on local efficiency, while the real failure came from the structure of the operation.
Making stations faster would not solve it.
The company needed to track shared components across all open orders and decide in advance where they would be used.
Different process structures fail in different ways:
- A V-plant turns one main input into many products. Problems occur when the wrong product mix is chosen.
- An A-plant brings many components together into one product. Problems occur when the components are not ready at the same time.
- An I-plant follows a mainly straight production line. Its output is limited by the slowest step.
- A T-plant uses shared components in many final products. It fails when several orders need the same component.
The consultant’s report had not identified the plant type. Without that structure, it was a list of possible improvements—not a diagnosis of the delivery problem.
We redesigned the planning process around shared-component availability.
Every open order was linked to its component requirements. Conflicts became visible earlier.
Managers made allocation decisions before assembly instead of discovering shortages on the production floor.
Within six weeks, delivery performance improved.
Nothing in production had changed.
The shape of a process determines where its problems are likely to appear. If you do not understand that shape, you can analyse the wrong problems with great precision.
Three numbers
The managing director had inherited the reporting system when he took over.
It had grown over twelve years under three different controllers. Each had added new reports without removing the old ones.
The weekly pack was now twenty-two pages. The monthly report had sixty-four.
He read the summary page and ignored the rest.
So did his management team.
He knew the system was not working but did not know how to change it.
We met at a conference in Porto. He described the situation calmly, with the acceptance of someone who had stopped expecting a solution.
I asked him one question.
“During the last six months, how many of those sixty-four pages directly influenced a decision?”
He thought for a moment.
“Maybe four or five. The same ones each month.”
That was the useful number.
Four or five pages—perhaps eight to ten metrics—contained the information the management team actually needed. The other pages were accurate, neatly presented and rarely used.
The data was not the problem. The reporting system had simply started with the wrong question.
Most reporting systems begin with: “What can we measure?”
Soon, everything that can be measured appears in a report.
In theory, the result is complete. In practice, management attention is limited.
When every number receives equal attention, the important numbers disappear among the rest.
The information is available, but finding it takes time. Under pressure, most managers stop looking.
We took a different approach. We started with the bottleneck—the factor currently limiting the company’s output.
Then we asked:
“Which numbers would warn us that this bottleneck is coming under pressure?”
The answer is usually a small set. Three numbers, perhaps five. These are the decisive variables. Everything else provides background.
We spent half a day with his team identifying the company’s bottleneck. It was the custom-engineering stage in the project pipeline.
Then we found its early warning signs:
- New order intake
- Number of projects waiting for engineering
- Time needed for technical approval
When these three numbers moved in the wrong direction, delivery problems appeared two to four weeks later. When they remained stable, the rest of the operation usually stayed under control.
The new weekly report fitted on one page. It contained seven numbers: the three decisive variables and four general indicators for the rest of the business.
The sixty-four-page monthly pack became a twelve-page quarterly board review.
Three months later, the managing director called me.
“We are making decisions faster,” he said. “I’m not completely sure why.”
“The information did not change,” I told him. “The noise around it did.”
Good reporting does not show everything that can be measured. It shows the few changes that require a different decision.
The system that knew everything
The IT director was proud of the system, and with good reason.
It connected nine internal applications and three external data feeds.
It stored four years of transactions and could search almost any combination of fields within thirty seconds.
It had taken three years to build and cost much more than planned.
Across the table sat the operations director. Every Monday morning, he needed an answer to one simple question:
“Are we on track to reach this month’s shipment target? If not, where is the gap?”
The system could not give him a clear answer.
I had been asked to redesign the management information environment. After one day, the problem was clear.
The system had been built by starting with the available data. Every source was connected. Every possible field was collected. The result was technically impressive and extremely complete.
But complete is not the same as useful.
Managers did not lack information. They had too much of it.
Finding the few numbers needed for one decision required technical skills they did not have and time they could not spare.
“The information is all there,” the IT director said.
He was right.
“But it takes me thirty minutes to answer one basic question,” said the operations director.
He was also right.
When both statements are true, the system has failed—regardless of its technical quality.
The correct approach starts at the other end.
First, define the manager’s question. Then identify the decision behind it. In this case: do we need to accelerate part of the operation or move resources?
Next, define the minimum information needed to make that decision with confidence. Only then do you select the data fields required to produce it.
Every field shown in a management system should connect to a question and a decision. If nobody can explain which question a field answers, it does not yet belong in the management view.
“Yet” is important.
Data without a current purpose may become useful later. It does not need to be deleted. It simply should not appear in management reporting until its purpose is clear.
We rebuilt the Monday-morning view from scratch.
Four weeks later, the operations director had one screen containing eleven fields. The data was updated automatically before five o’clock every Monday morning.
He could now answer his shipment question in under a minute.
Those eleven fields came from only three existing source tables. The necessary data had been available all along. It was simply buried beneath everything else the system had collected.
The IT director asked whether the remaining data had been wasted.
“No,” I said. “It is still available when someone needs it. The mistake was believing that available data is automatically useful information.”
A system built backward from a question gives every field a purpose.
A system built forward from all available data creates a swamp: the answers may be there, but nobody can find them.
The question comes first. Everything else follows.
Problem chain
The management team had three problems. For two years, they had discussed them separately.
- The first was falling margin. Prices had been under pressure for eighteen months. To protect sales volume, the company offered discounts, which reduced margins even further.
- The second was stagnant sales. Revenue had stopped growing even though the market continued to expand. The commercial director blamed the product range and the marketing budget.
- The third was customer complaints about delivery times. Lead times had increased. Operations tried overtime and priority scheduling, but neither made much difference.
Three problems. Three projects. Three sets of meetings.
I was asked to spend a week with the company and give my assessment. Before discussing solutions, I asked to map how the problems were connected.
The exercise took a day and a half.
We started with the delivery complaints.
Long lead times were causing customers to demand discounts as compensation for waiting. They were also pushing customers towards faster competitors.
The margin problem and the sales problem had the same cause: late delivery.
So why were deliveries late?
Orders were waiting at one specific step: technical validation. Its capacity had not increased as order volumes grew. The resulting queue added eight to fourteen days to almost every order.
Why was the queue not being managed?
Technical validation had never been identified as the company’s bottleneck.
It was managed like any other department, with normal targets and priorities.
Whenever it fell behind, managers pushed urgent orders to the front. Each priority order disrupted the existing schedule. One customer received faster service, while everyone else waited longer.
The average delivery time became worse.
At the bottom of the problem chain was one root cause: the company was managing its bottleneck reactively instead of treating it as the step that controlled the performance of the whole operation.
The three management problems were actually one problem appearing in three places.
Margins were falling because of delivery delays. Sales had stopped growing because of delivery delays. The delays existed because technical validation was not being managed as the bottleneck.
When I showed the map to the CEO, he was silent for a moment.
“We have been treating the symptoms,” he said.
That was exactly right.
A problem chain does not provide the solution. It shows where to look.
Once the cause-and-effect structure becomes visible, the task becomes simpler.
Instead of working on three separate symptoms, the company can address the one cause creating all three.
Over the next six weeks, the company increased and reorganised capacity in technical validation.
Lead times returned to normal within three months. Customer pressure for discounts fell during the next two quarters. Sales began to recover as delivery performance improved.
The three problems did not need three solutions.
They needed one solution, applied in the right place.
The conflict
The sales director and finance director had not agreed on a pricing decision in three years.
The CEO warned me before I entered the room. His tone suggested he had stopped trying to solve the conflict and had learned to work around it.
The company produced specialist coatings for industrial customers. Sales wanted to lower the price of one product line to win volume from a new competitor. Finance wanted to hold the price to protect margins on a product with high development costs and few alternatives.
Both positions made sense. Both had supporting figures.
The discussion about this one product had already continued for eighteen months.
I asked both directors the same question:
“What would need to be untrue for the other person’s position to be correct?”
This is often the most useful question in a conflict.
Most business conflicts do not continue because one person is irrational. They continue because both sides depend on assumptions that appear so obvious that nobody checks them.
For sales, the main assumption was:
“We can win more orders only by lowering our price.”
The new competitor had grown quickly and charged less. Sales had connected those two facts without investigating further.
Finance had a different assumption:
“The product’s margin depends on its current price, so any price reduction will directly reduce profit.”
We spent two hours examining the evidence behind both positions.
The competitor had won four important accounts. In three cases, delivery time—not price—had influenced the customer’s decision.
One purchasing manager had been very clear. The competitor promised delivery within three weeks. The company was quoting six to eight weeks.
This information had appeared in a sales report but nobody had acted on it.
The disagreement between lowering and maintaining the price was genuine. But both options responded to the wrong diagnosis.
There was little evidence that price was the main reason customers were leaving.
Once we challenged that assumption, the conflict changed. The question was no longer:
“Should we lower the price or keep it?”
It became:
“What is really driving the customer’s decision, and what can we improve?”
The answer was delivery time. That was an operational problem the company could solve without damaging its price position.
Two capable directors had spent eighteen months arguing about what to do because they had never first agreed on what was true.
The proposed fix was not a compromise. They did not need to meet halfway on price.
They needed to recognise that both positions were based on a problem that did not exist in the way they had assumed.
Neither director looked comfortable with that conclusion.
Discovering that you misunderstood the problem rarely feels good.
But it is much cheaper than implementing the wrong solution perfectly.
The solution that needed lunch
We had been in the meeting room since eight. By half past twelve, the whiteboard was full of logic chains, the coffee was gone and nobody had eaten.
The operations director suggested lunch. The CEO, who had pushed hard to finish the meeting, agreed surprisingly quickly.
We walked ten minutes to a small restaurant near the river. It was quiet, simple and served food without ceremony. We ordered quickly.
The next two hours became the most useful part of the engagement.
The company had designed a solution to its delivery problem. It was a good one: a new scheduling method that would give priority to the constrained finishing station, reduce the queue and cut lead times by thirty to forty percent.
The logic was sound. Everyone agreed.
We were about to start implementation planning when I asked one question:
“What happens to the customers currently at the front of the queue when we change the priority system?”
Nobody had considered it.
Over lunch, we worked through the Future Reality: a way to test the complete chain of consequences before implementing a solution.
You begin with the proposed fix. Then you write down each expected result as an if-then connection:
If we make this change, then what happens next?
Each link must be tested. Does one result really lead to the next? Eventually, the chain should reach the intended outcome—in this case, shorter and more reliable delivery times.
Then comes the side-effect check.
You take the same solution and ask what else it could cause. Not the results you want, but the results that will happen anyway.
We worked through the chain on paper napkins while eating lunch and drinking coffee that was much better than the coffee in the meeting room.
A problem soon became clear.
Some customers had placed orders under the old system and received firm delivery promises. The new priority rules would move their orders backwards in the queue.
Those customers would wait longer, not less.
The solution designed to improve delivery would first make it worse for a specific group.
That was not a reason to abandon the plan. It meant the plan needed a safeguard—a trim.
Existing orders would remain under the old delivery commitments. The new scheduling rules would apply only to orders received after a fixed transition date.
This required three weeks of manual planning and direct communication with the affected customers. It was simple to arrange.
Without the side-effect check, the company would have discovered the problem only when complaints arrived.
After lunch, we returned to the meeting room and completed the implementation plan in ninety minutes. We added the trim and checked the full chain again.
It held.
As we finished, the CEO said lunch had probably saved them two months of correcting mistakes.
“Lunch mostly stopped us from skipping a step,” I said.
Test the solution on paper before putting it into practice. Follow the full chain. Check the side effects. Add the necessary safeguards.
Then act.
The food helps too.
The roadmap on a paper tablecloth
The owner ordered fish. I ordered soup.
We were sitting in a restaurant in the old town. It was the kind of place that covered its tablecloths with paper and left pencils in a jar for customers.
He had brought his own pencil, which I took as a sign of experience.
Fourteen months earlier, at thirty-four, he had taken over the family business after his father suffered a stroke.
It was a small manufacturer with forty-two employees and a customer base that had been stable for ten years. But three problems had appeared at roughly the same time.
Cash was tight. Management information was unreliable. And the loyal, experienced team was struggling to adapt to his changes.
He had tried to solve all three at once and made little progress with any of them.
I asked him to write his goal at the bottom of the paper tablecloth.
He wrote:
“Turnaround completed. Company stable by the end of next year.”
Then I asked what stood between the current situation and that goal.
He wrote three obstacles:
- Cash flow under pressure
- No reliable information for decisions
- Resistance to new working methods
This became his Obstacle Roadmap.
The method is simple. First, define the goal. Then identify the obstacles blocking it.
For each obstacle, define the minimum condition needed to overcome it. Not a large project or programme—just the result that must exist before you can move forward.
Then place the obstacles in the correct order.
In his case, cash had to come first. Without stable cash flow, he could not invest in better reporting or give management enough time to work with the team.
The first intermediate objective was clear: create and execute a ninety-day cash plan, reviewed every week.
Once cash was stable, the company could improve its reporting.
The second objective was a practical management dashboard: seven numbers, updated weekly, showing the information needed for his main decisions. That would take about four weeks.
Reliable figures would then make the third obstacle easier to address.
People do not always resist change itself. Often, they resist the uncertainty around it. Clear numbers make the situation and direction easier to understand.
The third objective was to introduce three new operating routines and follow them without exception for sixty consecutive days.
As we talked, he drew the chain across the paper tablecloth:
Current situation. Obstacle. Objective. Obstacle. Objective. Obstacle. Objective. Goal.
Then he stopped and studied it.
His herring had arrived and was getting cold.
“This is what I have been trying to do,” he said. “I just didn’t have it in this order.”
That was the real problem.
He already knew the obstacles and the goal. What was missing was the sequence. Each intermediate objective created the conditions needed to tackle the next obstacle.
Trying to work on all three at once was precisely why progress had been slow.
He ate the fish. I ate the soup.
The paper tablecloth stayed behind when we left. The restaurant would throw it away, but by then the roadmap was already in his notebook.
Morning coffee
The turnaround specialist had been in the business for eleven weeks when I met her for coffee.
She had chosen a place near the port — functional, no pretensions, good coffee, the kind of establishment that opens at seven because the people who use it start work before eight.
She was already there when I arrived, with a notebook open and a cup that suggested she had been there for a while.
The board had brought her into a mid-sized Estonian logistics company after two years of falling results.
The diagnosis was complete. The root cause was clear. The board had agreed on the target and the sequence of actions. Every task had an owner and a deadline.
On paper, the turnaround plan was solid.
“The problem,” she said, “is that nothing is moving.”
She turned the notebook towards me.
The plan was well designed. Each step led logically to the next. But four weeks into implementation, the management team remained polite, attentive and almost completely stationary.
“Where are the quick wins?” I asked.
She looked down at the plan.
There were none.
It moved directly from diagnosis to major structural changes: reorganising dispatch, introducing a new scheduling system and renegotiating three supplier contracts.
All three were necessary. All three would take three or four months to produce results.
That created a problem.
The people being asked to change had to believe the work was worthwhile. Belief needs evidence, and in a turnaround, that evidence usually comes from early results.
That is why an action sequence needs quick wins: small, visible improvements that appear before the larger work is complete. They show the team that this time, something is genuinely changing.
Without quick wins, the plan depends on authority. Employees cooperate because the board tells them to, not because they believe in the direction.
They have probably seen earlier restructuring plans—with deadlines, notebooks and outside specialists—that produced little lasting change.
Over a second cup of coffee, we identified four improvements that could be completed within two weeks without changing the main plan.
One was a scheduling adjustment that would reduce handover delays on the busiest route.
Another would give depot managers earlier information about the following day’s loads.
Neither required new software, investment or restructuring. Both could produce visible, measurable results.
The quick wins would run alongside the structural work. Their purpose was not to solve the entire problem. Their purpose was to provide evidence that the new direction worked.
That evidence would build confidence. Confidence would create the support needed for the harder changes ahead.
She added two lines to the notebook, wrote an owner beside each and closed it.
“I built the right plan,” she said. “I just forgot what the plan was for.”
A plan is not the destination.
It must create the conditions that make the destination reachable. Some steps improve the system. Others convince the people inside it that the improvement is real.
The offer nobody refused
He had been cutting prices for three years.
Each reduction worked for about six months. Sales increased, the team relaxed, and then a competitor matched the new price. The cycle started again.
By the time I met him, his margin was half what it had been. He was considering another cut.
We had lunch near the market square. Proper Polish food, served without hurry—the kind of meal that takes ninety minutes without anyone noticing.
He explained the problem clearly. The product was good. The service was reliable. Customers were satisfied.
“They simply won’t pay more than the cheapest alternative,” he said.
I asked a different question.
“What causes your customers real pain? Not what do they buy from you, but what keeps them awake at night where your product is used?”
He thought for a while.
His customers were production managers at mid-sized manufacturers. Their biggest concern was unplanned downtime: equipment stopped, and replacement components were not immediately available.
His product was one of those components.
Emergency delivery in the industry normally took five to seven days. Customers kept safety stock to protect themselves.
That used cash and warehouse space, yet they still faced three or four downtime incidents each year.
He sold components.
His customers needed uptime.
Those are different things and only one is worth paying extra for.
Over coffee, we sketched a new offer on a paper napkin.
Not a lower price.
Instead: guaranteed delivery within four hours for emergency orders inside a defined area. A regional stock agreement would support the service, and customers would pay a fixed annual fee.
The fee was roughly equal to the cost of one downtime incident—a figure customers knew because they already measured it.
The offer addressed the real pain. The problem was not the price of the component. It was the cost of waiting for it.
The first customer signed within a week. It was his fastest sale in four years.
The second asked whether he could extend the delivery area. The third wanted to include another product category.
None tried to negotiate the price.
The offer was based on the value of the problem it solved, not the cost of the component it delivered.
Price competition always follows the same path. You cut the price. A competitor follows. Margins fall until the market reaches a level that works well for the customer and badly for every supplier.
The way out is not a better discount.
It is an offer built so precisely around a real problem that the customer’s alternative is to continue suffering that problem.
An offer becomes difficult to refuse because it fits the need—not because it is cheap.
A lasting advantage does not come from having the lowest number on the quotation. It comes from understanding the customer’s situation better than a new competitor can.
The soup was very good too.
The buffer
The gate had changed twice in forty minutes.
I had followed the departure board from C to D and was now somewhere near E.
A Lufthansa flight was leaving the next stand while my connecting flight waited on the tarmac for a slot.
Around me, six passengers were making the same calculation: forty-five minutes until departure, and our incoming aircraft was still taxiing.
The man beside me was a project manager for a construction company in Utrecht. He looked like someone who spent a great deal of time in airports and had learned to accept it.
We started talking because the alternative was staring at a departure board that refused to update.
He asked what I did. After I explained, he said he had been trying to solve the same project-delivery problem for two years.
“Every project is late,” he said.
Not seriously late—usually two to four weeks. His teams were capable, plans were detailed and most individual tasks finished close to schedule.
Yet the complete project always arrived late.
I recognised the pattern.
It is common in engineering and construction projects. Individual task estimates contain hidden safety time, while the plan does not properly account for shared people and resources.
Suppose the owner of Task 3 expects four weeks but promises six to be safe. The owners of Tasks 4 and 5 do the same. The schedule now contains eighteen weeks of padded estimates.
If one task finishes early, the saved time usually disappears. The next person may be busy elsewhere, or nobody planned for an early start.
But when a task finishes late, the delay moves directly into the next task.
The plan contains safety time everywhere, but that safety is rarely available where it is actually needed.
Resource-Aware Project Planning handles this differently.
Task estimates are reduced to roughly half of their padded duration: challenging, but achievable. The removed safety time is then combined into two controlled buffers.
The project buffer sits at the end of the critical path and protects the final delivery date.
Feeding buffers sit where parallel work enters the critical path. They prevent delays in supporting activities from disrupting the project’s most important sequence.
These buffers are actively managed.
If a critical task uses too much of the available buffer, it receives immediate attention—extra resources, faster decisions or management support.
The main signal is not whether every aggressive task date is achieved. Some will be missed.
The signal is how much buffer remains.
Outside, three aircraft took off while we talked. Each waited for its slot, used the runway and moved on.
The airport worked because the runway was managed as one shared resource. Individual aircraft did not each add their own safety margin and reserve part of it.
My flight called final boarding.
We shook hands. He said he would review the buffer levels in his current project that evening.
“Start with the feeding buffers,” I said. “That is usually where the surprises are.”
The flight departed nine minutes late and arrived four minutes early.
The project buffer had absorbed the delay.
The playground
The park lay between her office and the coffee place where we had agreed to meet, so we walked through it.
It was a warm Tuesday afternoon in late September. The playground was busy: children on the climbing frame, a queue for the slide and two small boys arguing over a bucket.
She stopped to watch them for a moment.
She managed projects for a mid-sized engineering company.
We had met at an industry event the evening before. Over coffee, she wanted to discuss a question that had bothered her for some time:
why did her detailed, professionally prepared plans always underestimate the project duration?
I asked her to describe a recent example.
It was a product-validation project with four main tasks:
Design. Review. Build. Test.
The plan showed sixteen days. The project took twenty-two.
The individual tasks had finished roughly on schedule. The extra six days had appeared somewhere between them.
“Who performed the review?” I asked.
“Engineer X, our senior validation engineer.”
“And who performed the testing?”
“Also Engineer X.”
There was the missing time.
The Critical Path Method, used by her planning software, calculated duration from task dependencies. It knew which tasks had to finish before others could begin.
It did not consider who performed them.
On the screen, review and testing were separated by the build phase. The software saw a clean sequence and calculated sixteen days.
But Engineer X was involved in other work while the team completed the build. Testing could not begin until he became available again.
That wait did not appear in the plan because the software did not recognise Engineer X as a shared resource.
Six days were invisible on the Gantt chart but very real in the final delivery date.
Resource-Aware Scheduling asks a broader question than Critical Path:
Not only, “What is the longest sequence of dependent tasks?”
But also, “What is the longest sequence when we include the people and machines required to perform those tasks?”
That sequence is usually longer. The difference is the hidden delay that project managers later have to explain.
As we left the coffee place and passed the playground again, one boy had solved the bucket dispute by sitting on it. The other had moved to the slide, where the queue had disappeared.
I pointed towards it.
“If five children need the same slide, the time they spend in the playground does not determine the flow. The shared slide does. The slide is Engineer X. The queue is testing waiting for him to become available.”
She watched the playground for a moment.
“My planning tool has no field for ‘same person as the review task.’”
“That is exactly the problem.”
Her software modelled tasks and dependencies. It did not model people and their limited availability.
The plan said sixteen days because it could not see the waiting time.
The project took twenty-two because the waiting time was real.
The solution is not a better Gantt chart. It is a planning method that includes resources—not only tasks—when calculating when the project can actually finish.
The 06:47 to Brussels
The departure board at Amsterdam Centraal shows times in five-minute intervals. If you are not on the platform before the doors close, the train leaves without you.
Everyone who regularly travels from Amsterdam knows this.
Most still cut it close.
I had arranged to meet a project manager on the train. He was leading a software rollout for a logistics company. The go-live date was fixed, but the plan appeared safe. Every stage contained extra time.
He reached the platform with forty seconds to spare.
We got on.
“How is the project going?” I asked.
“Fine,” he said. “Every task has a generous estimate. We have buffers everywhere.”
“When did a task last finish early?”
He thought for a moment.
He could not name one.
- Two things happen to time buffers in projects so often that they have names.
The first is Student Syndrome.
Give someone three weeks for a task that should take two, and they rarely start on the first day. They wait until the deadline feels close, often near the end of the first week.
Part of the buffer disappears before the work begins. - The second is Parkinson’s Law: work expands to fill the available time.
If a two-week task is given three weeks, it rarely finishes after two. More details are added. The work is checked again, discussed again and improved further.
It finishes after three weeks.
Between these two behaviours, the buffer disappears without anything going wrong. People delay the start and then allow the work to fill the remaining time.
When a real problem finally appears—an integration fails, an approval is late or a dependency is missing—there is no protection left.
Outside, the train passed the backs of warehouses and then the open polders.
It was running on time.
“So the buffer doesn’t help?” he asked.
“Not in its current form.”
Extra time attached to individual tasks is easily consumed. A shared project buffer works differently. It sits at the end of the critical sequence, remains visible and is managed by the project as a whole.
When that buffer starts shrinking, the project manager receives an early warning while there is still time to act.
He looked at the screen inside the carriage.
Amsterdam Centraal to Brussels: two hours and four minutes.
“We both knew the departure time yesterday,” I said. “And we still nearly missed the train.”
He nodded.
Having extra time is not the same as using it to arrive on time. Knowing the deadline and starting at the right moment are two different things.
The train crossed the border on schedule.
The project, I suspected, would not.
The lunchroom
The company canteen was on the second floor, overlooking the car park.
It looked as if nothing had changed since the building opened: long tables, plastic chairs and a serving hatch where a woman handed out soup and sandwiches between twelve and half past twelve.
When I arrived, the programme manager was already sitting near the window with his tray.
He managed large technology projects for a manufacturing company and had been doing it for fifteen years.
His projects regularly finished late.
“How do you build the schedule?” I asked.
“Every task gets a realistic estimate. We add safety time where necessary, then build the schedule from those estimates.”
“What happens to the safety time?”
He took a bite of his sandwich and thought.
“It disappears somehow. Most tasks finish close to their deadlines, but when something goes wrong near the end, there is never any margin left.”
The problem was built into the planning method.
When safety time is hidden inside individual tasks, three things happen.
First, people delay starting until the deadline feels close: Student Syndrome.
Then the work expands to fill the available time: Parkinson’s Law.
Finally, any delay moves immediately into the next task. But an early finish rarely does. People do not always report that they are ready early, and the next resource may not be available anyway.
Bad news moves forward at once, good news often goes nowhere.
Resource-Aware Scheduling handles safety time differently. It removes the hidden margins from individual tasks and combines them into visible buffers placed where the project needs protection.
There are three types.
- The project buffer sits at the end of the Resource-Aware Scheduling. It absorbs delays from the main task sequence and protects the final deadline.
- A feeding buffer sits where a supporting sequence joins the Resource-Aware Schedule. It prevents delays in side activities from disrupting the main flow.
- A resource buffer is not extra time. It is an advance warning. It tells the next key person or team to be ready before the previous task finishes, avoiding a gap between the two.
The difference is visibility.
Safety hidden inside individual tasks disappears into daily behaviour. A shared buffer can be measured. The project manager can see how quickly it is being used and respond before the delivery date is in danger.
He had finished his sandwich and was looking through the window at the car park.
“So the safety margin still exists,” he said. “It has just moved.”
“Moved and made visible. Inside a task, you cannot see it disappearing. In a buffer, you can watch it being used.”
He picked up his coffee. The serving hatch had closed, and the canteen was emptying.
“We have always put the margin inside each task because that is how the schedule works.”
“That is how the software expects you to build it,” I said. “The software does not know the margin will disappear before you need it.”
“You do.”
The first-year classroom
The school was three streets from the station.
She had asked to meet there instead of at her office because she needed to collect her son at half past three.
We sat on a low wall outside while the final lesson continued. Through a window, we could see six-year-old children working with crayons.
She managed project delivery for a mid-sized IT consultancy.
The company had a project method. That was not the problem.
Projects still finished late, everyone was always busy and the busyness seemed to make matters worse.
“That is not one problem,” I said. “It is three.”
- The first was execution discipline, which Resource-Aware Scheduling calls handoff discipline.
Think of a relay race. The runner carries the baton as fast as possible and passes it on immediately. They do not wait for a meeting. They do not return to improve the previous lap.
They finish and hand over.
In many projects, completed work sits waiting—for approval, a scheduled meeting or the next person to find time.
The task itself may finish on schedule, but the safety time disappears in the gap after it. - The second problem was multitasking.
A team working on six tasks at once is not six times more productive. Every switch requires people to stop, remember where they were and start again.
Each task takes longer, and little gets finished.
Resource-Aware Scheduling requires people working on critical tasks to focus on one task from start to finish. This can feel uncomfortable because the other five tasks appear to be waiting.
But being busy is not the goal.
Finishing work is. - The third problem was buffer management.
Resource-Aware Scheduling places a shared buffer at the end of the project. Many project managers ignore it until the deadline is close, when it is already too late.
Instead, the shared buffer use must be tracked throughout the project using a fever chart.
The chart compares how much of the project is complete with how much buffer has been used:
- Green: continue as planned
- Yellow: watch closely and prepare
- Red: act now
It provides a warning early enough to prevent a delay—not merely enough time to explain one.
Inside the classroom, the teacher was collecting the children’s drawings and holding them up one by one.
“So the fever chart is just a status indicator?” she asked.
“Not quite. A deadline tells you that you are late. A fever chart tells you that you are likely to be late while you can still prevent it.”
A child knocked a box of crayons onto the floor. The teacher helped collect him and continued without stopping the lesson. The rest of the class kept working.
She had noticed it too.
“Small disruption. No stop.”
“That is a managed buffer. The disruption is real, but the system absorbs it. You intervene only when the signal tells you to.”
Her son appeared at the classroom window, looking for her.
She stood and waved.
The kitchen
He had suggested a brasserie near the Presqu’île.
We arrived before the lunch rush and were seated beside the pass — the opening between the dining room and the kitchen.
Through it, we watched the chef organise the preparation. One station finished a sauce. Another arranged plates. A third stood waiting for something to arrive.
The kitchen had a rhythm. Whenever that rhythm broke, work began to pile up.
He managed the project office of an engineering company with forty active projects. Staffing had not increased for three years.
Every project had a planned start date.
Almost none finished on time.
“How do you decide when to start a new project?” I asked.
“The client signs, procurement releases the budget and we start.”
“What happens when three clients sign in the same month?”
“Three projects start.”
There was the problem.
In a multi-project organisation, successful delivery depends on more than how each project is managed. All projects compete for the same limited resources.
One of those resources is usually the bottleneck for the entire portfolio. It could be a senior engineer, testing environment, regulatory reviewer or specialist supplier.
Whatever it is, that resource controls how quickly projects can move through the company.
When several projects start together, they often reach the bottleneck at roughly the same time.
The bottleneck becomes overloaded. It switches between projects, losing time with every change. All projects slow down together.
Projects that were possible individually become impossible when run at the same time.
The solution has three parts.
- First, identify the shared bottleneck across the full project portfolio—not only within each project.
- Second, time new project starts according to the bottleneck’s available capacity. A project should not start simply because the contract has been signed. It should start when the bottleneck can handle the work.
- Third, protect that resource from being pulled between too many projects.
The bottleneck’s capacity determines the company’s project output. Overloading it does not increase delivery. It reduces it.
Behind the pass, a tray arrived at the waiting station.
The chef called an instruction. Two stations worked together briefly and then returned to their own tasks.
The rhythm was deliberate. Nothing started before the right moment.
He watched them.
“We have no way to delay a project start,” he said. “Once the client signs, the pressure to begin is immediate.”
“That pressure is real. But starting everything overloads the bottleneck. All three new projects slow down, and the older projects are delayed as well.”
He looked at the menu.
The kitchen was now fully active. Every station was working, but nothing was piling up at the pass.
“The real question is not whether you delay a project,” I said. “It is whether you delay the start or the finish.”
“One of them will be delayed.”
“At the moment, you always delay the finish—without ever deciding to.”
ERP in Gdańsk
She called me fourteen months after the system went live.
The project had been delivered more or less on time.
Nothing had improved.
We met in a fourth-floor conference room at the company’s headquarters. A stack of reports from the new system lay on the table.
They looked different from the old reports but contained much the same information and led to the same decisions.
Outside, shipyard cranes stood motionless in the grey November morning.
She was the operations director. The ERP system had cost four million euros and taken two years to implement.
The board had expected improvements in throughput, inventory turnover and on-time delivery.
None of those numbers had changed.
“What decision rules changed when the system went live?” I asked.
She looked at the reports.
“None. We receive better information faster, but we still make the same decisions.”
That was the heart of the problem.
An ERP system is often necessary for improvement.
Without accurate, current information, a large manufacturing or distribution company cannot make good decisions consistently.
But necessary does not mean sufficient.
Technology creates the ability to improve. It does not produce the improvement itself.
Results change only when the company uses the new capability to make different decisions.
That may mean planning around throughput instead of local cost.
Replenishing stock based on actual consumption instead of forecasts.
Or changing purchasing rules so buyers protect flow instead of chasing the lowest unit price.
The system may be needed to support these methods. But it will not introduce them by itself.
Someone must challenge the old rules, define better ones and make sure people apply them.
Most ERP projects stop before that point.
They migrate the data, configure the software and automate the existing processes.
A poor process, once automated, simply runs faster and more consistently. The outcome stays the same while the cost increases.
She picked up a purchasing report.
The system showed low stock for forty-seven items. The buyer had responded by ordering the standard economic quantity for all forty-seven.
“That was the rule before the ERP,” she said. “It is still the rule.”
“But the system can now show which items are needed for active customer orders and which are not. Those situations require different decisions. The technology can show the difference, but someone must tell the buyer to act differently.”
She put the report down.
“The implementation team handled migration, configuration and user training. Nobody was responsible for changing how people made decisions.”
“That is the gap between necessary and sufficient,” I said. “The system provides the capability. The new rules create the improvement.”
“You have the capability; you are still missing the improvement.”
Outside, one of the cranes began to move.
Printing press
The machine dominated the room.
A Heidelberg Speedmaster XL 106, installed six months earlier, occupied most of the production floor at a commercial printer in West Flanders.
It could produce twenty-one thousand sheets per hour. The old press had managed eleven thousand.
The owner had invested two and a half million euros and expected output to double.
Instead, it had increased by about twelve percent.
He contacted me through a referral.
We walked across the production floor while the press printed a furniture catalogue — full colour, edge to edge, with precise registration.
The machine ran with a smooth, controlled rhythm.
It was excellent.
It was also not the problem.
“What changed in the operation when the new press arrived?” I asked.
“We removed the old press, hired a second operator and changed the maintenance schedule.”
“What about planning? How do you decide which jobs run and in what order?”
“The same way as before. Sales accepts the order, estimating promises a delivery date and production schedules by arrival time, except for urgent jobs.”
The old press needed forty-five minutes between jobs for plate changes and colour adjustment. The Heidelberg needed eighteen.
“That saves twenty-seven minutes per changeover. What happens to that time?”
He paused.
“The operators start the next job when it is ready. Sometimes they have to wait.”
Any major technology investment should pass three tests.
- First: which bottleneck will it remove?
Here, the answer was press speed and changeover time. - Second: was that really the company’s bottleneck?
It was. The company regularly lost orders because it could not meet the required delivery dates. - Third: have the operating rules built around the old bottleneck been changed?
That was where the investment had failed.
With the old press, estimating quoted five days because that was the time production needed.
Planners combined jobs into long runs because each changeover cost forty-five minutes.
Sales avoided short jobs because they were too expensive to produce.
Every rule made sense for the old machine; none had changed after the new one arrived.
The Heidelberg could complete some jobs within two days. Estimating still promised five.
It could change economically between jobs in eighteen minutes. Planning still created large batches to avoid changeovers.
Short, urgent production runs were now profitable. Sales still rejected them.
The twelve-percent improvement came from the machine running faster. Much of the remaining potential was trapped behind rules that no longer matched the production system.
The owner stopped and looked at the press.
“We bought the capability but kept the old assumptions.”
“Exactly. The technology removed the bottleneck, but your rules were designed around that bottleneck. You are running a two-and-a-half-million-euro press inside a system built for the machine you replaced.”
The Heidelberg finished the furniture catalogue and started its eighteen-minute plate change.
On the planning board, the next three orders had been combined into one long production run.
They could have been four separate jobs, delivered to four customers within two days.
The new machine was ready.
The old rules were still in control.
Card game
It was Friday evening, and the meeting had run late.
His office overlooked the Maas. On the table lay the implementation partner’s presentation: eighty-six polished slides with charts showing how much faster reporting would become after go-live.
He was the CFO of a mid-sized distribution company. Its new ERP system had been running for eight months.
While we waited for his car, he took a deck of cards from his desk and began shuffling.
“Old habit,” he said. “I think better when my hands are busy.”
“Did the system deliver what the supplier promised?” I asked.
“Yes. The data arrives faster. Reports that took two days now take two hours. We have better inventory visibility. Everything works.”
“What decisions are the buyers making differently?”
He looked at the cards.
“They still order the same economic quantities. They still monitor turnover per item, unit cost and supplier delivery performance.”
“So the decisions are the same?”
“Yes.”
That was the heart of the problem.
The ERP system was necessary. A distribution company cannot make reliable decisions at scale without accurate, current data.
But necessary does not mean sufficient.
An ERP system digitises the existing process. If that process measures and rewards the wrong things, the system digitises those mistakes—only faster and more consistently.
Department efficiency, staff utilisation and cost per unit are local measures. They show how one part of the company performs, but not what that performance does to the whole operation.
A buyer measured on unit cost will order large volumes to secure a lower price.
The buyer’s figures improve.
But inventory rises, cash becomes trapped in stock and products move more slowly through the company.
The ERP can now tell the buyer every minute how well he is performing against that local target.
That is not improvement.
It is the automation of the error.
He shuffled the cards again.
“We implemented the system without deciding what we wanted to measure differently.”
“Exactly. Measures drive behaviour. If you keep the same measures and only replace the tool that reports them, behaviour will not change.”
He placed the cards on the desk and looked out at the river.
“More data, but the same logic.”
“And therefore the same results.”
The system could not decide whether the company should optimise individual departments or improve flow across the whole business.
Management had to make that choice first. Only then could the ERP be configured to support it.
His car arrived.
He stood and returned the cards to the drawer.
“Eight months after go-live, and we are still measuring exactly what we always measured.”
“That’s right,” I said.
“And so is the system.”
The bar
The bar stood in a side street near the Burg.
It was narrow and dim, with eight tables and a long counter lined with Belgian beer taps. It had been there before the tourists arrived and seemed determined to remain after they left.
The owner kept his stock in a room behind the kitchen. After thirty years, he knew roughly what was there without checking.
I was meeting the logistics director of a consumer-goods distributor. He had chosen the place.
We ordered two Westmalle beers and discussed his inventory problem.
His company supplied forty-three independent retailers across three countries. Each retailer managed its own stock and ordered on its own schedule. Some ordered weekly. Others monthly. A few waited until they ran out.
His central warehouse moved between excess stock and shortages in a pattern he could not predict.
Some retailers complained that products were unavailable. Others held six months of stock.
“Watch the bar,” I said.
Four customers finished their beers. The owner cleared the glasses and returned to the counter.
Within ninety seconds, four new beers appeared on the table without anyone ordering them.
He had not checked a stock report. He had seen what the customers consumed and replaced it.
“That is the model.”
The logistics director looked at me.
His network had a structural problem.
Every retailer carried enough stock for its forecast plus a safety margin.
They ordered based on what they expected to sell rather than what customers had actually bought.
Small changes in demand grew larger as they moved up the supply chain.
A retailer ordered extra to be safe. The distributor saw the higher order and ordered more from the manufacturer. The manufacturer increased production.
Then demand returned to normal, leaving every part of the chain with too much stock.
The problem was not simply poor forecasting. It was having a separate forecast and safety margin at every level.
A better approach is to replenish from actual consumption.
Keep a central buffer large enough to protect the full network. Refill retailers frequently in smaller quantities, based on sales instead of predictions.
When a retailer sells ten units, send ten units.
The central stock absorbs differences across all forty-three locations. One shop may sell more while another sells less. Across the full network, those variations partly balance each other.
Total inventory falls while product availability improves.
At the counter, the owner refilled another customer’s glass without being asked. He had watched the level and moved when it became low.
“He does not forecast thirst,” I said. “He responds to consumption.”
It was a busy Friday evening. The owner was managing twelve tables, the bar and two employees without a clipboard.
Nothing had run out.
“My retailers won’t give me daily sales data,” the logistics director said.
“Some won’t. But those that do can carry less stock and face fewer shortages. When the others see that, they may reconsider.”
He finished his Westmalle; the owner appeared beside us within thirty seconds.
The football club
He had become interim general manager of a football club in Germany’s 3. Liga six weeks earlier.
The club was mid-table, inconsistent and facing what the board called “a complex situation.”
He used the word complex in the way people often do when they have not yet found the cause.
We had met through a mutual contact. On a Tuesday morning, while the first team trained, we found a quiet table at the back of a café near Odeonsplatz.
“Describe the situation,” I said.
He listed the problems.
- Good performances were followed by poor ones without a clear pattern.
- The coaches disagreed about the team’s playing style. The sporting director and head coach spoke with agents separately.
- Different people made decisions about transfers, contracts and playing time using different criteria.
- Players received mixed messages.
- Concerns from the medical team did not always reach the board.
- Morale was low, but nobody could explain why.
It sounded like six separate problems, each needing its own solution.
“I don’t think you have six problems,” I said.
He looked at the list on his phone.
A troubled organisation always appears to have many problems: poor results, low morale, weak decisions, constant firefighting and unhappy customers.
Each symptom creates meetings, action plans and sometimes its own consultant. Management becomes busy dealing with visible problems while the causes underneath remain unchanged.
FlowLogic calls this Hidden Simplicity.
The idea is that apparent complexity often comes from only one or two root causes. Not because organisations are simple, but because cause-and-effect chains connect.
Six symptoms may come from four intermediate causes, which lead back to two roots.
Fix the roots and several symptoms disappear. Treat every symptom separately and the work never ends.
In his club, the two root causes were already visible.
First, the sporting director and head coach had different ideas about what the team was trying to achieve.
Second, there was no single decision framework. Different people decided about players, tactics, contracts and communication, but nobody held responsibility for the whole.
Everything else followed from those two problems.
He studied his phone again.
“I’ve been treating every item as a separate problem.”
“That is natural. Symptoms create the complaints, calls and pressure. They feel like the real problems.”
“But fixing them individually is like replacing players when the tactical system is wrong. You can keep changing the team, but the pattern remains.”
A notification appeared from the training ground. He read it and placed the phone face down.
“One serious conversation between the sporting director and head coach could change most of this,” I said. “They need a written agreement on the playing model, shared goals and who decides what.”
“That single action will solve more than six separate projects.”
He picked up his coffee.
“I came here expecting complexity. You are telling me it’s simple.”
“Simpler than it looks,” I said.
“That does not mean easy.”
Children’s play
The theatre was a converted warehouse on the edge of the old city.
It still carried its industrial past: exposed beams, rough brick walls and rows of folding chairs.
The Saturday afternoon performance was for children aged four to eight. There was a dragon, a queen and a missing crown. The children in the front rows watched without moving.
I was there with the commercial director of a packaging company. Her daughter sat in the fourth row. We were two rows behind her.
She had spent the car journey telling me about a conflict that had continued for eight months.
Sales wanted to offer five-day delivery and flexible order quantities. They were losing business to faster competitors.
Operations insisted on minimum quantities and three-week lead times. Shorter runs, they argued, would disrupt production and increase costs.
Both positions made sense. Both sides refused to move.
An earlier attempt at compromise had produced seven-day delivery for larger orders and standard terms for everything else.
Neither team was satisfied. The customers who valued flexibility most were still choosing competitors.
On stage, the queen and dragon were arguing. The queen wanted her crown. The dragon wanted to keep the cave.
“What assumption is holding your conflict in place?” I asked.
She looked away from the stage.
A Conflict Diagram traces opposing positions back to the needs behind them. It then identifies the hidden assumption that makes those needs appear incompatible.
Usually, both sides are right about what they need.
Sales needed speed and flexibility to win orders. Operations needed predictability to control production and cost.
The conflict was not between those needs.
It was between the solutions each side had chosen.
The hidden assumption was that offering short lead times and small quantities would require production to interrupt long runs.
Operations was right that constant interruptions would be expensive. But nobody had challenged the assumption that interruptions were unavoidable.
“Does production really need long runs?” I asked. “Or does it mainly need predictability?”
She thought for a moment.
“Predictability. If we know three days in advance what is coming, we can plan shorter runs without creating chaos.”
“Then lead time is not the real issue. Visibility is.”
If important customers provided a rolling three-day order forecast, operations might be able to plan small runs and still deliver within five days.
She went quiet.
On stage, someone finally asked why the dragon needed the cave.
Not for territory. He needed somewhere warm.
The queen did not want the cave. She wanted her crown.
Once their real needs became clear, the conflict disappeared. The dragon kept the cave, the queen recovered her crown and the children applauded.
“We have spent eight months negotiating the wrong thing,” she said.
“The compromise divided the difference on delivery time. It never challenged the assumption underneath.”
Sales and operations did not have incompatible needs. They had chosen incompatible solutions when a third solution might satisfy both.
Her daughter turned around to check that she was still there.
She waved.
“The next question is whether key customers will provide a rolling three-day forecast in exchange for five-day delivery,” I said. “That is a different conversation from the one you have been having.”
She picked up the programme from the chair beside her.
“Eight months,” she repeated.
“That is how long a conflict can last when nobody questions the assumption underneath it.”
Teenagers
The school was a Gymnasium in the south of the city.
I had come to meet the deputy principal, who was also the mother of a colleague. She preferred somewhere neutral, away from her office, so we sat on a low wall in the schoolyard during lunch.
Students moved around us in the unpredictable patterns of teenagers.
A group of fourteen-year-olds stood near the fence, phones in hand, practising the careful indifference of that age. Older students argued with great seriousness. One boy sat alone, eating a sandwich and reading. One girl tried to get a response from another who was determined not to give one.
The deputy principal watched them as we talked.
She had been dealing with a performance problem for two years. Several teachers were underperforming. Their lessons were weak, exam results were below average and parent complaints had increased.
The school board proposed a clear solution: formal reviews, performance targets and consequences.
She had resisted.
“Why?” I asked.
“Three of those teachers were excellent five years ago. Two received internal awards. They did not suddenly become bad teachers.”
“What changed five years ago?”
The school had introduced a new assessment system. Student evaluations now carried significant weight. Exam results were measured by class, and teachers were ranked against each other.
“What happened when you started comparing teachers by exam results?”
She already knew.
The teachers who accepted the most difficult classes began receiving the lowest scores. They taught disruptive students, remedial groups and children who started further behind.
Their results were lower, but not necessarily because their teaching was worse.Some of the school’s strongest teachers were now rated below average.
They stopped volunteering for difficult classes. Some began teaching for the exam instead of for understanding. One left for another school.
The students had not changed.
The system around the teachers had changed what it rewarded. Their behaviour changed in response.
FlowLogic starts from a clear principle: people are good.
When several capable people in the same role begin showing the same unwanted behaviour, the likely cause is not their character. It is the system.
Poor incentives create rational behaviour that can look like laziness, selfishness or resistance. Replace the person, and the replacement studies the same incentives and eventually behaves in much the same way.
Near the fence, the two fourteen-year-olds had ended their disagreement and were talking normally again.
“The board wants formal proceedings against two teachers,” she said.
“Then you may soon have two fewer teachers. But those who remain will still work inside the same system. The problem will continue.”
The real question was what the assessment framework rewarded.
It penalised teachers for accepting difficult students. Student evaluations partly measured popularity as if it were quality. Comparing teachers created competition where the school needed cooperation.
Those effects were not accidents. They came from the system’s design.
And the system could be redesigned.
She looked towards the boy with the sandwich. He had closed his book and was quietly watching the other students.
“He does that every day,” she said. “He reads through lunch and then watches everyone for five minutes. He once told me he finds them interesting.”
“How does the assessment system rate his class results?”
“Below average. Most of his students come from the integration programme.”
He was probably one of her best teachers.
The system could not see it.
Martial arts club
The sports hall belonged to a secondary school.
A martial arts club trained there every Tuesday and Thursday evening.
I had come at the invitation of the head coach, who was also production director at a packaging plant twenty minutes outside the city.
“Watch the training first,” he had said. “We’ll talk afterwards.”
Fourteen students aged thirteen to sixteen stood on the mat. Their experience varied, as did the particular restlessness that comes with that age.
A younger instructor was teaching a series of throws. He demonstrated the movement slowly, then at full speed, and asked the students to repeat it.
The experienced students produced something close to the example. Several younger ones struggled with the entry.
One boy repeatedly placed his foot in the wrong position.
The instructor watched him fail three times. Then he moved the boy’s foot to the correct place.
The boy tried again.
The same mistake.
The instructor repositioned the foot once more. This time, he said nothing. He held it there for two seconds, allowing the boy to feel the position, then stepped away.
On the next attempt, the boy performed the throw correctly.
The head coach had been watching from the side. During the water break, he joined me.
He had worked in production for twenty years. He knew the factory floor, machines, employees, products and customers.
Whenever a problem appeared, he usually had an explanation within minutes.
Often, he was right.
Sometimes, he was wrong—and he rarely stayed long enough to discover which.
“Never think you understand” does not mean ignoring experience. It means recognising that an explanation is not the end of an investigation.
The improvement loop should continue:
Observe. Question. Understand. Improve. Observe again.
Certainty breaks that loop.
You observe, form a conclusion and stop looking. The original explanation is never properly tested.
“I had a machine causing rework three times a week,” he said. “I knew the setup technician was inconsistent. I knew it for two years.”
“Last month, I watched the full setup process for the first time. The variation was real, but it came from a worn alignment guide. Consistent setup was physically impossible.”
“The technician was doing the best anyone could have done. For two years, I was certain about the wrong cause.”
On the mat, the boy was now repeating the throw successfully. The instructor had moved on and was watching another student with the same patience.
“He doesn’t assume he knows why a student makes a mistake,” the coach said. “He watches until he sees it.”
“That is the loop. Every correction begins the next observation. It does not end the investigation.”
The students began moving faster in pairs. The boy who had struggled now had the cleanest technique.
The instructor noticed but said nothing.
That was also a form of instruction.
“Twenty years in production,” the coach said, “and I thought I knew the floor.”
“You knew the version that existed the last time you looked carefully. The factory has changed since then. The question is whether your understanding changed with it.”
He watched the training for another moment.
“There are three other machines I have already explained to myself. I haven’t watched any of them.”
“That is where to start.”
Sales call
He had worked in distribution sales for nineteen years.
He knew the feeling that sometimes appeared during the first twenty minutes of a meeting: something was wrong, although he could not yet explain what.
He had learned to trust that feeling.
Eventually, he also learned that trusting it was not the same as understanding it.
We had known each other for three years. He called me from his car after a two-hour meeting with a prospective distributor.
“Something is off,” he said. “I don’t think they’re serious.”
“What happened?”
The prospect was a regional distributor of building materials. It had a strong market position, a capable team and an interest in adding his company’s products.
By normal standards, the meeting had gone well.
They agreed on first-year sales targets and discussed the territory. The commercial director spoke about commitment and long-term cooperation.
“What did they ask about reaching the targets?” I asked.
He went quiet.
“Nothing. They simply accepted them.”
“There it is.”
His instinct was probably correct, but the reason behind it was still unclear.
A gut feeling cannot easily be shared, tested or improved. When someone asks why, the conversation usually stops.
A clear chain of reasoning does the opposite. It makes the concern visible and testable.
“Build the chain out loud,” I said.
They had accepted the targets without asking how to achieve them.
That suggested two possibilities: either they already had a plan they had not shared, or they did not consider the targets real.
If the targets were not real, they would not invest in the salespeople, training and activities needed to reach them.
Without that investment, first-year results would disappoint.
When the results disappointed, the distributor would blame factors outside its control: the market, product positioning or price.
The next discussion would resemble the ones he had already had with three other distributors during the previous four years.
He was quiet again.
“That is exactly what happened with the last two.”
“Then you need to establish whether today’s behaviour is the same warning sign—or whether they have a real plan they simply did not share during the first meeting.”
“How do I find out?”
“Ask them to explain how they will achieve the first-year target. Request specific activities, staffing, training, timing and a date for the first order.”
“Present it as a standard part of distributor onboarding. Their answer will tell you more than today’s meeting.”
“And if they refuse to provide the detail, that is also a signal.”
“A much clearer one than instinct alone. You can share it with your manager, discuss it with the prospect and use it later to understand what happened.”
He started the car.
“The feeling was right, but I couldn’t defend it.”
“That is intuition. It is nineteen years of experience compressed into a signal. It is useful, but it is not yet something another person can test or act on.”
“Turning the feeling into reasoning is the work.”
He said he would send the follow-up that afternoon.
“I already know what they’ll say.”
“Write down your expectation anyway. If you are wrong, you need to know exactly where your reasoning failed.”
Phone launch in Seoul
The electronics retailer had forty-three stores across South Korea.
A new device launched on Friday. By Sunday evening, fourteen stores had sold out.
By Tuesday, eleven still had no stock.
At the same time, six other stores had unsold units in their back rooms. Staff had stopped promoting them because a new colour would arrive the following week.
The head of inventory planning explained the situation from a café near Gangnam Station.
From our table by the window, we could see a queue outside a competitor’s store.
They still had stock.
She had been in the role for eight months, but the problem was older. It happened during every major product launch.
Some stores sold out within days. Others received too much. For the next three weeks, the company moved units between locations while the best sales opportunity slowly disappeared.
“How is replenishment triggered?” I asked.
“Every store submits a weekly order based on what it expects to sell the following week. The warehouse reviews the requests, adjusts them against available stock and ships once a week.”
“What happens if a store sells out on Tuesday?”
“It waits until Friday to submit the order. We process it on Monday, and the stock arrives on Wednesday at the earliest.”
Nine days without stock.
That was the problem.
It is the retail inventory paradox: a company has too much stock and too many shortages at the same time.
This was not happening despite the replenishment system.
It was happening because of it.
The company used push logic. The warehouse forecast demand and sent stock to stores on a fixed schedule.
Across forty-three locations, every forecast error created imbalance. Stores that estimated too high received excess stock. Stores that estimated too low—or faced an unexpected increase in demand—ran out.
Better forecasting would not solve the problem quickly enough.
The company needed pull logic.
Instead of sending products based on expected sales, it should replenish stores based on actual sales.
Keep the main buffer at the central warehouse. Replenish stores daily in small quantities. If one store sells three units today, send three replacements tomorrow morning.
Pooling inventory centrally means one buffer can protect all forty-three stores. Higher sales in one location may be balanced by lower sales elsewhere.
The company can hold less total stock while improving availability.
She looked at the queue across the street.
“We have enough stock. It is simply in the wrong places.”
“That is the real problem. Total inventory matters less than where the product is when a customer wants to buy it.”
Weekly push planning asks, “What will every store need next week?”
That question cannot be answered accurately.
Daily pull planning asks, “What did every store sell yesterday?”
That can be answered exactly.
“Our warehouse system already provides daily sales by location,” she said. “We have the data.”
“Then information is not the bottleneck. The decision rule is.”
The company was using its data to support forecasts. The same data could automatically trigger replenishment.
That required a policy change, not a new system.
Outside, the queue had barely moved. Someone near the front checked their phone, perhaps looking for stock elsewhere.
“If we had replenished daily from Monday, the stores that sold out on Sunday would have had stock by Tuesday.”
“By Tuesday morning,” I said.
“The queue would be outside your stores, not theirs.”
Sneaker shop in Melbourne
The store was on Swanston Street: three floors, each with four hundred square metres of selling space, in one of the city’s best locations.
The owner had managed it himself for eleven years. He knew his regular customers, his bestselling shoes and the frustration of watching someone leave because their size was unavailable.
A trade association contact had introduced us.
He carried around eighteen thousand pairs across the three floors. Yet the models and sizes customers wanted most were regularly out of stock.
“How do you order?” I asked.
He placed orders with his three main brands four times a year, twelve weeks before each season.
At that point, he had to commit to models, colours, quantities and size distributions. The brands then allocated stock against those orders.
What arrived was what he had to sell.
The problem began before the first shoe reached the shelf.
Forecast-driven distribution forces decisions to be made when uncertainty is highest.
Twelve weeks before the season, he could not know which colours would become popular, which models competitors would promote or which sizes would sell faster than expected.
He made his best estimate. The brands then added their own allocation decisions.
By the time the shoes arrived, any forecasting error was already fixed into the stock.
The result was predictable.
Popular models sold out halfway through the season. Slower models remained on the shelves and later needed discounts.
The stock existed, but in the wrong mix: too few of the right sizes and models, too many of the wrong ones.
“Which sizes sell fastest?” I asked.
“EU 42 to 44 for men. Always. I have known that for eleven years. I already order more, but they still sell out.”
“Ordering more does not solve the structure. It only changes the forecast.”
He might have more popular sizes overall, but he still had to decide twelve weeks early which models would need them.
We were standing on the second floor. Three pairs of the same trainer in sizes 45 and 46 sat at the bottom of a display.
The space for size 42 was empty.
The solution was not a more accurate forecast. It was a different supply arrangement.
With his sales volume and supplier relationships, he could negotiate smaller, more frequent deliveries: seasonal open orders with quantities released according to actual sales.
Some brands already offered this to important accounts.
He had never used it because large early orders came with lower prices. His purchasing decisions had always focused on unit cost.
That was the trade-off.
A lower price for stock he might not sell, or a slightly higher price for stock that matched real demand.
The end-of-season discount on a slow colour often cost more than the premium for smaller orders. A lost sale because size 42 was unavailable cost more than either.
He picked up one of the size 46 shoes.
“I have always ordered the way the brands prefer—large commitments, placed early.”
“They prefer that because it transfers the forecast risk to you. You hold the stock and pay for the mistakes.”
He returned the shoe to the display.
“The supply model I need already exists. I have simply never asked for it.”
The change required a different discussion with suppliers and a different internal measure: sell-through instead of purchase price.
He would pay slightly more per pair but hold far fewer pairs that customers did not want.
He looked at the empty space for size 42.
“Eleven years.”
“Experience does not make the forecast certain,” I said. “The structure has to change.”
Haircare company
The company had produced professional haircare products for thirty-eight years from the same factory outside Bologna: shampoos, treatments, colour developers and styling products.
The founder’s son now ran it. He had studied in London, returned home and spent five years wondering why the business his father built so simply had become so difficult to manage.
The main problem was distribution.
The company supplied salons across Italy, France and Spain through eleven regional distributors. Each held its own stock, ordered on its own schedule and managed its own salon customers.
We met at the factory and started in the warehouse.
The raw materials were neatly organised. The finished products told a different story.
Several pallets of a conditioning treatment occupied a large part of the floor. Sales had been slow for six months.
Three metres away was an empty section where the colour developer should have been. It was the fastest-selling product in the range and had been unavailable for eleven days.
“How do distributors order?” I asked.
“Monthly. Each sends a forecast, and we prepare a shipment.”
The distributor estimated what it would need. The company adjusted that estimate. Production then adjusted it again according to available capacity.
“Three estimates on top of each other,” I said. “Each adding another error.”
He nodded.
A consultant had advised the company to hold safety stock at every distributor. Total inventory across the network had increased by thirty percent.
Product availability had not improved.
That is a predictable result of push distribution.
When every distributor holds its own buffer, the network needs more stock because each location protects itself against its own uncertainty.
Eleven distributors each carrying sixty days of safety stock require far more inventory than one central buffer protecting the whole network.
Demand across eleven regions varies less in total than it does at each location separately. Higher sales in one market can be balanced by lower sales in another.
The solution was structural.
Replace monthly forecast orders with weekly replenishment based on actual sales.
Each distributor would hold a small local buffer—perhaps one or two weeks. Every week, it would report what salons had bought. The company would replace those quantities from a centrally managed buffer.
If a distributor sold fifty units, the company would send fifty.
Less forecasting. Smaller shipments. Fewer layers of error.
He looked at the empty space for colour developer.
“Our distributors are holding products they expected to sell. Meanwhile, we have none of the product customers are actually buying.”
“That is the main failure of a push system. Adding local stock does not remove the forecast error. It creates more stock in the wrong places while shortages remain elsewhere.”
He walked over to the slow-moving conditioner.
“This has been here since February.”
“And it may still be here in December if the system stays the same. Your distributors will have similar products—ordered months ago and still occupying their warehouses.”
The entire network was holding the wrong products in the wrong places because replenishment decisions had been made before anyone knew what salons would buy.
“The distributors won’t want to share weekly sales data,” he said.
“Some won’t, at first. But those that do can hold less stock and face fewer shortages. Once the others see that, the conversation changes.”
He looked from the empty section to the conditioner.
“We make good products. The product isn’t the problem.”
“No. The product is made correctly and then placed in the wrong location. The distribution structure determines where it ends up.”
He said he would call his largest distributor that afternoon.
“Ask what they sold last month, product by product,” I said. “Not what they ordered. What they sold.”
“I have never asked that.”
“That is where to start.”
Cosmetics company
The meeting had been arranged through a contact in the beauty industry.
The company was based in Valencia and produced professional cosmetics, skincare and colour products for salons. It had sixty-one products and independent distributors in nine European countries.
After twelve years of growth, the company had reached a wall.
The commercial director flew to Lisbon, where we met in a hotel. Portugal had complained the loudest.
She placed the distributor’s letter on the table without comment.
The complaint was about product availability.
The Portuguese distributor regularly ran out of the three fastest-selling lines while holding too much of the slower products.
Commercial terms required minimum order quantities, so he was financing stock he did not need while losing sales on products he could not obtain.
“Every distributor says something similar,” she said. “If I solve Portugal, the next letter comes from the Netherlands or Poland.”
“How do they order?”
“Once a month. They send a forecast, and our warehouse in Valencia ships against it.”
Some distributors forecast better than others. But the forecast was always prepared before the month started, and every month brought surprises.
“The main problem is not that the forecasts are inaccurate,” I said. “It is that your system needs them to be accurate.”
Every distributor tried to predict demand in its own country, with different salon customers, seasons and promotions.
Each operated as a separate island of uncertainty. Each had to stock its warehouse based on its own prediction of the future.
“What is the alternative?” she asked.
“Pooling the stock.”
If Portugal ran out of Intense Repair Serum, the product might still exist elsewhere in the network. It could be sitting in a Czech warehouse or waiting in Valencia.
The stock existed, but Portugal could not access it quickly enough. By the next monthly order, the sale was already lost.
The central warehouse should become the main inventory location. This could remain in Valencia or move to a dedicated European hub.
Distributors would hold only a small local buffer—enough for two or three weeks.
When Portugal sold ten serums, it would report those sales and automatically receive ten replacements.
No monthly forecast and no large monthly order. What was sold would be replaced.
“How much stock would we need in Valencia?”
“Less than your nine distributors currently hold together.”
That was the part that appeared illogical.
Nine distributors carrying their own safety stock meant nine separate buffers, each protecting against local demand changes.
One central pool could serve all nine. A slow month in one country could partly balance a strong month in another.
The company could therefore hold less total stock while improving availability.
She looked at the complaint letter.
“He has too much of the wrong stock and none of the right stock. That isn’t his fault.”
“No. He ordered what he expected to sell. The expectation was wrong, so both the excess and the shortages arrived in his warehouse.”
The same complaint would continue until distributors no longer had to predict demand independently.
“They would need to share sales data every week,” she said.
“Yes. You take more responsibility for inventory, and they give you visibility into what salons are buying.”
Some distributors would resist. But those that adopted pull replenishment first would reduce stock and face fewer shortages.
That would help convince the others.
She folded the complaint letter and returned it to her bag.
“Twelve years of monthly forecasts, and not once have all nine distributors been satisfied in the same month.”
“That isn’t a coincidence,” I said. “The system was never designed to produce that result.”
Office supplies company
The procurement director had managed the Polish operation of an office-supplies distributor for nine years.
The company carried seven hundred products: paper, folders, binders, printer cartridges, pens and notebooks. It supplied large companies and smaller businesses across Poland.
She was good at her job; the problem was the ordering calendar.
We met in a conference room on the fourteenth floor of a Warsaw office building. Before saying anything, she turned her laptop towards me.
A spreadsheet showed inventory by product.
Red and green.
Mostly red.
“We order once a month,” she said. “At the beginning of each month, we forecast the next four weeks. The order arrives within four days, and then we spend the rest of the month watching what we predicted incorrectly.”
“What happens when a popular item runs out halfway through the month?”
“We wait, or we place an urgent order with faster delivery and a higher price. We either lose the sale or lose margin.”
“And the slow-moving products?”
“They stay in the warehouse. We pay for the space, and some become obsolete—especially printer cartridges. A cartridge selling well today may be worthless when printer models change.”
The main problem was the four-week forecast period.
With monthly ordering, the company had to predict four weeks of demand before it happened.
That was enough time for demand to change. They bought too much of what they expected to sell and too little of what customers actually wanted.
Safety stock had to cover four weeks of uncertainty. Even then, popular products still ran out because the forecast error was sometimes larger than the buffer.
“Should we increase safety stock?” she asked.
“No. That is the trap.”
Better availability does not always require more stock. Often, it requires faster replenishment.
“If you order weekly, your forecast period falls from four weeks to one. The uncertainty becomes much smaller, so you need less safety stock.”
Fast-selling products are replenished before they run out. Slow products are not reordered in quantities that may sit for months.
“But weekly orders cost more,” she said. “More transactions and more administration.”
“That needs to be calculated properly.”
The cost per order might increase. But that cost had to be compared with urgent shipments, lost margin, excess storage, obsolete products and the administrative work needed to solve constant shortages.
The monthly system appeared cheap because its ordering cost was visible.
Its stockout and overstock costs were hidden.
She remained quiet for a moment.
“Two customers reduced their spending last quarter. They never said it was because of availability, but I know what happened.”
Customers rarely announce that they are leaving because of shortages. They simply order less or move part of their business to another supplier.
Revenue falls without a clear complaint.
“If we order weekly, suppliers must support shorter lead times.”
“Some will and some won’t. Start with those already delivering within two or three days.”
The first trial should cover high-volume products that most often ran out mid-month.
The result would become visible quickly: lower stock levels and fewer shortages.
She closed the spreadsheet.
“We have increased safety stock for three years, and nothing has improved.”
“Adding inventory to a monthly ordering system does not repair the ordering system. It only makes the same problem more expensive.”
She wrote something in her notebook.
The main lever had never been the amount of inventory.
It was the frequency of replenishment.
The school
The head of year had taught history for twenty-two years.
She knew her students. She was also certain that the school director’s proposed behaviour programme was unnecessary, would fail and might make matters worse.
She had said so during two staff meetings and repeated it in an email the director had never fully answered.
I was there because he had asked for help.
“Not help convincing the teachers,” he said carefully. “Help thinking it through together.”
The problem involved eight students aged fourteen and fifteen. Three had always been difficult. The other five had started the year as reasonable members of the school community but had become a daily source of conflict by November.
They arrived late, disrupted lessons and became confrontational when challenged.
The head of year believed the existing disciplinary system was sufficient and that the director was overreacting.
The director believed the current approach was failing and something had to change.
Both positions were sincere; that was why the conflict continued.
“What do you actually observe?” I asked her. “Not your interpretation. What do you see?”
“They arrive late, sit at the back, talk during lessons and leave early when they can. When teachers challenge them, they become defensive or dismissive.”
“Is that new behaviour for all eight?”
She thought for a moment.
“No. Three were already difficult last year. Five changed this year.”
“What changed for those five?”
She paused.
“Two moved to another residential area during the summer. One has a new family situation. I’m not sure about the other two.”
“So five students are showing new behaviour after changes outside school. But the disciplinary system was designed for the students they used to be.”
“The rules apply to everyone,” she said.
“That works when the rules produce the required result. When they don’t, you must ask whether the system still fits the situation.”
“So you want us to abandon standards?”
“No. I want to examine the assumption behind the conflict.”
She wanted to protect consistency and an approach that had worked before. The director wanted better results.
Both needs were reasonable.
The hidden assumption was that they could not have both — that changing the response meant giving up consistent standards.
But the eight students did not have the same problem.
Three showed a long-term behaviour pattern. Five had changed after something in their circumstances changed.
The school was applying one response to two different situations.
“The real conflict is not between you and the director,” I said. “It is between a uniform response and different underlying problems.”
She remained quiet.
“If we treat the groups differently, teachers need to understand why. Otherwise, it will look inconsistent.”
“That is the implementation challenge. The reasoning must be clear: why one student receives one response and another receives something different.”
That approach was harder than applying one rule to everyone.
But the single rule was already producing different results while treating every case as the same problem.
The director had remained silent. He looked towards her.
“I want to help design the new approach,” she said. “I don’t want it presented to me after the decision.”
“That was always the intention,” he replied.
“That isn’t how it felt during the staff meetings.”
Her resistance had not only been about the proposed change. It had also been about how the change was being introduced.
Once the assumptions became visible, she stopped defending her position and began solving the problem.
That is what good thinking tools do.
They do not win arguments.
They make the arguments unnecessary.
Distributor in Germany
It was the final day of a trade show in Düsseldorf.
The halls were emptying, and exhibitors were already dismantling their stands. In the canteen, I shared a table with an agricultural-equipment manufacturer from outside Osaka.
His name was Tanaka.
He had attended the same show for eleven years. Every two years, he returned with the same stand and slightly updated brochures.
He spoke careful English, choosing his words like someone who had been thinking about the same problem for a long time.
Eight years earlier, he had appointed a German distributor.
It was a good company with a strong reputation and established contacts. It attended the right trade shows.
Orders were strong during the first year. In the second, they fell slightly. By the fifth, Tanaka was travelling to Europe twice a year for meetings that increasingly felt like courtesy visits.
The distributor remained polite.
The sales figures did not.
“What do you know about sales to dealers and end users?” I asked. “Which products sell, in which regions, and to whom?”
He looked down at his coffee.
“We know what we ship to the distributor. The rest is their business.”
That was the problem.
Eight years of sell-in data.
No visibility of sell-out.
The distributor was not dishonest. It was simply doing what distributors do: selling the products that moved easily, protecting its own margins and managing its own customer relationships.
Tanaka’s goals and the distributor’s goals were not the same.
Nobody had built a system to align them.
“What have you tried?” I asked.
He mentioned a new price list, visits from the export manager, a jointly funded trade-show campaign and one product-training session attended by six people.
All were reasonable actions; none changed the structure.
“You have repeated market entry every year for eight years,” I said. “But you have never really entered the market.”
He was silent for a moment.
“What would that look like?”
“Local presence without building a local company.”
It would require a rollout plan with clear country priorities and deadlines. Someone would track not only shipments to the distributor but also sales to dealers and end users.
Distributor onboarding and training would continue throughout the year instead of happening once. Market activity would follow a system rather than a calendar of occasional visits.
Not a subsidiary.
Not another office.
An operating model -> Europe-as-a-service.
Tanaka returned to Japan two days later, and we stayed in contact.
What remained with me was not the solution. It was the sentence:
“We know what we ship to them.”
Sell-in is not sell-out.
Appointing a distributor is not the same as entering a market.
And even a good product does not sell itself across the European Union’s twenty-seven different markets and business cultures.
Manufacturers that understand this in year two can build momentum.
Those that understand it in year eight have lost six years they cannot buy back.
Delivery Schedule for skincare products
Thomas had been distributing professional skincare products for fourteen years — two hundred and forty salons and spas across Austria.
He knew the business well: the seasonal lines, the slow movers, the products that sold out two weeks before the next delivery and the ones that sat on shelves until they expired.
He had called me because his three largest accounts had given him the same warning in the same month. If availability didn't improve, they would look elsewhere.
We met at his warehouse on the edge of the city, a Tuesday morning in early March. A truck was being unloaded outside. He watched it from the window while we talked.
His model was simple: clients ordered at the start of each quarter. He consolidated, placed one large purchase from his supplier in Italy, and shipped within the first two weeks. Efficient. Low freight cost per unit. Predictable for his warehouse team.
I asked to see the write-off numbers from the previous year.
He pulled up a spreadsheet without hesitation — which told me he already knew this was coming. Seventeen percent of purchased volume written off.
Expired products, discontinued seasonal colours, a reformulated treatment line whose old version was now unsellable. He had absorbed all of it.
I asked what freight cost as a percentage of revenue.
Four point two percent, he said.
I asked what monthly deliveries would cost instead.
Around seven percent. He had already run the numbers. Nearly three percent higher. He said it in the tone of someone presenting a closed case.
I said: you are losing seventeen percent of purchased volume to write-offs. Your freight is four point two percent. If monthly deliveries bring write-offs down to five percent, you have saved twelve percent of purchased volume.
You are paying three percent more in freight to save twelve percent in losses. That is not a cost problem. That is a margin improvement.
He looked at the spreadsheet.
The write-offs were structural. Quarterly ordering meant forecasting ninety days of demand before it occurred. At ninety days, the forecast was almost always wrong — he over-ordered on fast movers that became slow movers when trends shifted, and under-ordered on slow movers that became emergencies when a client ran an unannounced promotion. By the time the error was visible, the capital was committed and the goods were in the warehouse.
Monthly deliveries changed the exposure window from ninety days to thirty. The forecast error at thirty days is a fraction of the error at ninety.
Less stock held, less capital tied up, less to write off when a product line changed.
I also asked about emergency orders.
Four or five times a year, he said, a client runs short mid-quarter and calls in a panic. If he has stock, he ships it. If not, he pays express freight from Italy — roughly eight times the standard rate. Those costs were not in the spreadsheet. They never are.
I asked what happened when a salon ran out of a product mid-quarter.
They called, he said. Sometimes ordered from a competitor to cover the gap. Sometimes didn't come back.
A salon that runs out of a product mid-treatment doesn't just experience a stockout. They experience an embarrassment in front of a client sitting in a chair.
Both problems — overstock and stockout — trace back to the same cause: too long between deliveries, too much committed too early.
Thomas looked at the truck outside. The driver was signing something at the warehouse door.
He said: my clients will have to order more frequently. Some won't want to do that.
They already deal with stockouts, expired products, and three months of stock in a backroom, I said. Monthly deliveries give them less to manage, fewer gaps, and no expired product. Most will prefer it once they've tried it.
He said: and my supplier in Italy?
A separate conversation. Once you know what you want to order and when, you negotiate. Suppliers who want your business will find a way.
He was quiet for a moment. The warehouse had gone still.
He said: I've been optimising for freight cost per unit for fourteen years. It never occurred to me that freight was the cheapest number in the calculation.
That is what unit cost does. It is visible, easy to measure, and improves when you order in larger quantities. Everything it causes — the write-offs, the stockouts, the emergency shipments, the clients who quietly leave — those costs are real but they show up in different spreadsheets, or they don't show up at all.
The most expensive decision in his business was not the one with the highest visible cost. It was the one that looked the most efficient.