Question 1

How do I evaluate a WMS for my 3PL?

Accepted Answer

Most founders are taught a version of this: list your requirements, demo a few vendors, check references, decide. The steps aren't wrong. But the inputs they depend on are.Requirements lists reflect what you believe your operation needs, filtered through proximity blindness to your own floor. The workarounds, exceptions, and process gaps that actually define how the operation runs have become invisible. You stopped seeing them years ago. Vendor demos respond to the mental model you describe, not the floor reality where fit problems live. References are vendor-provided, vendor-prepared, vendor-incentivized. The unhappy clients don't show up.Every input that feels like due diligence was shaped by someone with a stake in the outcome.A real evaluation has to fix the inputs before the process begins. That means a documented operational baseline that proximity didn't filter — what's actually happening on the floor, not what you'd describe in a meeting. A shortlist filtered by operational fit, not by which vendors were visible and recommended. Vendor evaluation run through a frame that exposes what a buyer-only frame structurally misses, because vendors are designed to be evaluated by buyers.More effort doesn't close those gaps. More research, longer demos, more reference calls — they generate more volume of the same compromised inputs. The conventional process produces a selection built on a foundation you can't see clearly from inside it. The way to evaluate a WMS well is to recognize that, and fix what the process depends on before any vendor conversation begins.

Question 2

Should I hire a WMS selection consultant?

Accepted Answer

Maybe. The harder question is which one, and the answer isn't about methodology or industry tenure.Most WMS selection consultants share the same structural problem you have running the process alone: their inputs are compromised by their own incentives, and you usually can't see it.Generalist consultancies that do WMS selection — enVista, Fortna, St. Onge, Armstrong — typically also do implementation work. The same firm helping select a system earns revenue if a particular system gets selected. Some take referral fees from vendors. Some have formal partnerships. Some have informal relationships built across years of placing clients with specific products. None of these are wrong on their face. They're normal business arrangements. But they create the same conflicted-input problem the solo evaluation has — the recommendation comes from someone with a stake in the outcome, even when the consultant is acting in good faith.That's the structural condition of the WMS market. Most actors with relevant expertise have a reason to prefer a particular outcome. Peers carry their own operational context. Vendors are designed to be evaluated by buyers. Implementers have relationships that create the same revenue conflict. The founder running it solo and the founder who hires a consultant with vendor or implementation revenue end up in similar positions: a recommendation whose reasoning isn't fully visible and isn't fully unconflicted.The right consultant is one whose revenue model doesn't create that conflict. No vendor relationships, no referral fees, no implementation revenue. That structural condition is what makes the recommendation auditable. Ask the consultant directly how they earn revenue and whether any of it is contingent on which system gets selected. The answer is the positioning.

Question 3

What's the WMS selection process?

Accepted Answer

If you search for this, you'll find a sequence: gather requirements, build a shortlist, run demos, check references, negotiate, contract. The sequence isn't wrong. It's downstream of the harder problem.The selection process most founders run is structurally compromised before the first vendor conversation. Requirements documents reflect what you believe your operation needs, filtered through proximity blindness — the workarounds and exceptions that define how things actually run have become invisible through normalization. Shortlists are shaped by which vendors were visible and recommended, not by which vendors fit. Demos respond to the mental model you describe, not the floor reality. Every input the process depends on was shaped before the process began.A useful selection process has two phases the conventional version skips.First, an operational baseline that captures what proximity has made invisible. Built before any requirements list gets written. Second, a fit-filtered shortlist built from a vantage point that reflects how vendors actually perform in implementation, not how they present in demos.Both phases happen before the first vendor demo. They aren't preparation steps. They're the inputs that determine whether the rest of the process produces a defensible decision or a documented version of an availability-biased one.Founders who skip those phases and go straight to vendor conversations are running a process that feels rigorous because effort goes in. The output is a shortlist filtered by visibility and a vendor evaluation run through a buyer-only frame. Both are predictable failures of a structurally compromised process. Not failures of effort.

Question 4

How do I avoid choosing the wrong WMS?

Accepted Answer

Most founders try to solve this by doing more of what they're already doing. More research, longer demos, more reference calls, tighter requirements, longer evaluation timelines. The reasoning is intuitive: if the risk of choosing wrong is high, more diligence should reduce it.It doesn't.More diligence generates more volume of the same compromised inputs. A longer demo sequence still tests vendors through a buyer-only frame. A larger shortlist still reflects availability bias if the filter that produced it was unchanged. A more detailed requirements document still reflects your normalized view of an operation you're too close to see clearly. The structural gaps that produce wrong selections — proximity blindness, availability bias, buyer-only frame — aren't closed by working harder inside the same process. They're produced by it.Avoiding the wrong WMS requires fixing the inputs the selection depends on, before the process begins. A documented operational baseline that captures what proximity has made invisible. A shortlist filtered by operational fit, built from a vantage point that reflects how vendors actually perform in implementation. A vendor evaluation run through a frame that knows what selection looks like from the sell side and the implementation side, not just the buy side.Without those three inputs, the selection is built on ground you can't see clearly. Founders sometimes get lucky. More often they select against an inaccurate operational picture, sign with a vendor whose fit problems only show up in implementation, or miss contract signals that predict downstream risk. Luck is not a selection strategy for a multi-year, high-switching-cost commitment.

Question 5

What's the biggest mistake 3PLs make when selecting a WMS?

Accepted Answer

Running the process solo. Not because founders aren't capable, but because the solo process is structurally compromised in a way effort can't fix.Three structural gaps exist simultaneously in any solo WMS evaluation.A proximity gap. You can't observe your own blind spots. The workarounds and exceptions that define how the operation runs have become invisible through normalization. You stopped seeing them years ago.An availability bias gap. The shortlist most founders bring into vendor conversations was shaped by which vendors were visible and recommended, not by which vendors fit the operation.A frame gap. Every question you ask in a vendor evaluation comes from a buyer's frame of reference, because that's the only frame you've ever occupied. Vendors are specifically designed to be evaluated by buyers.None of these are knowledge gaps. None are closed by more research, longer demos, or tighter requirements. They're structural conditions of running a selection from inside the operation, with no access to the sell side, the implementation side, or a vantage point that compounds across engagements. Founder diligence doesn't close them. It produces more volume of the same compromised inputs.The mistake isn't that founders make poor decisions inside the process. It's that the process produces a selection built on three foundations you can't see clearly from inside it. That's a different kind of error than the one founders are usually told to watch for. It can't be corrected by trying harder. It can only be corrected by fixing the inputs before the process begins.

Question 6

Why are my warehouse workarounds growing?

Accepted Answer

Workarounds grow because the operation is doing things the system doesn't support, and someone has to bridge the gap. A picker uses a workflow that isn't in the WMS. A supervisor keeps a spreadsheet the system can't produce. A receiving process runs on a verbal handoff because the documented flow doesn't match what actually happens on the dock.That's not unusual. What's unusual is being able to see it clearly from inside the operation.Most of the workarounds in a 3PL accumulate slowly, get normalized, and stop registering as workarounds. They become how the work gets done. The picker's habit, the supervisor's spreadsheet, the verbal handoff — they look like the operation rather than gaps in it. Proximity blindness is the reason. Founders are too close to their own floor to see what they've absorbed. The workarounds didn't disappear. They became invisible.That's why workarounds growing is rarely the question that matters. The question that matters is which ones you no longer notice — the ones that have become part of your operation's DNA, the ones that will quietly disqualify vendors during selection because no one ever surfaced them as requirements. When you run a WMS evaluation against the mental model of your operation, you evaluate against a picture that excludes the workarounds you've stopped seeing. The system gets selected. The workarounds resurface in implementation. The fit gap that was structural the whole time becomes visible only after contracts are signed.The visible workarounds are the ones you can still negotiate with. The invisible ones pick the wrong WMS for you.

Question 7

How do I know if my 3PL has outgrown its current system?

Accepted Answer

From inside the operation, you typically can't — at least not with the precision the question implies.The question assumes you can run the diagnostic yourself. Most founders can name a few symptoms — workarounds growing, throughput stalling, training getting longer, customer complaints rising. Symptoms don't tell you whether the system has been outgrown or whether something else is producing the same surface signals. A throughput problem can be a system limit, a process design issue, a labor model issue, or a data quality issue. The same complaint can have four different root causes, and you're the person least positioned to tell them apart — because every interpretation gets filtered through the same normalized view that produced the operation's current shape in the first place.This isn't a knowledge gap. It's a proximity gap. The workarounds, exceptions, and process gaps that would tell you whether the system is the constraint have become invisible through normalization. You stopped seeing them years ago. The diagnostic question — is the system the bottleneck, or is the operation working around the system in ways I no longer notice? — requires an outside set of eyes that hasn't absorbed what you've absorbed.Founders who answer this solo usually default to one of two places: yes, because the symptoms are loud, or no, because change feels expensive. Neither answer is grounded in an actual diagnostic. Both are grounded in a view of the operation you can't audit from inside.The founders who get this right stop trying to answer the question from where they're standing.

Question 8

How do I write WMS requirements?

Accepted Answer

Most guides on this start with a template: list your workflows, capture exception handling, document integration needs, define reporting requirements. The template isn't wrong. The problem is what gets put into it.A requirements document captures what the founder believes the operation needs. The capture itself feels rigorous — you're writing it down, structuring it, reviewing it with the team. Every input came from the same source, though: your mental model of how the operation runs, plus what your team can articulate when asked directly. Both are filtered through proximity blindness. The workarounds nobody questions anymore don't show up. The exceptions that have become routine don't get flagged as exceptions. The process gaps people have built habits around don't register as gaps. The document captures the operation as you describe it, not as it actually runs.There's a deeper problem underneath that one. Even when a requirements document is captured carefully, the format itself flattens what should be sharply weighted. Workflows, exception handling, integrations, reporting — all of it goes in, all of it gets reviewed, all of it shapes vendor evaluation. Every captured requirement reads as roughly equivalent input. What actually predicts vendor fit is a small set of operationally-specific levers — usually fewer than a dozen — that define how this operation runs and that most vendors will struggle to support in at least some respect. These aren't the longest items in a requirements doc. They're often not the most obvious ones. They're the ones that, if a system can't handle them well, no amount of feature breadth elsewhere compensates.Surface them and you have a real filter. Bury them in a hundred-item requirements catalog and you have a document vendors can respond to favorably while still being wrong for the operation. Writing better requirements isn't the move. Writing the right artifact is — and the right artifact is not a requirements document.

Question 9

Should I use an RFP for WMS selection?

Accepted Answer

Probably not. Not because RFPs are badly designed, but because they answer a less important question than founders typically realize.An RFP is a fair-comparison instrument. It asks every shortlisted vendor the same structured questions, captures their written responses, and produces a comparable record. The format assumes vendor responses to a written criteria list are useful signal for fit. They're not — at least not for the question that actually matters. Vendors are trained to respond to RFPs. The capabilities they describe are framed by their own product positioning. The gaps they don't volunteer are the ones that won't appear in the response. The format produces thorough, comparable, defensible documentation of vendor self-presentation. What it doesn't produce is a defensible answer to whether a given vendor can actually support this specific operation.The question that determines fit isn't can the vendor describe how they handle X. It's can the vendor support the small set of operationally-specific levers that define how this operation runs — including the ones the founder hasn't consciously surfaced as requirements. That question is answered through firsthand knowledge of how vendors perform in implementation rather than how they respond in writing, applied against operational realities someone has actually documented from observation. Neither input is what the RFP is built to produce.The RFP also persists because it produces something everyone in the process can point to — a structured artifact that documents diligence. That's a real function. It's just not the same function as identifying the right vendor. Founders who run an RFP and end up disappointed often blame the responses. The responses aren't the problem. The format produced exactly what it was designed to produce. The founder was hoping it would produce something else: a real signal about fit. That signal isn't what an RFP returns.If a vendor evaluation is going to predict implementation outcomes, the inputs have to be different in kind from RFP responses. The RFP automates a comparison whose underlying inputs were never going to surface what mattered.

Question 10

Should I customize my WMS or change my processes?

Accepted Answer

If you're asking this after vendor selection, the answer is harder than it should be — and the reason has less to do with the question than with when it's getting asked.Customization tolerance is an operational lever. How much your processes can flex to match a system, how much a system needs to flex to match your processes, where the line sits between the two — these are inputs to vendor fit, not outputs of it. They determine which vendors can support your operation and which ones will require expensive customization or process compromise to make the relationship work. Settled in advance, they shape the shortlist. Settled after the fact, they become a forced choice between two bad options: customize the system you bought, which is expensive, fragile, and often vendor-dependent — or restructure operations to fit a system that wasn't selected for fit, which is operationally disruptive and sometimes impossible without losing what made the operation work in the first place.The reason this question gets asked too late isn't carelessness. It's that customization tolerance is exactly the kind of operational lever that's hard to see clearly from inside the operation. The processes that can flex and the ones that can't — and why — are bound up in workarounds, exceptions, and operational habits proximity blindness has made invisible. When you run a solo evaluation, you typically don't surface customization tolerance as a vendor-selection criterion because you don't have a documented picture of what your operation can and can't bend on. The question you should be answering at selection — which processes are load-bearing and which are habits I could change — gets deferred to implementation, where the answer is no longer free.By the time the customize-or-change question is being asked, the choice is between bad options and worse ones. The path to better choices was upstream.

Question 11

What questions should I ask a WMS vendor in a demo?

Accepted Answer

This is the question every WMS selection guide answers. There are good lists out there. The problem isn't the lists. It's where the questions come from.Every question a founder generates for a vendor demo originates from inside a buyer-only frame of reference. That's not a failure of preparation — it's the only frame a buyer has ever occupied. The frame determines which questions feel important, which vendor answers feel satisfactory, and which risks don't register as risks because the buyer doesn't know to look for them. Vendors are specifically designed to be evaluated by buyers. The questions that come naturally from a buyer's seat are the questions vendor demos are built to satisfy.The questions that actually expose fit problems come from the other side of the table. Where will this system require workflow customization that your support team will quietly bill against later? Which capabilities you just demoed are full product and which are roadmap? When this implementation gets complicated, who on your bench is actually assigned, and how many concurrent projects are they on? These aren't smarter versions of buyer questions. They come from having watched implementations go sideways from inside the vendor and from inside the implementation team — knowing which polished demo answers predict which downstream problems.A founder running solo can be handed a list of those questions and ask them word-for-word. The vendor still answers from inside a frame the buyer doesn't share. The follow-up questions that would catch the deflection don't get generated, because the founder doesn't have the pattern recognition that produces them. The frame itself is the gap. A better list of opening questions doesn't close it.

Question 12

What red flags should I watch for in a WMS demo?

Accepted Answer

The red flags most founders watch for are the ones visible from the buyer's seat: a vendor who can't answer a specific question, a feature that crashes mid-demo, a sales rep who doesn't know the product. Those are real signals. They're also the obvious ones — and obvious flags get caught by every founder, which means they rarely sort the good vendors from the bad ones in any decision-relevant way.The flags that actually predict implementation problems are visible from the sell side, not the buy side.A demo environment that walks through scenarios in a specific order, never deviating when asked to. Configuration changes that get demoed in a sandbox the vendor controls, never in a fresh environment. "We can customize that" as the answer to questions about gaps — every time, with no scope or cost framing attached. Rep handoffs to a solution architect who joins the demo, demos one piece flawlessly, then disappears for the rest of the engagement. None of these are visible-from-the-buyer-side problems. They look like normal, even polished, sales behavior — because they are normal sales behavior, calibrated to satisfy what buyers know to look for.These patterns don't read as red flags from inside the buyer-only frame because the buyer has never sat on the other side. They read as flags to people who have watched what each pattern predicts in implementation: which deflection language signals a feature gap that will surface as a six-figure customization scope, which solution architect appearances predict an implementation team that won't include them, which sandbox demos paper over configuration limits the buyer would have caught in a fresh environment.A founder watching for the wrong red flags in a polished demo will conclude the vendor passed. That conclusion is the predictable output of a process where the diligence is real but the frame is wrong.

Question 13

What should be in a WMS implementation contract?

Accepted Answer

The clauses most likely to predict downstream problems don't read as problematic from inside the buyer-only frame. The signal isn't in what looks aggressive on the page — it's in what specific contract language predicts about how a vendor will behave when implementation gets hard, and that signal is sell-side knowledge.The contract patterns that predict trouble usually look reasonable.Vague scope language that defers definition to "discovery" or "kickoff" — the contract doesn't commit because the vendor knows the actual scope will exceed what the buyer would sign for upfront. Customization-out-of-scope provisions that exclude the workflow modifications the vendor implied during the demo would be straightforward to support. Termination clauses that allow the vendor to walk if the project gets complicated but require the buyer to pay through completion if they want to walk for the same reason.None of these are unusual. They appear in most WMS implementation contracts in some form. The signal isn't whether they're present — it's how they're scoped, what they're paired with, and what they predict about how the vendor will behave when the project gets hard. That signal is sell-side pattern recognition. It comes from having structured those contracts from the inside, having watched how each clause gets invoked when a project goes sideways, knowing which vendors use which clause patterns and what each pattern predicts about post-signature behavior.A founder reviewing the contract from the buyer's seat sees standard commercial language. The patterns that would change the negotiation aren't visible from where they're sitting. The frame is the gap, and contract review run inside it produces a signed agreement that looked fine until the project got complicated.

Question 14

How do I know if a WMS vendor is being honest in a demo?

Accepted Answer

The question assumes the answer is detectable from where you're sitting. Mostly, it isn't. But not because vendors are lying.Vendor demos are rarely dishonest in the way the question implies. Outright misrepresentation is unusual; it creates downstream legal exposure vendors don't want. What's near-universal is strategic omission — and strategic omission isn't visible as dishonesty from inside the buyer-only frame, because it doesn't look like anything. It's the absence of information the buyer didn't know to ask about. The roadmap feature demoed as if it shipped. The configuration that exists but requires services-team work to enable, framed as "out of the box." The integration that works in principle but breaks in the specific ERP version you actually run, disclosed only if you ask the right follow-up. The customer base described as "3PLs like yours" without naming that the comparable accounts are operationally different from yours in ways that matter.None of these are lies. They're answers to the questions you asked, framed in ways that satisfy your frame and avoid surfacing what would complicate the sale. The question that would have caught the omission isn't a smarter version of the question you asked — it's a question that comes from having watched how vendors prepare for these moments, knowing which polished phrasings paper over which kinds of gaps.That pattern recognition isn't accessible through more diligent listening or harder questions. It comes from having sat on the other side of the table — having prepped vendor reps for demos, watched which buyer questions trigger which trained responses, seen which strategic omissions surface as implementation problems six months later. A buyer doing their best to listen carefully is still listening from inside a frame that vendor preparation is calibrated to satisfy.The honesty question is the wrong question. The right one is: what is this vendor not telling me, and how would I know? From inside the buyer's frame, you usually don't.

Question 15

What's the difference between WMS implementation partners and the vendor's own implementation team?

Accepted Answer

Most answers to this question read as a pros-and-cons list: partners offer X, vendor teams offer Y, here's how to choose. That framing skips what actually matters and is also the framing the buyer-only frame produces by default.The real difference is incentive structure, and most buyers don't think about incentive structure at selection time.Implementation partners and software vendors run different revenue models, and those models drive different post-signature behaviors. Implementation partners typically earn revenue while implementation continues — their economics are tied to time-on-project and client adoption. They're incentivized to keep the implementation moving, surface scope expansion, and stay engaged through the transition into steady-state operations. Software vendors earn revenue primarily through subscription access — the contract is the revenue event, and adoption matters operationally but is secondary to the recurring revenue already locked in at signature. Their implementation teams are structurally pulled toward closing projects and freeing capacity for the next deal, not toward extending engagement to maximize how deeply the system gets used.Neither model is bad. They're both rational responses to how the businesses are built. But they predict different behaviors after go-live, and the right post-selection partner depends on what the buyer needs in that period. A founder running an operation with significant change-management complexity, where adoption will require sustained partner involvement after the system goes live, will get something fundamentally different from an implementation partner than from a vendor team that's structurally pulled toward closing the project and moving on. A founder running a cleaner deployment may be better served by the vendor's own team's product depth and direct accountability.This is one of the things that should be considered at selection — and rarely is. The reason it gets skipped is that revenue-model and incentive-structure analysis isn't natively visible from the buyer's seat. Buyers are evaluating capabilities and price. The economic structures that determine how each option will behave when the project gets complicated are sell-side knowledge, not buyer-side knowledge. Settled in advance, this question shapes which partner type belongs in the contract. Settled after the fact, it becomes a renegotiation the buyer didn't plan for.

Question 16

Why do WMS implementations fail?

Accepted Answer

Most explanations of WMS implementation failure focus on the implementation phase: change management was weak, the project plan slipped, the integration was harder than expected, training didn't take. Those things are real. They're also rarely the cause.Most "implementation failures" are selection failures showing up downstream.By the time an implementation is in trouble, three things have usually been true for months. The system was selected against an inaccurate picture of how the operation actually runs — a picture filtered through proximity blindness, where the workarounds and exceptions that define daily operations had become invisible to the founder before the requirements conversation ever started. The shortlist was shaped by which vendors were visible and recommended rather than which vendors fit — availability bias dressed up as due diligence. And the vendor evaluation was run through a buyer-only frame, which is the only frame vendors are designed to be evaluated by, which means the questions that would have surfaced fit problems weren't asked.None of those gaps are visible during selection. They become visible during implementation, when the operation that wasn't fully documented meets a system that was selected for the operation's described shape rather than its actual one. Workflows the founder didn't surface as requirements run into system limits. Customizations the vendor implied would be straightforward turn out to require services-team work the contract didn't price. Edge cases nobody flagged become the cases that break first. The implementation team is now solving a fit problem in real time, after contracts are signed, when the cost of changing course is highest.The pattern is consistent enough that the conventional explanation gets the causation backwards. Implementation isn't where the failure happens. It's where the selection failure becomes legible.

Question 17

What WMS selection mistakes lead to failed implementations?

Accepted Answer

If you're mid-evaluation, the patterns that produce failed implementations are likely visible in your current process right now. Three are typical.The first: your requirements document captures what you and your team can articulate when asked directly. The workarounds nobody questions anymore, the exceptions that have become routine, the process gaps people have built habits around — those are the things most likely to break under a new system, and they're the things least likely to show up in a requirements doc you wrote. Proximity blindness is operating on you in real time. The vendors responding to your requirements are responding to the operation as you described it, not as it actually runs.The second: your shortlist is shaped more than you realize by which vendors were visible and recommended. Availability bias is the dominant filter when founders haven't done documented operational work first. The vendors you're demoing got there because peers mentioned them, because they showed up in search, because they reached out at the right moment. Those filters predict visibility, not fit. The fit-relevant question — which of these vendors can actually support how this specific operation runs — gets answered by elimination during demos rather than by selection upfront, which is the opposite of what produces a defensible decision.The third: the questions you're asking in demos feel rigorous, and they are. They also come from inside the same frame vendors are designed to satisfy. The polished demo answers feel reassuring because they're calibrated to feel reassuring. The follow-up questions that would catch strategic omission come from the side of the table the buyer has never sat on.These aren't future risks. They're the conditions of your evaluation right now. The implementations that fail twelve months from now are the ones where these patterns ran unchallenged through selection.

Question 18

How do I diagnose a failed WMS implementation?

Accepted Answer

The diagnostic question most founders ask after a failed implementation is what the implementation team did wrong. That question rarely produces a useful answer. Implementation teams don't usually fail the way the question implies — they fail to recover from a fit problem that was already locked in before they started.Most WMS implementations that fail trace back to one of three structural causes, and all three sit in selection rather than implementation.The first is that the wrong system was selected. Not in the sense of a poor product — in the sense of a system that fit the operation as it was described in selection but not the operation as it actually runs. The workarounds, edge cases, and process realities that make this specific operation work weren't surfaced as requirements because proximity blindness had made them invisible to the founder before the evaluation began. Implementation became the moment when the un-surfaced operation met a system selected without it.The second is that the operational picture the system was selected against was inaccurate — which is distinct from picking the wrong system, because the right system selected against an inaccurate picture fails the same way. What broke wasn't the product — it was the assumptions about throughput, exception rates, integration realities, and process maturity that sat underneath the selection. Founders don't see this clearly during selection because every input — requirements, demo scenarios, reference checks — runs through the same description-based picture.The third is that the vendor over-promised on capabilities that don't exist as demoed, or exist only with services-team work the contract didn't price. Strategic omission during demos is near-universal in the WMS market — not as dishonesty but as the absence of information the buyer didn't know to ask about. Roadmap features framed as if shipped. Configurations that work in a vendor-controlled sandbox but break in a fresh environment. Integrations that work in principle but fail in the specific ERP version you actually run. From inside a buyer-only frame, those gaps look like the system performing as demoed. From the inside of the vendor preparation that produced the demo, they're the predictable result of a sales motion calibrated to satisfy what buyers know to ask about.The implementation team inherited the consequence. Whatever they did or didn't do, they were solving for a fit problem the selection process couldn't see — at the point in the project where changing course costs the most. The diagnostic question that produces a useful answer isn't what implementation got wrong. It's which selection-stage gap is now visible in the failure.

Question 19

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

Accepted Answer

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.

Question 20

How do I avoid a WMS implementation disaster?

Accepted Answer

Most advice on this question lives in implementation territory — change management plans, executive sponsorship, training rigor, integration testing protocols, go-live readiness checklists. The advice is fine. It's also downstream of where prevention actually works.Implementation disasters get prevented in selection, not in implementation.By the time implementation is underway, the structural conditions that produce a disaster are largely set. The system was either selected against an accurate operational picture or it wasn't. The vendor was either filtered for fit against documented critical levers or it was filtered by who was visible and recommended. The contract either reflects sell-side patterns the buyer was helped to recognize or it doesn't. Implementation rigor matters at the margins, but the margins are narrow when the foundations underneath are wrong. The most disciplined project plan can't fix a system that doesn't fit the operation. The most experienced change management lead can't recover from a contract that priced for a scope the implementation actually requires twice over.The high-leverage prevention moves are upstream. A documented operational picture built from observation rather than description, before any vendor conversation begins — so the system gets evaluated against how the operation actually runs, not how it's been described. A shortlist filtered against those documented operational realities, not against vendor visibility — so the vendors making the cut are filtered by fit rather than by who showed up first. A vendor evaluation run through a frame that catches strategic omission and contract patterns that predict downstream problems — so what gets signed reflects what will actually be delivered, not what was implied during the sale. None of these are implementation moves. They're selection moves. They determine whether implementation has a foundation that can be executed on or a foundation that implementation will spend its budget compensating for.Founders who arrive at implementation having done that upstream work tend to have implementations that are hard but recoverable. Founders who arrive at implementation without it tend to have implementations where the team is solving fit problems the selection process should have caught — at the point in the project where solving them costs the most. Implementation discipline can't substitute for selection discipline. The disaster gets prevented earlier than founders are usually told to look for it.

Question 21

How do I compare WMS vendors?

Accepted Answer

Most advice on this question routes you to a comparison framework: build a weighted scorecard, score each vendor across the dimensions, total the columns, pick the winner. The frameworks aren't wrong. They're downstream of the harder problem.A comparison framework is a tool for evaluating options against criteria. It assumes you already know what the criteria are — which is to say, what your operation actually needs a system to do. That assumption is where most WMS comparisons quietly fail.The criteria most founders bring into a comparison exercise are the requirements they could articulate when asked. The workarounds nobody questions anymore, the exceptions that have become routine, the process gaps people have built habits around — those are the things most likely to determine real fit, and they're the things least likely to show up in a requirements list. Proximity blindness is doing its work before the framework opens. The criteria reflect the operation as the founder describes it, not as it actually runs. A scorecard built on those criteria produces a feature comparison, not a fit comparison. The vendor that scores highest is the one that best matches the described operation — which is not the same vendor as the one that fits the actual operation.The other input most founders feed into a comparison framework is their shortlist. The vendors being compared. That shortlist almost always carries availability bias — the vendors made the cut because they were visible, recommended, or actively reaching out, not because they were filtered against documented operational fit. Comparing a stacked shortlist against soft criteria is the activity that feels most like rigor and produces the least of it.What this means practically: the comparison stage is not where the WMS decision actually gets made. The decision was made earlier, when the criteria and the shortlist took shape — almost always without the founder seeing it happen. The comparison is the ratification, not the choice. Better comparison frameworks don't fix this. They polish a decision the inputs already determined.The structural question isn't how do I compare vendors better. It's how do I get to the comparison stage with criteria that reflect what my operation actually needs and a shortlist filtered against those criteria.

Question 22

How do I check WMS vendor references?

Accepted Answer

The conventional advice is a list of better questions to ask reference customers: ask about timeline overruns, ask about hidden costs, ask what they wish they'd known, ask to talk to someone in operations rather than the executive sponsor. The questions are reasonable. The problem is that they're being asked of the wrong people.Vendor-provided references are not a representative sample of the vendor's customer base. They're a curated one. The reference list is built from customers the vendor knows will give a positive account — customers where the implementation went well, where the relationship is intact, where the executive sponsor is invested in the vendor's success and unlikely to volunteer hard truths to a stranger on a phone call. Availability bias dressed up as due diligence. The references that would actually tell you something — the failed implementations, the mid-project pivots, the customers two years past go-live who quietly regret the decision — are not on the list. The vendor will not surface them, and they have no incentive to.Better questions to a stacked reference list don't fix the stacking. The reference call is structured to produce the same answer regardless of how the founder asks. The customer on the other end is friendly to the vendor by selection. The conversation happens inside that friendliness. The signal the founder is trying to extract — would this vendor be the right call for an operation like mine — is not a signal the reference call is built to produce.The references that would close this gap are the ones the founder would have to find independently. Customers the vendor didn't suggest. Implementations that didn't end with the relationship intact. Operations similar enough in shape to the founder's that the comparison actually generalizes. None of those are accessible through the vendor's reference channel, which is the only channel most founders have.This isn't a vendor failure. Vendors curate references because every vendor curates references — it's what reference programs are built to do. Asking a vendor to surface their failed implementations is asking them to do a job their sales motion isn't designed for, and they won't. The reference call is real, the customer is real, the answers are honest — and the input is still structurally compromised by who got into the conversation in the first place.What founders typically have access to instead, when they want signal that isn't curated, are peers and industry voices — which carry their own version of the same problem. A peer's experience with a vendor reflects their operation, not yours. An industry voice's recommendation reflects their relationships, which usually include the vendors. The kind of vendor-side pattern recognition that would actually inform a fit decision — what specific systems do under stress, where particular vendors deflect, what their contract language signals — accumulates from being on the other side of the table, and isn't something a reference call is designed to surface.

Question 23

How is this different from a vendor's discovery process?

Accepted Answer

A WMS vendor's discovery process and an independent assessment look superficially similar. Both involve walking through the operation, both ask about workflows and requirements, both produce documentation that informs the system selection. The difference isn't in the activity. It's in what each process is structurally built to surface.A vendor's discovery process is part of a sales motion. It's not dishonest — the discovery team is asking real questions, and the documentation is real work. But the process is built to find the path from where the founder is to a signed contract for the vendor's product. That structural job determines what discovery surfaces and what it doesn't. It surfaces the requirements the vendor's product can demonstrably support. It surfaces the workflows that map cleanly to the system's strengths. It does not go looking for the operational realities that would expose fit problems with the vendor's own offering, because no sales motion is structured to disqualify itself. Strategic omission isn't a failure of vendor discovery. It's a feature of how every vendor's discovery is designed to operate.An independent assessment has a different structural job. It's built to surface what the operation actually needs a system to do — including the workarounds, edge cases, and process gaps the founder has stopped seeing because proximity blindness has made them invisible — and to evaluate that against the vendor market without a stake in which vendor wins. The assessment surfaces the things vendor discovery has no incentive to surface. It documents the operation as it actually runs, not as it has been described. It produces a baseline that exists independently of any vendor's product.The gap between the two isn't quality of work. It's whose interests each process is built around. Vendor discovery is the founder's operation seen through the lens of the vendor's product. Independent assessment is the founder's operation seen through the lens of what the operation actually needs. Both are useful. Only one produces a foundation the founder can evaluate vendors against rather than from inside.The System Fit Sprint exists because the structural conditions of an independent assessment — no vendor relationships, no implementation revenue, no stake in which system wins — are not conditions any vendor's discovery process can replicate. Not because vendors are doing something wrong, but because the discovery process is doing exactly what a sales motion is supposed to do. The founder who treats vendor discovery as a substitute for independent assessment is not getting a worse version of the same thing. They're getting a different thing, designed for a different outcome.

Question 24

What's the best WMS for a mid-sized 3PL?

Accepted Answer

The question feels like it should have an answer. It doesn't. Not because the WMS market is too crowded or too dynamic to track — it isn't — but because best is operation-specific in a category where operations vary more than the systems do.Two 3PLs at the same revenue, with similar headcount and similar warehouse square footage, can run operations that need fundamentally different systems. One handles a steady B2B client base with predictable pick patterns and minimal customization; one handles a hybrid B2B/B2C mix with a long tail of client-specific exceptions and constant onboarding. The first one needs a system optimized for stability and throughput. The second one needs a system that can absorb operational variance without breaking. The "best" WMS for the first 3PL would be a structural mismatch for the second. There is no general answer that survives the difference between these two operations — and the difference is invisible from outside the operation.The instinct behind the question is reasonable. The founder is trying to compress a complicated decision into a generalizable answer. Most decisions can be compressed that way — there are best practices, common standards, default choices that work for most operations most of the time. WMS selection is one of the cases where the compression destroys the signal. The features that make a system the right call for one operation are the same features that make it the wrong call for another. The decision is not generic, and treating it as if it were is how founders end up with systems that demoed well, scored highly, and broke in implementation.This is also why published WMS comparison rankings — top WMS for 3PLs, best WMS by size, leading WMS for hybrid operations — are misleading even when they're well-researched. The rankings are scoring systems against generic criteria. The criteria that determine fit for a specific operation are not the criteria the rankings use, because the rankings are structurally required to use criteria that generalize. A system that ranks highly across the top published lists may be the wrong system for the operation reading the list. The list cannot tell the founder this, because the list has no access to the operation.The honest answer to the question is the one founders typically don't want to hear: there is no best WMS for a mid-sized 3PL. There is a best WMS for this specific operation, given what it actually does today and what it plausibly needs to do over the next three to five years — and identifying that system requires closing the proximity gap between the operation as the founder describes it and the operation as it actually runs, then filtering the vendor market against documented operational fit rather than against generic criteria. None of that is generalizable. All of it is the work the question is trying to skip.

Question 25

Why is my 3PL hard to scale?

Accepted Answer

The visible answers to this question are usually about people, process, or capital. Hiring is slow. Training takes too long. New clients onboard messily. The team is stretched. Capacity expansion needs investment the business can't yet make. Each of those is real. Each of them has a tactical answer. And in most 3PLs that are genuinely hard to scale, fixing all of them in sequence still leaves the scaling problem largely intact.That's the signal that's worth paying attention to. When the visible answers don't compound into the outcome the founder expects, the friction is usually being produced somewhere the founder isn't looking. In a 3PL, the place the founder usually isn't looking is the system foundation underneath the operation — the WMS, the workflows it does or doesn't support, and the workarounds the team has built around its gaps. The friction the founder is attributing to people and process is often the surface effect of a system foundation that hits a ceiling well before the business does.The reason this is hard to see from inside the operation is structural. The workarounds, exceptions, and process gaps that define how the operation actually scales — or doesn't — have become invisible through normalization. A workaround that's been in place for two years stops feeling like a workaround. It just becomes "how we do it." Each one carries a hidden cost in training overhead, error rates, throughput, and onboarding friction. The costs are real, but they don't show up labeled as system costs. They show up as the things the founder is trying to fix by hiring better, training harder, or building more process. Proximity blindness is doing its work before the question of why is scaling hard even gets asked.This doesn't mean every scaling-hard 3PL has a WMS problem. Some genuinely do need to hire differently or invest in capacity. But when the visible fixes aren't compounding, the foundation is usually the place to look — and looking at it clearly tends to require an outside view, because from inside the operation, the foundation is the thing that has stopped being visible at all.

Question 26

When does a 3PL need a WMS?

Accepted Answer

Most versions of this question expect a threshold answer. A revenue number. An order-volume tier. A headcount. A SKU count. The expectation is that there's a line, and once the operation crosses it, the WMS conversation becomes urgent.The thresholds aren't useless — operations of certain sizes do tend to outgrow certain kinds of systems — but they're a weaker signal than they look. Two 3PLs at the same revenue, with similar volumes and similar headcount, can be in genuinely different places on the WMS question. One is running comfortably on a system that fits the operation. The other is running on workarounds the team has stopped noticing, with a system that stopped fitting eighteen months ago. The threshold doesn't tell them apart. What tells them apart is whether the operation has quietly accumulated enough hidden friction that it has outgrown the foundation underneath it — and that's a question the threshold framing isn't built to surface.The harder problem is that the founder is usually the wrong person to detect this from inside the operation. The friction shows up first in the things that have become invisible: the manual reconciliation step that's been part of the closing routine for two years; the client onboarding that takes longer than the team admits because nobody is timing it anymore; the error rates that have crept up slowly enough to feel like the baseline; the workarounds that have become so embedded they're treated as standard procedure. Each of those is a signal that the operation has outgrown its foundation. None of them announce themselves as such. Proximity blindness is what keeps them from announcing themselves — the operation has normalized them, and the founder, by definition, is the most normalized observer of it.So the honest answer to when does a 3PL need a WMS is: usually somewhat before the founder recognizes it does. The recognition tends to lag the need, because the indicators that should drive recognition have been absorbed into the operation's day-to-day. Founders who go looking for the answer in revenue thresholds or volume tiers are looking for a signal the operation rarely sends in those terms. The signal it sends, when it sends one at all, is friction that the team has stopped calling friction.This isn't a reason to start a vendor evaluation reactively at the first sign of normalized workarounds. It's a reason to take seriously that the question do we need a WMS yet is structurally harder to answer from inside the operation than the question's framing suggests — and that the answer founders typically arrive at on their own usually arrives later than the operation would have benefited from.

Question 27

What does it cost to run a 3PL without a real WMS?

Accepted Answer

The instinct behind this question is usually to itemize. Error rates, training overhead, customer complaints, throughput ceilings, scaling friction, the cost of paper-based or radio-based processes in an environment where end-clients now expect consumer-grade tech experiences. Each of those is real, and each can be assigned a number with enough effort. The reason the itemized version is unsatisfying isn't that the numbers are wrong. It's that the numbers, even added up correctly, undercount the actual cost in a way that's invisible to the founder doing the adding.The hidden cost isn't a separate category. It's that the costs the founder can see have been operating long enough to feel like baseline conditions rather than costs. An order-accuracy rate of 96% sounds like a number; if it has been the rate for three years, it stops feeling like a 4% error cost and starts feeling like "our accuracy." Training time that runs eight weeks for a new picker stops feeling like overhead and starts feeling like "how long it takes to ramp someone." Onboarding a new client that takes two months stops feeling like friction and starts feeling like "our onboarding timeline." None of those numbers register as costs because the operation has normalized them. They feel like the shape of the business, not like the things the business is paying for the absence of a system that would let them be different.This is what running without a real WMS actually costs: not just the line items the founder can enumerate, but the larger second-order cost of not being able to see clearly how much of the operation's friction is system-shaped rather than people-shaped or process-shaped. The team is hired against the friction. The training is built against the friction. The hiring plan, the onboarding cadence, the client commitments, the capacity model — all of it is calibrated to an operation running on a foundation that doesn't fully support it. The cost compounds at the system foundation and then gets paid everywhere else in the business, where it doesn't look like a system cost at all.Proximity blindness is what makes this hard to estimate from inside. The founder isn't underestimating because they aren't trying. They're underestimating because the costs that have been operating longest are the ones that have most thoroughly become part of the operation's self-description. Asking the founder what does it cost is asking them to inventory friction the operation has stopped flagging as friction — which is the inventory the operation is least equipped to produce.The honest cost is usually larger than the itemized version. How much larger is the thing that gets hard to answer from where the question is being asked.

Question 28

My WMS implementation is failing. What do I do?

Accepted Answer

The triage questions are immediate and reasonable. Escalate to the vendor. Get an outside review. Pull in the implementation team's leadership. Document everything. Prepare for the possibility of a renegotiation, a contract dispute, or a write-off. Each of those has a place. But the question they all skip is the one that determines whether any of them is the right move: what kind of failure is this?Most failing WMS implementations look similar from inside the failure. Timelines slip. Scope shifts. The vendor's explanations get less confident. The team's frustration builds. The founder is asked to make decisions about things — configuration trade-offs, customization scope, go-live readiness — that the founder doesn't have the context to decide well. The surface is roughly the same regardless of root cause. Underneath, three different failures tend to be running, and they require different responses.The first is a configuration failure. The system that was selected can support the operation, but it has been configured against the wrong picture of what the operation needs. The workflows have been built around an inaccurate operational baseline. The integrations have been scoped against requirements that don't reflect the floor reality. This kind of failure is usually fixable — the system is the right system; what got built on it is wrong. The path forward involves rescoping configuration against an accurate operational picture, which usually means going back to the work that should have been done before the system was selected and doing it now, mid-implementation, under significantly worse conditions.The second is a process failure. The system is right, the configuration is closer to right than wrong, but the operation hasn't done the people, process, and data work that implementation requires. The team isn't ready. The data isn't clean. The workflows haven't been updated to take advantage of what the new system does. The system is doing its job; the operation hasn't caught up to it. This is also usually fixable, but the fix isn't a system fix — it's an operational fix that the implementation team isn't structurally set up to drive. The founder usually has to lead it, and usually doesn't recognize that distinction in time.The third is a selection failure. The system itself is wrong for the operation, and no amount of configuration or process work will close the gap. This is the failure that doesn't get better with more effort, because effort is being applied to a foundation that can't carry the operation regardless. Selection failures showing up downstream are the failure mode the implementation phase wasn't built to surface or solve — they originated upstream, in a process that produced a selection against an inaccurate operational picture or through a buyer-only frame that didn't expose the fit problems that are now visible at full cost. The path forward in this case is structurally different from the other two: more effort on the current system is good money after bad, and the real question becomes whether the implementation can be paused, whether the contract can be unwound, and whether the next selection — if there is one — gets done differently.Which failure the implementation is in determines almost everything about what to do next. Configuration failures get rescoped. Process failures get operationally led. Selection failures get exited, on the best terms available. The triage moves — escalation, outside review, documentation — are useful in all three cases, but they don't substitute for the diagnosis. The diagnosis is what tells the founder whether they're trying to fix the right thing.Most founders living a failing implementation are in the middle of it without having yet asked the diagnostic question. The failure itself is consuming the attention that the question requires.

Question 29

We picked the wrong WMS. What now?

Accepted Answer

Two questions sit underneath this one. The first is whether the system is actually wrong, or whether what's wrong is what got built on it. The second is what to do about it depending on which answer the first one returns.The first question is harder than it looks from where it's being asked. By the time a founder concludes the WMS is the wrong WMS, the implementation has usually accumulated enough problems that the system has become the most visible explanation. Some of those problems do trace to the system itself. Others trace to a configuration that was built against an inaccurate picture of the operation, or to operational readiness gaps the implementation phase wasn't structurally set up to fix. The conclusion we picked wrong is sometimes the right diagnosis and sometimes the most available explanation for a problem with multiple structural sources. Disentangling which is which is harder mid-failure than it would have been earlier, because more variables are confounded.If the system is configuration-wrong rather than fundamentally-wrong, the path forward usually doesn't involve replacement. It involves going back to the operational picture, building it accurately this time, and rescoping configuration against what's actually true on the floor — work that should have happened before the system was selected and that's now being done under worse conditions, with sunk costs in the way. This isn't a comfortable path. It's usually the right one when the system itself can support the operation and what's failing is what got built on top of it.If the system is fundamentally-wrong — wrong category, wrong architecture, wrong product for the operational realities that are now visible — then no amount of reconfiguration closes the gap. The system cannot do what the operation needs it to do. In that case, the question becomes how to exit on the best available terms: whether the implementation can be paused, what the contract actually permits, what the practical cost of switching is, and whether the operation can run on the current system in a degraded mode while a real selection process happens. None of that is a good situation. Some of it is recoverable. Most of the recovery comes from the next decision being made through a process that closes the gaps the first one left open.The structural observation worth holding through both paths is that picking the wrong WMS is rarely a mistake the founder made through carelessness. It's usually the predictable output of a selection process that was structurally compromised before the founder ever sat down to demos. Every input the founder collected — peer recommendations, vendor presentations, reference calls — was shaped by someone with a stake in which system would be selected. The shortlist reflected vendor visibility more than operational fit. The vendor evaluation ran through a buyer-only frame that the questions vendors are designed to answer are specifically built for. The selection that resulted reflected the inputs accurately. The inputs were the problem.This isn't offered as consolation. It's the same observation that determines what to do about the next selection, if there is one. The founder who concludes we picked wrong and then runs the next selection the same way is likely to pick wrong again, because the inputs haven't changed. The founder who concludes the inputs were the problem has a different starting point — and a different chance at a different outcome.

Question 30

Can a failed WMS implementation be saved?

Accepted Answer

Sometimes. The honest answer is that saving a failed implementation depends almost entirely on what failed actually means in the specific case — and the cases where the answer is yes look structurally different from the cases where it's no.An implementation in which the system is the right system, the operational baseline was wrong, and the configuration was built against the wrong baseline can usually be saved. The work is uncomfortable — going back to do operational reality work that should have happened before the system was selected, rescoping configuration under sunk-cost pressure, recovering team morale that has eroded during the failure — but the system itself can carry the operation once the work that wasn't done gets done. The implementation isn't saved by fixing the implementation. It's saved by going back to the input that was missing.An implementation in which the system is the right system but the operation isn't ready for it — people, process, data — can also usually be saved, though the saving doesn't happen in the implementation. It happens in the operation. The system has been waiting for the operation to catch up to it; the path forward is leading that operational change, which the implementation team typically isn't structured to lead and the founder typically has to drive. Implementations in this state often look like they're failing when what's actually happening is the operation underneath them isn't able to receive what the system is delivering.An implementation in which the system itself is fundamentally wrong for the operation can't really be saved in the sense the question intends. More effort on the current system doesn't close the gap, because the gap is between what the system architecturally does and what the operation structurally needs. What can be done in this case isn't saving — it's exiting on the best terms available and getting to a real next selection without repeating the conditions that produced this one. That's a different question than whether the current implementation can be rescued, and treating it as the same question is how some founders spend another year and another budget cycle trying to save something that the structural reality won't let them save.The diagnostic that separates the saveable cases from the unsaveable ones is what determines the answer. The surface symptoms of a failing implementation look similar across all three: timelines slip, vendors get defensive, teams get frustrated, decisions get harder. Underneath, the conditions are different, and the conditions determine whether saving is possible. Most founders asking can this be saved are asking before the diagnostic has been done — which is the right time to ask the question, but the wrong time to expect a confident answer.What does help: getting the diagnostic done before more resources get committed to a path the diagnostic might not support. The cost of pausing to figure out which kind of failure is in progress is almost always smaller than the cost of continuing to push on the wrong path. Implementations that get saved tend to be the ones where the founder paused to ask which failure is this before deciding how hard to push for recovery. Implementations that don't get saved tend to be the ones where the founder kept pushing without that diagnostic, on a path that more effort couldn't fix.So: sometimes. Whether this implementation can be saved is a question the diagnostic answers. The question that can be answered without the diagnostic is whether the diagnostic is worth doing — and it almost always is, because the alternative is making the next set of decisions in the same conditions that produced the current ones.

Frequently Asked Questions

Recognizing the problem

The selection process

Evaluating vendors

When implementations fail