Selecting a New Case Management System: Why the Scope of Works Matters More Than the Demo

Most case management system projects that go wrong do not fail at selection. They fail at implementation, and the cause is nearly always written down months earlier in a document few partners read closely: the scope of works. Choose the right platform with a weak scope and you will still end up over budget, late and with a system that only half fits the way your firm works.

Selection gets all the attention. The demos, the shortlist, the pricing negotiation. The scope of works is often treated as paperwork that follows once the decision is made, and very often the vendor drafts it. That is where an independent consultant earns their fee.

The scope is where the sales pitch meets reality

During a sales process, everything is possible. Workflows can be configured, integrations are available, data migration is straightforward. None of those statements are exactly false. They simply have not been tested against your case types, your volumes or your data.

The scope of works is the first point where those promises have to become deliverables, assumptions, days and costs. If the firm does not write it, or at least challenge it line by line, the vendor will write a version that protects the vendor.

A scope of works written by the vendor is a sales document with a delivery date attached.

What a vendor-led scope usually leaves out

• Data migration defined as "standard" | which usually means open matters and core fields only, with closed matters, documents and history left behind or quoted separately later.
• Integrations listed by name only | "Outlook integration" or "accounts integration" with no detail on which data moves, in which direction, or who fixes it when a sync fails.
• Workflow configuration capped by days, not outcomes | so when the allowance runs out halfway through your second practice area, everything after it becomes a change request.
• Document templates excluded or limited | a firm with several hundred precedents discovers that converting them is the client's responsibility.
• Testing left to the firm | with no defined acceptance criteria, so there is no objective point at which the work counts as complete.
• Training reduced to a fixed number of sessions | delivered around the vendor's diary rather than your go-live plan.
• Assumptions buried in an appendix | that your data is clean, your staff are available and your decisions will be made within days, none of which the vendor has checked.

Each item looks small at signature. Together, they are the reason so many implementations end up costing half as much again as the original proposal.

How an independent consultant cuts through it

An independent consultant has no licence to sell and no implementation days to bill against. That changes what they look for. Their job is to make sure the scope describes what your firm actually needs delivered, in enough detail that both sides know what done looks like.

• Mapping current workflows by case type before the scope is drafted, so configuration is defined by your processes rather than the vendor's template.
• Profiling your data | what exists in the legacy system, what condition it is in and what genuinely needs to move | so migration is scoped on evidence rather than optimism.
• Specifying every integration properly: the systems, the data, the direction, the frequency and who owns failures.
• Writing acceptance criteria into the scope, so sign-off depends on the system working rather than the days being used up.
• Separating what is in scope, what is out of scope and what is the firm's own responsibility, in plain language.
• Pressure testing every assumption and pricing the risk in it, so it is visible before signature rather than after go-live.
• Building a realistic plan for internal resource, because the fee earners and supervisors who need to test and sign off are also the people billing.

The state of the existing build matters here too. A legacy system with duplicated case types and undocumented workflows has to be understood before anyone can honestly scope what replaces it.

Phasing is a scoping decision, not a fallback

One of the most useful things a good scope does is decide what not to do on day one. Trying to move every practice area, every integration and every template in a single go-live is how projects stall.

A phased scope puts the highest-volume or highest-value work first, proves the platform under real conditions and gives the firm a chance to learn before the harder areas follow. Vendors will usually agree to phasing if asked. They rarely suggest it, because a single big-bang scope is easier to sell and simpler to price.

Getting the balance right

• Write your requirements before the demos, and write the scope before you sign.
• Insist the scope is specific to your firm, not a template with your name added.
• Treat "standard" as a word that needs defining every time it appears.
• Agree acceptance criteria for every deliverable, including data migration.
• Make sure every assumption has an owner and a consequence if it proves wrong.
• Check the change control process and day rates now, because you will use them.
• Have someone independent read the whole document, including the appendices.

The right platform with a well-defined scope of works will usually be delivered close to plan. The right platform with a vague one rarely is. If your firm is choosing a new case management system, or has a proposal on the table and a scope of works it is not sure about, get in touch and we will tell you what it really commits you to.