One of my favorite CI projects was also one of the smallest.
A few extra seconds per transaction doesn’t sound meaningful…until it scales across an entire operation.
Lots of Continuous Improvement projects are ambitious. Some require massive investment in new tools, equipment, or warehouse reconfiguration. In fact, some leaders are convinced that all improvement needs to be on a grand scale. But my favorite CI project I’ve ever led centered around something incredibly small: one extra data entry.
At the time, I was leading a receiving operation with roughly 20 employees handling grocery inventory. Receivers would scan incoming product, stow it directly to shelf locations, and manually enter expiration dates into handheld scanners as part of the receiving transaction.
The process itself made sense. The system had expected shelf-life ranges configured by product type. If an employee entered a date outside the acceptable range, the system would prompt for a second entry as verification. That safeguard was designed to catch mistakes before inventory hit the floor.
The problem was that the product characteristic tables…the part of the code these entries would reference…was wrong. The data was bad. For most products, it was set to 1 day. A can of soup? One day. A gallon of milk? One day. So instead of prompting for re-entry only on exceptions, the system was requiring a second date entry for every single item received.
At first glance, it didn’t seem catastrophic. Nobody was stopping production. No alarms were going off. The operation continued moving.
But after spending time on the floor, it became obvious that the extra step was creating constant friction in some of the highest-frequency transactions in the building.
That observation led to a simple question:
“What is this actually costing us?”
Quantifying the Problem
The receiving team averaged roughly:
- 20 employees
- 7.5 working hours per shift
- ~120 units per hour per employee
That translated to approximately 18,000 units processed daily.
We estimated the unnecessary second date entry added about 2.5 seconds per item. Again, individually, almost nothing.
At scale:
- 18,000 units/day × 2.5 extra seconds
- = 45,000 lost seconds daily
- = ~12.5 labor hours per day
That equated to:
- roughly 8% productivity loss
- or nearly 2 full-time employees worth of capacity consumed by a software defect
Not because employees were underperforming. Not because the process design was poor. Simply because a small system issue had embedded itself into a high-volume workflow.
The Bigger Lesson
This experience reinforced something that applies far beyond warehouse operations:
Small inefficiencies become massive when attached to high-frequency work.
Most operations do not collapse because of dramatic failures. They erode through thousands of tiny interruptions:
- extra clicks
- duplicate entries
- unnecessary approvals
- avoidable motion
- systems that force people to work around them
Individually, these seem trivial. Collectively, they quietly consume labor, attention, and throughput every day. They are waste.
Why Direct Observation Matters
What made this issue visible was not a dashboard or KPI report.
It started with direct observation on the floor. Watching the work happen in real time. Listening to operator frustration. Looking for moments where the process felt slower, heavier, or more repetitive than it should.
That is one of the most overlooked parts of continuous improvement.
You cannot improve work you do not truly understand.
The Outcome
Once the issue was quantified, it became much easier to prioritize and partner cross-functionally on a resolution. The discussion shifted from anecdotal frustration to measurable operational impact.
Fixing the defect effectively returned more than 12 labor hours of productive capacity back to the operation each day without adding headcount.
All from removing a few unnecessary seconds from a transaction repeated thousands of times daily.
At scale, small frictions stop being small.