What are the warning signs my WMS implementation is in trouble?

The warning signs visible from inside a buyer-only frame are the obvious ones: timeline slipping, key client-side staff disengaging, integration tests failing, training not taking. Those are real. They're also late signals — by the time they're visible, the implementation is already in trouble and the question is recovery, not prevention.

The earlier warning signs are vendor-side patterns the buyer-frame doesn't recognize as warnings.

Scope language that drifts. Conversations that started with specific deliverables tied to specific dates begin to use softer phrasing. "We'll figure out the configuration approach in discovery" becomes "we'll address that in the next phase" becomes "that's something we'll look at post-go-live." Each substitution is small. The pattern is a vendor moving commitments out of the contract scope into a future where they can be repriced or deprioritized.

Vendor explanations that shift over time. The reason a feature wasn't ready for the milestone changes between conversations. First it was a dependency on another team. Then it was a configuration question. Then it was a roadmap item that got moved. The shifting isn't lying, exactly — it's the visible surface of a vendor team realigning what's actually deliverable against what was sold, and using whichever explanation is least costly in the current conversation.

Solution architects who appeared in selection but aren't in implementation. The senior technical resource who joined a key demo, demonstrated a complex configuration, and made the system feel achievable — and who is now unavailable, on another project, "supporting where needed" without specific allocation. This was visible in selection if the founder knew to ask whether that resource was committed to the implementation or was a sales asset. From the buyer's frame, the resource appeared. From the sell side, the resource was demoing because that's what solution architects do. Neither side lied; the buyer's frame just didn't surface the question that would have clarified the allocation.

Customization scope that keeps appearing. The vendor said most of what the operation needed was configurable out of the box. In implementation, capabilities that were demoed as standard are being scoped with services hours attached — "we can absolutely support that, we'll just need a few weeks of configuration work," said about features that were positioned as ready-to-use during selection. The demoed capabilities are real, but the path from demo to production is going through a services line item the contract didn't fully account for.

These signs share a structure: each is a pattern that was visible during selection — in the demo, in the contract language, in how the vendor staffed the engagement — but didn't read as a warning because the buyer-frame doesn't recognize sell-side patterns as warnings. By the time they're visible in implementation, the warning has converted into a consequence. Catching them at selection requires a frame the buyer doesn't natively have.