Why the best fit is good for the vendor too

What a poor fit looks like

It rarely shows up at the demonstration. It shows up months later, during data migration, testing or the first month-end:

• A fundamental gap: a type of work the system cannot handle properly, an accounting process it does not support, a regulatory report it cannot produce. In our experience most change requests after go-live relate to accounting, which is why core accounting is still the gold standard for selection.
• Development on the fly: the vendor diverts developers to build the missing piece under time pressure, without the design and testing it would normally get.
• Scope disputes: was it in the contract or not? Who pays? Each side has a reasonable view, and the relationship suffers whichever way it is settled.
• Workarounds: spreadsheets and manual steps fill the gap, and often become permanent.
• Delay and fatigue: go-live slips, teams on both sides are exhausted, and the firm's people lose faith in the system before they have really used it.

Why it hurts the vendor too

• Margin: unplanned development and a long implementation cost the vendor far more than the original deal assumed.
• The roadmap: developers pulled onto one client's emergency delay features that many other clients are waiting for.
• Reputation: an unhappy firm will not be a reference site, and the legal market is small enough for word to travel.
• Retention: a firm that starts badly is the firm most likely to leave at the first renewal.

A good fit gives the vendor the opposite: a predictable implementation, a client who becomes a reference, and a roadmap driven by what the market needs rather than by firefighting.

Why it happens

• Requirements that are too general: "must handle conveyancing" means very different things to different people.
• Standard demonstrations: the vendor shows what the system does well, not what the firm needs to see.
• Pressure to say yes: on both sides of the table. Sales teams want the deal; firms want the decision made.
• Firms not knowing their own processes: what the old system does quietly, often through years of customisation, is only noticed when it is missing.
• Development contracted as a one-liner: when a gap is agreed as development, the contract often says little more than "the system will produce the monthly client account report". There is no scope, no user stories, no acceptance criteria and no definition of done. The developers have no real idea what they are creating, so they build their interpretation, the firm tests against its expectation, and the gap between the two becomes the dispute.

How to get a fit that works for everyone

1. Be specific: write requirements that describe how you actually work, including the awkward cases.
2. See it working: scripted demonstrations using your own scenarios and sample data. If you cannot see it, treat it as not existing.
3. Put the gaps on the table before signing: a gap register listing what is missing, how it will be handled (configuration, workaround or development), who pays, when it will be delivered and how it will be accepted, written into the contract.
4. Define every piece of development properly: user stories written with the people who will use it, worked examples from your own data, acceptance criteria and a definition of done, agreed by both sides before any code is written. It takes days, and it saves months. Developers can only build what they understand.
5. Value an honest "no": a vendor that tells you something is missing is a vendor you can work with. One that says yes to everything is storing up the problem.
6. Walk away from a fundamental gap: if something central to how the firm works is missing, no discount makes up for it.

An adviser with no side to take

Because we have no ties to any vendor, we can tell a firm when a system is not right for it, and tell a vendor plainly what a firm really needs. Having worked inside law firms and inside the vendors that sell to them, we know that a selection made on evidence leads to a stable project for every party. Our free requirements builder produces a technical selection specification and demonstration scenarios you can use with any vendor, including asking each one for a gap register, and we can run the whole selection with you, independently of any vendor.