Run a bake-off
Three vendors demo, a scorecard gets built afterwards to justify the preference already formed, and the selection is made on presentation quality. The problems arrive during implementation, when changing course is expensive.
A seven-figure system decision is on the table, and the vendors are the only advisors in the room.
ERP, CRM, or a platform migration you will live with for a decade.
The people who understand the options best are the people selling them, and their answers are honest and incomplete in exactly the ways their products require. Meanwhile the requirements are being assembled from whoever in the business feels most strongly, the demo is being mistaken for the product, and the number under discussion is the licence cost rather than the cost of getting the company onto it.
Underneath
What is actually going on
The visible problem is rarely the one that decides how this goes. These are the parts that are true whether or not anybody has said them out loud.
The advisors are the vendors
Every question you ask is answered by somebody whose compensation depends on the answer. That does not make them dishonest; it makes their advice structurally incomplete.
Requirements written by volume
The department that lobbies hardest gets its needs into the specification, and the quiet operational requirement that breaks the implementation is not in there at all.
The demo is not the product
Demonstrations run on prepared data, in configurations built to demonstrate. The gap between that and your data is where implementations overrun.
The real cost is downstream
Licence cost is the visible number. Implementation, data migration, integration, training and the productivity dip are the ones that decide whether this was a good decision.
The fork
Two ways this usually goes
Write the requirements before you meet anyone
Get what the business actually needs on paper first, agree how you will score it before you see a demonstration, and make every vendor answer the same questions. The shortlist then means something.
The order
What to do, in sequence
The order matters more than the individual steps. Most of the cost in these situations comes from doing the right things in the wrong sequence.
- First
Requirements from the business
Gathered across the departments that will use it, including the ones that do not lobby. Written as outcomes rather than as a feature list copied from a brochure.
- Before demos
Agree the scoring model
Weighted, written down, signed off. Doing this after the demonstrations means building a justification rather than making a decision.
- During
Scripted demonstrations on your data
Your scenarios, your edge cases, your volumes. Plus reference calls with customers you found rather than customers you were given.
- Before signing
Negotiate the whole cost
Licence, implementation, integration, exit. Including what happens at renewal in year three, which is where the leverage disappears.
The questions
What you will be asked
Each of these has a real answer and a plausible one. Knowing which you are giving is most of the job.
What must this do that the current system cannot, in the words of the people who will use it?
What is the total cost over five years, including implementation and change?
Who inside the business is accountable for adoption after go-live?
What does leaving this platform look like, and what would it cost?
The result
What you end up with
- Requirements written independently of any vendor
- A weighted scoring model agreed before the first demonstration
- A scored comparison you can show a board
- A negotiated contract covering implementation, renewal and exit
Also happening