It’s the Requirements, Stupid: Why So Many Warehouse Improvement Projects Go Sideways
- Mar 11
- 6 min read
Issue #006 – March 11, 2026
In This Issue (tl;dr):
Too often, projects in warehouses and DCs go sideways because teams start by shopping for solutions instead of defining the problem. Whether it’s automation, software, equipment, or a 3PL, the right approach is always the same: clearly define the problem and the business requirements first, and then evaluate solutions that meet them. If you skip that first step, you risk making expensive mistakes. Like buying a multi-million-dollar system you never really needed. Good decisions start with good requirements definition. So, be requirements-driven, not solutions-driven.
Many warehouse improvement projects begin the same way:
Someone says, “We need to look at solutions.”
Sometimes that means attending trade shows like MODEX and walking the floor looking for interesting technology. Other times it means calling vendors to present automation systems, software, equipment, or outsourcing options like a 3PL.
But when clients tell me this, I ask two simple questions:
What problem are you trying to solve?
And what requirements must the solution satisfy?
I’m often met with that “deer in the headlights” look.
In other words, the client’s team started shopping for solutions before they clearly defined the problem and their business requirements.
And that’s a bit like buying a drill before deciding whether you actually need a hole.
And that’s a bit like buying a drill before deciding whether you actually need a hole.
The First Step of the Engineering Method
There’s a reason the universally adopted engineering method begins with defining the problem.
Not the solution.
The problem.
When I was studying for my Industrial Engineering degree at Georgia Tech in the mid-1980s, I had a terrific professor named John A. White, PhD. He was widely respected as a veritable guru of warehousing and distribution operations. (I still use the textbooks he authored!) One of the principles Dr. White drilled into his students’ heads was simple but powerful:
“Be requirements-driven, not solutions-driven.”
I’ve carried that principle with me for more than 40 years, and it has served me well.
Yet in warehousing, it’s remarkably common to see projects start the other way around. The team begins searching for solutions before they’ve clearly defined what the business actually needs to accomplish to be successful.
When that happens, the project is no longer an engineering exercise.
It’s just...shopping.
And shopping is how you end up with expensive regrets…and with a “solution” you now “manage” mostly by avoiding eye contact.

People Want Holes, Not Drills
A classic problem-solving principle says this:
People don’t buy a drill because they want a drill. They buy a drill because they want holes.
In warehouse operations, companies don’t really want:
Robots
Conveyors
ASRS
Software
A 3PL
They want outcomes:
Lower operating costs
Higher capacity
More throughput
Improved accuracy
Better service
Reduced risk
Those are the holes.
The equipment, software, process changes, or outsourcing arrangement is simply a possible way to achieve them. And that’s the point: the “right” solution to the problem depends on the business requirements.
The “Kid in a Candy Store” Problem
Trade shows like MODEX and ProMat are fantastic events. They showcase truly impressive technology and innovation. I love them!
But they can also create a dangerous dynamic.
When a business sends its people to these events in search of solutions before defining the problem and their business requirements in meaningful detail, the experience can resemble a kid in a candy store.
Everything looks exciting.
Everything seems useful.
And before long, someone falls in love with a shiny new object…er, “solution.”
The problem is that the business might still not have a clear answer to those two most important questions:
What problem are you trying to solve?
And what requirements must the solution satisfy?
If the answers aren’t clear, you’re not evaluating solutions; you’re collecting souvenirs. (Very expensive souvenirs.)
A “Solution” in Search of a Problem
I once attended a professional organization’s tour of an electronics manufacturer’s warehouse.
Several years earlier, the company’s management team had decided they absolutely needed a miniload ASRS. (I know this because I was working with them at the time.) So, they purchased one and installed it at a cost of several million dollars.
But during the tour, I noticed something curious.
The system was empty. And dark.
When I asked the company’s tour guide why the ASRS wasn’t operational, he rolled his eyes and said they never should have bought it because they didn’t actually need it. They eventually found that other storage and picking methods were more efficient and cost-effective.
Inviscid Man might summarize their situation like this:
“Great solution. Wrong problem.”
Or perhaps more bluntly:
“That was a very expensive way to store air.”
Don’t Cut Butter with a Chainsaw
Think about why nobody cuts butter with a chainsaw.
At least I hope not. Unless, of course, their goal was to redecorate the kitchen.
Have you considered why?
The goal of a warehouse improvement project isn’t to buy the most impressive or sophisticated solution.
The goal is to satisfy the specific requirements of the business…
Practically.
Sensibly.
Cost-effectively.
And with minimal risk.
The goal of a warehouse improvement project isn’t to buy the most impressive or sophisticated solution.
Sometimes the right solution really is a chainsaw. (Cue up The Texas Chain Saw Massacre.)
But often, a lowly butter knife does a better job.
And if the “butter knife” feels boring, that’s okay. Boring can be beautiful when it meets service levels, costs less, and doesn’t break down on third shift. At 2:00 a.m. During peak season.
Diagnose Before Prescribing
In our last article, we used a medical analogy.
Imagine a doctor walking into an examination room and immediately prescribing medication or surgery before examining the patient or asking any questions.
Would you respect that doctor?
Most of us would find that approach alarming. Yet warehouse improvement projects often proceed exactly this way.
Vendors are invited to present solutions long before anyone clearly defined the business requirements for the warehouse or objectively diagnosed the operational problems.
That, my friends, is putting the cart before the horse. Even though it might seem like a really cool cart.
A Real-World Example of Defining the Problem
A department-store chain once asked us for help planning a multi-million-dollar expansion of their receiving docks because they believed their inbound capacity was insufficient.
But when we examined their inbound patterns, we discovered something interesting:
About 40% of monthly receipts arrived in one week.
About 30% the next week.
About 20% the next.
And about 10% the final week.
Why?
Because all of the company’s buyers placed orders when their monthly “open-to-buy” budgets reset—at the same time.
So, instead of expanding the docks, we recommended staggering those budget open-to-buy dates so that only about 25% of the buyers placed their orders for new merchandise each week.
The result flattened the inbound spikes dramatically.
The expensive dock expansion was no longer necessary.
Lesson learned: The real problem wasn’t dock capacity; it was purchasing behavior.
A Practical Approach that Works
A better approach to warehouse improvement projects looks like this:
Define the problem clearly, using meaningful metrics and KPIs.
Define the detailed business requirements.
Identify sensible solution candidates for the defined requirements.
Objectively evaluate reasonable options.
Select and implement the best solution.
This disciplined approach applies whether you’re selecting:
Equipment
Automation
Software
A 3PL
Even simple process changes
Why should you care if this approach leads to a “less sexy” solution? Sexiness is great for marketing. Requirements matter more for operations.

When to Bring Vendors Into the Process
Vendor presentations and demonstrations can be extremely valuable. But timing is important.
The right time to ask vendors to present their solutions is after your business requirements have been clearly defined and the appropriate solution category has been identified.
Otherwise, vendors will naturally focus on showing off bells and whistles. (Wouldn’t you?) They’ll put on their best swimsuits and strut their stuff. Proverbially speaking, of course.
That’s understandable. It’s their job.
But your job is to ensure that the chosen solution actually satisfies your business requirements. Not your team’s “ooh-ahh” reflex.
The Bottom Line
In my experience, when a business begins with careful definition of their problem and their business requirements, the result is always better.
And clients are often surprised to discover that the best solution isn’t necessarily the most expensive one. Sometimes it’s something simple.
So, before heading to the next trade show or calling the next vendor, remember the principle my Georgia Tech professor taught me many years ago:
“Be requirements-driven, not solutions-driven.”
Inviscid Man might put it this way:
“If you shop for a solution before you define your problem, it’s probably gonna be expensive.”
And if you’d like help clearly defining your warehousing problems and their business requirements and finding sensible solutions, call us. We’re here to help.
Until our next episode...thanks again for joining us!

Stephen T. Hopper, P.E.
Founder & Principal
Click “Subscribe” below if you want these insights delivered straight to your inbox. We promise we’ll only send valuable content. But we won’t spam you. Ever.
Saving the World, One Warehouse at a Time™





I have three other examples for you.
A GOH area that was improperly used. It was run in the opposite way that it was designed. (Retail distribution. Solved by realigning GOH area.)
An AS/RS system where instead of using it pallet in / pallet out they were case picking from it exclusively. (Auto parts. I never learned if this was resolved.)
A receiving dock that had to repalletize shipments from vendors because they were too tall for the racking system. (Solved by revising purchasing T&C's.)