Change management for AI adoption in litigation

Most firms that buy new software do not fail at installing it. They fail at the six weeks afterwards, when the old way is still there and still works well enough. AI tools face that problem twice over: they ask people to change how they work, and they ask people who are paid for judgement to trust a machine with part of it. This guide is a framework for bringing skeptical partners and staff along.

Start with the work, not the tool

Do not open with a demo. Open with a list of the work everyone already agrees is waste: renaming files, re-keying client details, chasing records, building chronologies by hand, calendaring by copy and paste. Ask the people who do that work to rank it by how much they would like it gone. The tool you introduce should remove the top item on that list, and you should say so.

People adopt what takes something off their desk. They resist what adds a new screen to it.

Find the skeptic, not the champion

Every firm has an enthusiast who will try anything. Their adoption proves little. The partner who is sure this will not work on real cases is the one worth convincing, because everyone else is waiting to see what they say. Give that person a real matter, the authority to judge the result, and a direct line to raise every problem they find.

Pilot on live matters, with a narrow scope

Pick one workflow and a handful of active cases. Run the new process alongside the old one for two weeks, then compare: time spent, errors caught, what each version missed. A narrow pilot on real work produces evidence people trust; a broad pilot on test data produces a slide.

Keep a person accountable for every output

Nothing in the pilot should go out the door without a named person having checked it. That is not a concession to skeptics; it is how the firm stays responsible for its work product. It also turns review time into the measure of success: as people learn where the system is reliable, review gets faster, and that speed is the honest number to report.

Train in the job, not in a classroom

Short sessions on a person's own matters beat any long training day. Pair each new user with someone a week ahead of them. Write down the five questions everybody asks in the first week and answer them in one place.

Retire the old way on a date

Two parallel processes are more work than either one. Once the pilot has shown the new workflow holds up, set a date when the old one stops — the old folder becomes read-only, the old spreadsheet is archived — and tell everyone well in advance.

What to report to the partners

Report what changed for the work and for the client, not what the tool can do: hours returned on the piloted workflow, problems the review caught, matters that moved faster, and what the people doing the work say about it in their own words. If those numbers are not good, say so and adjust the pilot. Credibility is the asset this whole process spends.

A four-week outline

Week one: list the waste and pick one workflow. Week two: pilot it on live matters with the skeptic involved. Week three: compare, fix what the pilot exposed, train the next group on their own matters. Week four: set the retirement date for the old process and report to the partners.