How Hardis Supply Chain would write its own WMS specifications (the method we’d apply to ourselves)

Chapter 1: Setting the pace so the project doesn’t drift off course

If we had to write our own specifications tomorrow, we’d start with the timeline.

Or more precisely, with the pace of the project.

As a software vendor, we’re in a unique position, having spent decades observing first-hand how WMS selection happens and specifications are written.

In the more than 40 years we’ve been in the business, we’ve seen far too many tender processes stretch out over 3 years or even longer.

And by the time they wrap up, everything may have changed: new people, new priorities, and a version of the product that looks nothing like the demo.

Our recommendation: 12–18 months maximum

This isn’t about rushing for the sake of speed.

The point of this timescale is to keep everyone aligned and working with information that’s still current.

Because when a tender process drags on too long, things inevitably start to drift: needs evolve, stakeholders change and the operational reality moves further away from the original document.

What we’d do: Set clear milestones

We’d set 3 firm, accountable milestones:

1. Month 6: shortlist and site visits
2. Month 9: detailed demos built around your use cases
3. Months 12 to 18: final decision and project scoping

At each stage, we’d assign an owner and set a defined deliverable and a fixed deadline.

This approach eliminates ambiguity and gives everyone clear timings to work toward.

Why this pace is a game-changer?

Setting this kind of pace keeps the momentum going and provides a clear focus for conversations.

Decisions are made at the right time.

Comparisons are based on up-to-date information.

And the vendor’s response reflects your current operational reality, not a snapshot taken a year earlier.

It’s also the best way to ensure team consistency, with the same people pursuing the same vision from start to finish.

In short, it helps turn a set of specifications into an implementation that actually holds up over time.

Chapter 2: Scoring and ranking requirements for effective comparison

Returning to our opening point: if we had to write our own specifications tomorrow, we’d start by cutting out the noise.

We’d map out a typical day in the warehouse, identifying:

1. Where the real pain points lie
2. What wastes time
3. What generates unnecessary costs

Avoiding bloated Excel spreadsheets

We’ve seen far too many spreadsheets where every requirement carries the same weight.

Running to hundreds of rows, these files can be reassuring at first glance, but almost impossible to interpret when a WMS choice has to be made.

Documents like these don’t help project teams make decisions. They cause paralysis.

Our approach would be to do the opposite: establish a clear order of priority, which in turn makes it much easier to compare vendors.

How we’d structure the requirements

We’d start with the core processes that shape day-to-day operations at the site.

Not every tiny variant, but the 10 or 15 big-picture processes that reflect how the warehouse really works.

These would be things like incoming goods, picking, shipping, returns, operational oversight and so on.

Next, we’d assign each process a level of criticality:

1. Blocking: without this, the project can’t go live
2. High-priority: this is required for proper operation
3. Preferential: this is a useful improvement, but it’s not essential

Then, we’d build a multi-vendor scoring matrix with each requirement rated and weighted according to its criticality.

Reviewing this matrix just a couple of times would give a clear picture of each application’s strengths and drawbacks.

It also ensures comparisons are made on a like-for-like basis, leading to clear answers instead of endless back-and-forth.

We prefer to keep this framework short and easy to understand, so everyone can act on it right from the outset.

This kind of discipline doesn’t constrain the conversation. It makes it meaningful.

Looking for quick wins during site visits and demos

Not all requirements carry the same weight. Some deliver immediate value.

We’d look for these quick wins during site visits–ideally with customers in the same sector or industry – and during WMS demo built around specific use cases.

It could be a print setting that streamlines the shipping process or a simple check that builds reliability into a returns flow.

These tangible gains build confidence and speed up the rest of the process.

Chapter 3: Getting the scope and timeline right for realistic costings

We’ve often seen WMS system projects start with big ambitions.

At the outset, anything seems possible.

But later on, it becomes clear that the scope is too broad, too vague or too ambitious to be costed accurately against real-world practices and the actual cost of a warehouse management system.

And once the scope starts shifting, everything else can shift with it: the budget, the schedule, and even the relationship between the company and the vendor.

“We want it all and we want it now”

We always start by narrowing things down. How many sites? How many flows? How many users?

These simple questions help frame the project properly.

A solid WMS system is built not on assumptions but on measurable foundations.

Defining a realistic scope is therefore an important first step toward realistic costings.

What we’d do

We’d start with a pilot.

One site.

One flow.

One product category.

Not an exhaustive rollout. Just enough to test the application under real-life conditions.

The pilot becomes our testing ground, allowing us to validate assumptions, adjust our approach and develop a budget rooted in reality. It also gives your people and future key users the chance to get hands-on with the application and build their expertise.

Next, we’d roll out a phased deployment plan—site by site, flow by flow—aligned with the project’s objectives.

We’d include all the key variables: number of users, volumes to be processed, systems to be integrated, and any binding logistics constraints.

This information helps keep the timings achievable and ensures that vendors’ responses accurately address your requirements.

Last but not least, we’d put together a timeline that everyone can actually meet.

Because a schedule that’s realistic—for both customer and vendor—sustains momentum rather than slowing things down.

Why this scoping exercise is a game-changer

A well-defined scope makes everything clearer and easier to understand.

Everyone talks from the same page and operates within the same constraints.

Vendors can build accurate responses.

Budgets are credible.

And time is saved because nobody has to deal with uncertainties or unspoken assumptions.

We know this kind of discipline isn’t always easy.

But it’s what turns an initial intention to buy into a project that can actually be delivered and sustained over time.

Chapter 4: Spelling out the importance of IT and interfaces

In every WMS project we work on, there’s always a moment when everything slows down.

Business teams and budgets aren’t always to blame. Sometimes, IT can be the issue.

Interfaces and technical responsibilities are often the gray area where the real work happens in a project.

And it’s also where the difference becomes clear between a well-structured set of specifications and one in which IT is treated as an afterthought.

Interfaces as a critical path

We know from experience that the success of a WMS project depends on how clearly this critical path is defined.

Without system maps and proper governance, it’s impossible to produce reliable costings or even get meaningful responses from vendors.

What we’d do

We’d start by mapping the entire IT ecosystem.

It would be a simple diagram, but one that covered everything, from ERP, TMS, OMS, and MES systems, to middleware, customer portals, and more.

And we’d seek to answer a key question: Who does what?

For every interface, we’d spell out:

1. The exchange format (API, EDI flow, web services, flat files)
2. The direction of the flow (inbound, outbound, two-way)
3. Where technical responsibility sits (with the vendor, the customer, or a third-party integrator)
4. We’d include this RACI matrix upfront in the specifications.

This would give everyone involved—IT, business teams, and the vendor—a clear picture of their role and the effort required.

Not forgetting the hardware

We’d also set out all hardware requirements, from the Wi-Fi network, to devices, printers, scanners, and servers.

These small details are often what create the biggest delays.

We prefer to address them early on to avoid nasty surprises later in the project.

Productive friction

We’d never cost a project without a comprehensive IT system map.

This detailed technical overview provides the foundations for any tender process.

And when interfaces are left “to be confirmed” at a later date, they end up costing more than planned.

Making IT an integral part of the specifications isn’t about adding another layer of complexity.

It’s about shoring things up from the outset.

Why this scoping exercise is a game-changer

Once the application ecosystem is clearly mapped, everything becomes easier.

Conversations are more precise.

Dependencies are visible.

And vendor responses can be compared on equal terms.

IT teams stop seeing the project as something they have to “deal with” and become full-fledged participants.

And as a vendor, we can offer the right level of support, neither underestimating what’s needed nor overestimating “just in case.”

This IT scoping exercise turns a list of flows into a fully developed integration strategy.

It’s what moves a project from theory to delivery.

Chapter 5: Good practices and overlooked risks

There always comes a point in a WMS software choice when everything seems to be aligned.

The demos are done, the decision has been made and the contract is under review.

It’s at this point when the real oversights become apparent.

These kinds of details might seem minor—until they end up stalling the entire project.

We’ve seen these same four blind spots come up time and again in the projects we’ve worked on:

1. Shadow IT
2. Legal issues
3. Contextual considerations
4. The Run phase

1. Consider shadow IT

We’d start by listing all the “home-made” applications in use.

These are tools built on the fly to speed up a process, fill a gap, or work around a constraint.

It could be an Excel script,
an internal app,
or a labeling tool.

They often work extremely well—until the person who built them leaves the company.

We’d document them all then assess which ones should be absorbed into the WMS software.

A WMS tender process is the ideal opportunity to challenge existing shadow IT practices and free the organization from unseen dependencies.

2. Plan for the legal review process

A WMS project is also a contract with a provider.

The legal sign-off process can take time—often longer than expected.

We’ve seen projects ready to launch only to be held up for three weeks because legal back-and-forth hadn’t been factored into the equation.

So we’d involve the legal team from the outset, with a clear approval timeline.

This simple precaution can prevent weeks of delays.

3. See the WMS in a real-life setting

We’d insist on seeing the software running in an environment that looks like our own.

This is a decisive step because it’s the closest you get to experiencing your future setup and assessing how smoothly it actually runs.

Ask to visit a customer in the same sector or industry, with processes that match the priorities you identified earlier on.

The same goes for the WMS demo: ask for use cases built around your core business processes and the improvements you want to see.

These context-based demos often uncover the questions that really need to be addressed—the kinds of questions no PowerPoint presentation can ever bring out into the open.

4. Meet the Run team

A WMS project doesn’t end at go-live.

In fact, the point at which the operations team takes over is when it really begins.

So before signing, we’d set up a meeting with the vendor’s Run team and ask some key questions:

1. Who handles tickets?
2. What are the response times?
3. How is long-term support organized?

These are practical questions that often get pushed aside, even though they determine the quality of the relationship over time.

Final word

We hope you’ve found this guide useful and that you can see how the method we’ve proposed can slot into your logistics strategy.

The five-step Hardis approach can be summarized as follows:

1. Timeline: 12–18 months max.
2. Priorities: 10–15 processes, with scores
3. Oversight: Initial scope perfectly defined
4. Mapping: Detailed IT requirements from the outset
5. Forward planning: Shadow IT, legal review and Run phase considered upfront

What next?

Do any of the following sound familiar?

1. Your last tender process dragged on for more than 18 months
2. You have an Excel spreadsheet with 200 unranked requirements
3. The IT section takes up two pages of an 80-page specifications document
4. You’re not sure where to start

If so, you can help yourself to a copy of our WMS template, which follows these principles.

A good set of specifications isn’t measured by its length, but by its ability to turn intent into outcomes.

And that’s exactly what we’ve been doing for the past 40 years.