TMS implementations rarely fail because of the software. More often than not, internal factors, such as organizational readiness challenges and resource constraints, are to blame.
In a recent LinkedIn Live Event, Brad Forster, Founder & CEO of JBF Consulting, and Bryan Stone, Principal of Delivery, explored five lessons shippers need to hear before they kick off a TMS implementation and the patterns they've seen derail otherwise well-funded, well-intentioned implementations.
1. Orchestration Isn't a Software Term. It's a Planning Discipline
Scope definition, rollout sequencing, stakeholder alignment, and a clear RACI — these are the things that determine whether everyone is rowing in the same direction before the project budget starts burning.
Who writes the functional specification for an integration? Is that the client, the system integrator, the vendor's professional services team? If no one answered that question in the statement of work, someone is going to answer it under pressure, and that answer almost always costs more time and money than getting it right at the start.
The compounding factor is that most implementations today are multi-party by design. Business integrators, system integrators, software vendors, internal IT, procurement, customer service, logistics, and finance are all a part of implementations. Lining up that many parties without a governance structure is a reliable way to end up in design review, debating who owns what, instead of actually designing anything.
As Bryan puts 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."
Upfront orchestration is cheap. Mid-project course correction is not.
2. Go-Live Is a Milestone, Not a Finish Line
There's a familiar arc in TMS implementations: as the go-live date approaches, pressure builds, but once the system gets turned on, everyone exhales. But going live and being operationally ready are not the same thing.
This is where the distinction between a system integrator and a business integrator matters. A system integrator focuses on whether the software is deployed. A business integrator asks whether the business is better. Both are necessary, but only one of them determines whether you get a return on the investment.
The practical implication is straightforward: establish KPIs before the project starts, not after. Identify what you're trying to improve and build a current-state baseline you can actually compare against. Without that baseline, go-live is just a date on a calendar. And as Brad notes, it's nearly impossible to go back and reconstruct it afterward: "We skip the KPIs and establishing the baseline because they're not seen as value-added in the immediate term. And then we get to the end and it's too late."
3. Designing for Reality, Not the Happy Path
Getting a TMS to a technically functional state is not particularly difficult. In pre-sales work, a system can be stood up to handle carrier selection, order consolidation, load tendering, and freight pay in a matter of days. The complexity of a real implementation lives in integration, workflow redesign, and the edge cases that accumulate at scale.
Most implementations are designed around the happy path: normal order flows, primary operational scenarios, standard use cases. These get designed, built, and tested. The edge cases — the RMA workflow, the order type that finance processes differently from the one logistics sees, the once-or-twice-a-week exception that still touches real freight volume — get deferred or overlooked. What feels like a corner case in design can represent tens of millions of dollars in freight in production.
The artifact that addresses this is what Bryan calls a requirements traceability matrix. At its core, it's a structured way of mapping each requirement to how it's actually being solved: standard system functionality, a workaround outside the system, or an acknowledged gap. That mapping tells you, before the build starts, whether the design is going to hold.
"If all of a sudden we have fifteen, twenty percent of things that fall outside of the standard," Bryan explains, "the question is, is our design good enough at that point?" That's the right question to ask in design. It's a much harder question to answer in production.
When this work gets skipped, the downstream effects are predictable: locked workflows, shadow IT, Excel-based workarounds that accumulate quietly over years as users adapt to a system that doesn't fully serve the business.
4. Integration Is a Business Problem Wearing an IT Hat
Transportation functional leads (directors, VPs, operations managers) tend to disengage when implementation conversations shift to integration. But every integration carries business logic inside it, and disengaging from that logic has consequences.
Which orders flow from the ERP into the TMS?
What date logic determines which ones are relevant for today's planning?
How do different order types get routed into different downstream workflows?
What happens when a customer service policy changes — a carrier adjusts its pickup cutoff schedule, and the business needs to update its next-day shipment rules?
If those rules are hard-coded in integration middleware that only an IT resource can touch, the business has traded agility for fragility.
Brad and Bryan worked together on exactly this kind of problem more than a decade ago, at a client in the automotive sector. The customer service team was manually keying ship-to information into order notes in the ERP, rather than selecting from a dropdown. Every time a new order hit the TMS, it failed to match an existing location and created a new one. The application was functioning exactly as designed, but an upstream procedure was never connected to the downstream integration.
"It's the integration and the lack of the business being engaged," Bryan says. "There's this view of a line of demarcation — I don't want to be a developer. And that's not what we're asking folks to do."
The design goal is to build integration logic so that business users can change business rules independently. A date window adjustment that requires an IT ticket, a queue, and a funded enhancement cycle is a configuration that should have been exposed as a parameter. That's not technically complex to build, but it has to be known as a requirement before the integration is written. And that requires the business to be in the room when the integration is being designed.
The organizational change management implication follows directly: if your customer service team's order entry procedures feed your TMS, customer service is a stakeholder in your TMS implementation. Most project plans don't include them.
5. You Can't Measure an Outcome You Never Defined
Most implementation teams can't answer a basic question: Did this investment pay off? Not because the outcomes weren't there, but because no one established a baseline before the project started. Without a current-state measurement, there's nothing to compare against.
This matters well before go-live. Measurements function as a steering mechanism throughout the project. When a steering committee faces a mid-project design decision — whether to move outbound operations from a static schedule to a dynamic model, for instance — having defined KPIs gives the team something to evaluate that decision against. The right answer may be technically challenging to implement, but if it's the decision that unlocks the ROI case for the entire project, that context belongs in the room. Without defined measurements, design trade-offs get made without knowing which ones quietly undermine the business case.
There's also a direct connection to adoption. End users who understand the metrics their behaviors are driving — carrier compliance rates, consolidation savings, freight pay accuracy — develop a clearer sense of why the new system and new workflows matter. That connection between individual action and measurable outcome is what creates durable adoption, not training materials and go-live communications. "It creates this reinforcing flywheel," Brad notes, "but we can't do that unless we have measurements to help them and tell them why these things are impactful."
Implementations with clearly defined KPIs, a current-state baseline, and a defined methodology for measuring improvement at the end are genuinely rare. That's worth changing, and it's far easier to do at the start of a project than to reconstruct afterward.
The Throughline
These five lessons are symptoms of a single underlying dynamic: TMS implementations that are treated as IT deployments rather than business transformations.
The enterprise clients that get the most out of their TMS investments are the ones where business leaders own the outcome — where the director of transportation, the VP of supply chain, the operations leadership team are driving design decisions, engaged in integration conversations, and accountable for the KPIs on the other side of go-live.
"The most successful implementations are business-led and IT-enabled," Brad puts it plainly. "IT-led, business riding the coattails of an IT deployment — you can never expect to get the outcomes you're after."
If you're in the planning phase, mid-implementation, or working through a system that hasn't delivered what you expected, these are the right questions to be asking.
If you're evaluating TMS or if you've already implemented something that isn't working the way you expected, contact us today. Whether it's identifying requirements, diagnosing a go-live gap, or defining your strategy, we’re here to help.
About the Author
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.
FAQs
TMS implementations most commonly fail because of organizational readiness gaps, not software defects. The leading causes include insufficient upfront orchestration across multi-party project teams, undefined governance structures and RACI accountability, integration logic that the business doesn't own or understand, and the absence of measurable KPIs before the project begins. When business leaders treat a TMS implementation as an IT deployment rather than a business transformation, the result is a technically functional system that doesn't deliver operational or financial outcomes.
The Go-Live Gap is the distance between system deployment and actual business readiness. Going live means the software is turned on. Being operationally ready means the business can measure improvement, users have adopted new workflows, and the integration logic reflects real business rules. Organizations that track go-live as the finish line typically can't answer whether the implementation paid off, because they never established a current-state baseline to compare against.
Every integration carries embedded business logic — which orders flow into the TMS, what date windows determine planning relevance, how different order types route to different workflows, and what happens when carrier policies or customer service procedures change. When that logic is hard-coded by IT without business input, the result is a system where updating a business rule requires an IT ticket, a funded enhancement cycle, and a queue. Business stakeholders need to be present during integration design so that operational parameters can be exposed as configurable values rather than buried in middleware.
Every integration carries embedded business logic — which orders flow into the TMS, what date windows determine planning relevance, how different order types route to different workflows, and what happens when carrier policies or customer service procedures change. When that logic is hard-coded by IT without business input, the result is a system where updating a business rule requires an IT ticket, a funded enhancement cycle, and a queue. Business stakeholders need to be present during integration design so that operational parameters can be exposed as configurable values rather than buried in middleware.
A requirements traceability matrix is a structured document that maps each project requirement to how it will be addressed: through standard system functionality, a defined workaround, or an acknowledged gap. In TMS implementations, it provides a pre-build view of whether the design is sufficient to handle the full range of operational scenarios — including edge cases that represent real freight volume even if they occur infrequently. When a high percentage of requirements fall outside standard functionality, the matrix surfaces that risk before the build begins, rather than after production workflows are locked.
