One Bottleneck, Thirty Days: A Productivity Method That Needs No Software

From Digital Tools to Daily Habits

The previous pieces in this series covered the case for AI diffusion, a digital maturity index, factory use cases, the gap between belief and adoption, and data protection. Most of them end with the advice to start small. This piece turns that into a method. It is our framework, and the numbers in the example are invented.

Week 1: Choose and measure

Pick one bottleneck. Ask your team, "What wastes the most time or money every week?" Common answers are rework, waiting for materials, searching for information, delayed approvals, and repeated customer queries. Choose the one with the largest cost and one you can influence. Then measure it for a week. Record how often it happens, how long it takes and who is involved. A simple tally sheet taped to the wall is enough. Without a baseline you cannot tell later whether you improved anything.

“Improve one thing, measure it, and write it down. Then do it again.”

Week 2: Find the cause

Ask "why" repeatedly. If deliveries are late, why? Because packing is slow. Why? Because cartons are not ready. Why? Because the order sheet arrives late. Why? Because it is typed from handwritten notes. The cause is rarely where the symptom shows. Walk the process with the people who do it, and draw it on a single page with each step and the waiting time between steps.

Week 3: Try one change

Pick the smallest change that addresses the cause. It might be a standard form, a checklist, a changed layout, a shared spreadsheet, a short daily meeting or a simple tool. Avoid changing five things at once, because you will not know which one worked. Brief the team on what is being tested and why, and ask for their ideas.

Week 4: Measure again and decide

Collect the same numbers as in week one. Compare. If the result improved, write the new method as a one-page standard, train everyone on it and decide who checks it each month. If it did not, ask why, adjust or try another change. A failed test is not a failure of the sprint; it tells you something about the cause.

An invented example

A small print shop finds that 12 of 60 jobs a month need rework because of file errors that surface only at the press. In week one the owner logs every error type. In week two she traces most to artwork received in the wrong format. In week three she introduces a one-page checklist that front-desk staff use before accepting artwork. In week four, rework falls to 5 jobs out of 62. She writes the checklist into the standard procedure. The shop saves press time and customer goodwill. These figures are invented to illustrate the cycle and should not be taken as typical.

A tracking sheet

Use six columns: date, what happened, time lost, cost estimate, cause and action. After four weeks, add the columns. If you are considering a tool, the sheet shows what the tool must improve and by how much.

Where technology fits

If the cause is the lack of information, a shared spreadsheet or a simple app may help. If the cause is repetitive manual entry, a tool for forms or scanning may help. If the cause is poor materials, no tool will fix it. Technology is a means; match it to the cause you found.

Avoiding common traps

Do not start with the most complicated problem. Do not blame individuals for system problems. Do not skip the baseline. Do not run more than one sprint at a time in the same team. And do not forget to recognise those who help; ideas come from the people who do the work.

Making it a habit

Run a sprint every quarter. Keep a list of problems for the next one. After a year, you will have four improvements documented and a team that expects to make things better.

For multi-site and family firms

Where a firm has several locations, run the sprint in one and share the standard with the others. In family firms, include non-family staff in problem-finding; they often see issues that the owners have stopped noticing.

What to do when the team resists

Resistance usually signals that the change adds work for someone without a visible benefit. Ask the person what the change costs them, and adjust. Show the baseline and the result so that the gain is concrete. Let the team name the new standard; ownership of the name often leads to ownership of the habit. Editorial framework; general information. Example numbers are invented for illustration.