Guides
These guides come out of rescue engagements rather than out of marketing. That means they are specific, occasionally unflattering to us, and willing to tell you the answer is to buy nothing — which is the answer a meaningful share of the time.
Send your shortlist, requirements, or a vendor quote. A person reads it and replies in writing.
The guides
We publish a guide when we have enough engagement evidence to say something specific, rather than restating what every vendor blog already says.
How to run a selection that survives implementation — the four decisions, the eight questions, and when to buy nothing.
Primary cause across 41 stalled deployments. Only four percent were the software.
Licence, implementation, integration, and the internal cost nobody books. What each vendor actually charges for.
What a mid-market implementation really costs and how long it really takes, by system.
Modelling three years properly, including the lines vendors leave out of a comparison.
The three signals that predict it, and the two fixes that do not require replacing your ledger.
A requirements document that produces useful demos rather than a feature bingo card.
Eleven to fourteen weeks, phase by phase, with what to do in each.
Search almost any ERP question and you get the same article rewritten forty times: a definition, a benefits list, a feature comparison that discriminates between nothing, and a call to book a demo. It is produced at volume because it ranks, and it is useless because it was never written to be read.
The tell is that it never says anything that costs the author something. No vendor blog will tell you the product is the cause of failure four percent of the time, that you should ask for a reference who left, or that a meaningful share of ERP searches should end with buying nothing. Those are all true and all commercially inconvenient.
Most of the material originates in diagnostics — the two days we spend inside a stalled or unhappy deployment before quoting. That is an unusually good vantage point, because you see what actually happened rather than what the project plan said would happen, and you see it across many companies with different systems.
It also biases the material toward failure modes, which is worth naming. A company that bought well and implemented smoothly never calls us, so our view of this category is skewed toward the projects that struggled. Read the guides as field notes from that vantage point rather than as a survey.
If something here is wrong, tell us. Factual errors get fixed and dated with a note saying what changed. We do not silently edit.
Questions
Send it. A person reads it and replies in writing, whether or not there is a deal in it.