Originally published by JBF Consulting. Read the original here.
When a TMS implementation fails, the software is rarely the reason. Organizational readiness and resource constraints usually are.
Recently, Brad Forester, Founder & CEO of JBF Consulting, and Bryan Stone, Principal of Delivery, sat down for a LinkedIn Live event to talk through the patterns they’ve seen derail well-funded, well-intentioned rollouts and the five things shippers should hear before they ever kick one off.
Watch their full conversation, or continue reading for the key takeaways.
1. Orchestration Isn’t a Software Term. It’s a Planning Discipline
Before a project’s budget starts burning, a few things need to be nailed down, such as who owns which piece of scope, in what sequence the rollout happens, which stakeholders sign off on what, and who’s accountable when something goes sideways (the RACI, in other words).
Take something as basic as the functional spec for an integration. Does the client write it? The system integrator? The vendor’s professional services team? If the statement of work is silent on that, the question gets answered later, under pressure, at a much higher price than it would have cost to settle up front.
Part of what makes this hard is scale. A modern TMS implementation typically pulls in business integrators, system integrators, software vendors, internal IT, procurement, customer service, logistics, and finance, all at once. Put that many parties in a room with no governance structure, and design review stops being about design — it instead becomes a running argument about who owns what.
As Bryan out it, “The question is when you do it, do you want to be doing it on the fly during build, during test, during hypercare? That’s a very difficult and costly time to have that discussion.”
Orchestration is cheap when it happens early. It gets expensive fast once the project is already moving.
2. Go-Live Is a Milestone, Not a Finish Line
Every TMS rollout seems to follow the same emotional arc: tension climbs as the go-live date approaches, then everyone exhales the moment the system flips on. The problem is that “live” and “ready” aren’t the same state.
That’s where the distinction between a system integrator and a business integrator becomes important. A system integrator’s job ends at “is the software deployed correctly.” A business integrator keeps going and asks “is the business actually performing better.” You need both roles, but only the second one tells you whether the project paid for itself.
Which is why KPIs and a current-state baseline belong at the start of the project, not the end. Decide what you’re trying to move, and measure where things stand before you touch anything because once go-live happens, that baseline is gone, and there’s no reconstructing it after the fact.
3. Designing for Reality, Not the Happy Path
Standing up a TMS to handle carrier selection, order consolidation, load tendering, and freight pay is, frankly, not that hard — pre-sales teams do it in days. Real implementation difficulty shows up somewhere else: in the integration layer, in workflow redesign, and in however many edge cases a business has accumulated over the years.
Design effort naturally gravitates toward the normal cases, such as the standard order flow, the primary scenario, the thing that happens a thousand times a day. That gets built and tested thoroughly. What tends to slide is everything unusual. The RMA process, an order type finance treats one way and logistics treats another, the exception that only surfaces once or twice a week — none of that looks urgent in a design workshop. In production, though, that edge case can turn out to represent tens of millions of dollars in freight.
That’s where a requirements traceability matrix comes into play. For every requirement, it documents exactly how the system will handle it. Built before a single line of code is written, this document is essentially a stress test for the design.\
Skip the matrix, and you get the usual downstream symptoms a few years later: workflows nobody can touch, shadow IT, and spreadsheets that quietly patch over whatever the system never actually solved.
4. Integration Is a Business Problem Wearing an IT Hat
Watch what happens in a project meeting the moment the conversation turns to integration. Transportation leads (directors, VPs, ops managers) start checking out. That’s a costly habit, because integration logic is business logic, just written in a technical language most of them don’t speak.
Consider what’s actually being decided inside an integration:
- Which orders move from the ERP into the TMS
- What date logic determines which orders matter for today’s planning
- How different order types get routed to different downstream workflows
- What happens when a carrier changes its pickup cutoff and next-day shipment rules need to update
Bury those decisions in middleware that only IT can touch, and the business has quietly handed over control of its own rules in exchange for a working system.
Brad and Bryan ran into a version of this more than a decade ago at an automotive client. Customer service was typing ship-to information into free-text order notes instead of picking a location from a dropdown. Every time a new order landed in the TMS, it failed to match anything on file and spawned a duplicate location. The software wasn’t broken. The break was upstream, where a manual habit had never been wired into the integration depending on it.
The fix isn’t asking business users to code. It’s designing integrations so a date-window change, for example, is a parameter someone in the business can update directly, not a ticket that sits in an IT queue waiting for a funded enhancement cycle. That only works if the requirement gets flagged before the integration is built, which means someone from the business has to be in the design conversation, not just the go-live announcement.
5. You Can’t Measure an Outcome You Never Defined
Ask most implementation teams, months after go-live, whether the investment paid off, and you’ll get a shrug, not because it didn’t, but because nobody captured what “before” looked like.
This isn’t just a reporting gap; it shapes decisions made in the middle of the project. Picture a steering committee weighing whether to move outbound operations from a static schedule to a dynamic model. With defined KPIs, that’s a decision grounded in what the project needs to achieve. Without them, it’s a coin flip dressed up as strategy, and trade-offs like that can quietly erode the business case without anyone noticing until much later.
There’s an adoption dimension too. Show end users the metrics tied to their own actions — carrier compliance, consolidation savings, freight pay accuracy — and they start to understand why a workflow changed, not just that it changed. That understanding drives adoption in a way no training deck ever will.
The Throughline
Pull these five lessons apart and they all point back to one root cause: treating a TMS rollout as an IT deployment instead of a business transformation.
The clients getting the most out of their TMS investment all ensure the director of transportation, the VP of supply chain, the operations leadership team aren’t just spectators. They’re making design calls, sitting in on integration discussions, and still on the hook for the KPIs long after go-live.
“The most successful implementations are business-led and IT-enabled. IT-led, business riding the coattails of an IT deployment — you can never expect to get the outcomes you’re after,” Brad explained.
If you’re evaluating a TMS, or you’re already live on one that isn’t performing the way you expected, contact JBF Consulting. Requirements, a go-live gap diagnosis, or overall strategy — whatever the starting point, they can help.
About the Authors
Brad Forester is the Founder and Managing Partner of JBF Consulting, bringing more than 25 years of leadership experience in transportation strategy, logistics technology, and supply chain transformation. A recognized industry expert, Brad has advised Fortune 500 companies and high-growth brands on complex global transportation initiatives, from network design and technology selection to implementation and value realization. His background spans senior roles in consulting, software, and shipper operations, giving him a uniquely balanced perspective on strategy and execution. Brad is a frequent industry speaker and thought leader on TMS, visibility, and logistics innovation.
Bryan Stone is the Principal for Client Delivery at JBF, leading the Delivery Team to ensure the successful design and implementation of client solutions and guarantee exceptional value. With over 20 years of experience, Bryan is a recognized expert in logistics and technology transformation, specializing in the management of large-scale system projects, including Blue Yonder and JDA transportation system implementations, migrations, and redesigns for global firms across retail, manufacturing, and consumer goods. His strength lies in his collaborative leadership and structured project management, which consistently helps clients achieve significant improvements in efficiency, quality, and operational performance.
About JBF Consulting
JBF Consulting is a leading logistics strategy advisory and technology integration firm that partners with shippers to transform their logistics and supply chain execution operations. We empower clients to achieve operational efficiency and scalable, sustainable value through strategy development, roadmap orchestration, unbiased technology selection, expert implementation, data-driven insights, and ongoing managed services. For over two decades, our client-centric approach and partnerships with best-of-breed solution providers have ensured that every strategy and solution we deliver drives measurable impact, long-term success, and customer satisfaction. For more information, visit us at www.jbf-consulting.com.