Legal Technology Adoption: Why Implementations Fail and How to Prevent It

May 25

11 min read

Legal technology adoption fails far more often because of how a system is introduced than because of any defect in the system itself. A firm purchases a capable platform, configures it quickly, announces that it is now in use, and within a few months finds that fee earners have returned to their private spreadsheets, shared drives and email folders. The software remains licensed and the firm remains out of pocket, but the work continues to be done as before. The cost is not only financial. Matters are now recorded partly in one place and partly in another, which is a worse position than either approach used consistently.

Legal technology adoption is properly understood as a change in how a firm works, which happens to involve software, and not as a software purchase which happens to involve some change. The decisive questions are therefore organisational: who owns the project, what problem is it meant to solve, which working habits must alter, what happens to existing data, and how will the firm know whether the change has taken hold. A firm that answers those questions before it signs a contract will usually succeed with any competent product. A firm that does not will usually fail with the best one.

This article examines the recurring causes of failed implementations, sets out a phased programme for avoiding them, and offers a practical checklist for solo practitioners and small firms. It makes no claims about industry failure rates, because reliable figures for law firms are not available to the author, and it does not assume any particular product.

What failure looks like in a law firm

Failure is rarely dramatic. A project seldom collapses on a single day. It erodes, and the signs are recognisable well before the firm admits to itself that anything is wrong.

Parallel systems. Fee earners keep their own diaries, notes and document folders alongside the official system, and the official record is incomplete.
Selective use. The system is used for time recording and billing, because the finance function insists upon it, but not for document management or matter notes, because no one does.
Workarounds. Staff email documents to one another and then upload the final version later, or not at all.
Data decay. Fields are left blank or completed carelessly, so that reports are unreliable and no one trusts them.
Quiet dissent. Senior practitioners describe the system as slow or unsuitable, and junior staff take their cue from them.

Each of these is a symptom of one or more underlying causes, which the following sections address.

The principal causes of failed implementations

No defined problem

Many projects begin with an instruction to modernise rather than with a statement of what is wrong. Without a defined problem there is no standard against which to judge the result. A firm that cannot say whether it is trying to reduce missed limitation dates, speed up billing, improve conflict checking, or simply give clients a better experience cannot decide which features matter, cannot prioritise configuration, and cannot recognise success. The first task is to write down, in a sentence or two for each, the specific difficulties the firm expects the technology to relieve.

Absence of a responsible owner

Implementations assigned to everyone are in practice assigned to no one. Someone with authority must own the project: able to make decisions, to insist upon changes in habit, and to be held to account for results. In a small firm this is often the principal. Where the principal delegates it, the delegate must have genuine authority and protected time, since a project run in the gaps between fee-earning work will be deferred whenever a deadline looms, and in a law firm a deadline always looms.

Partner and principal disengagement

Staff watch what senior practitioners do. If the principal continues to dictate letters for typing, keeps a private paper diary, or exempts herself from time recording, the rest of the firm will conclude that the system is optional. Visible, consistent use by the most senior people is the single most reliable determinant of adoption, and no amount of training compensates for its absence.

Over-configuration at the outset

Firms often attempt to replicate every existing process, form and exception in the new system on the first day. The result is a complicated configuration that confuses users, delays go-live, and encodes bad habits permanently. It is better to launch with a deliberately modest configuration, covering the essential workflows well, and to add refinements when users have experience and can say what they actually need.

Poor data migration

Migrating existing data is where many implementations are won or lost. Moving years of duplicated client records, inconsistent names and abandoned matters into a new system transfers every defect and makes the new system look unreliable from the outset. Equally, migrating nothing leaves fee earners unable to find the history of live matters and drives them back to the old sources. Data migration is considered in detail below.

Inadequate or untimely training

Training delivered months before go-live is forgotten, and training delivered once, in a single session, is not retained. Generic training that does not use the firm's own matters and documents fails to connect with daily work. Staff also differ widely in confidence, and those least comfortable with technology are often the least likely to say so.

Ignoring the people who do the work

A system selected by the principal alone, without reference to the secretaries, paralegals, accounts staff and junior attorneys who will use it daily, is likely to contain features that nobody wanted and to lack those that matter to them. Those users also hold the best knowledge of how work is actually done, as distinct from how the firm's procedures say it is done. Excluding them wastes that knowledge and breeds resentment.

No measurement and no review

If no one checks whether the system is being used correctly, usage drifts. Without agreed indicators, the firm cannot distinguish a teething problem from a fundamental one, and the decision whether to persevere, adjust or abandon is taken on impression and anecdote.

Before selection: establishing the requirements

Prevention begins before any product is examined. The firm should prepare a short requirements document, which need not exceed two or three pages.

State the problems. List the specific difficulties the firm hopes to resolve, in order of importance.
Map current workflows. Describe how a matter moves through the firm from first enquiry to file closure, noting where information is created, where it is stored, and where it is lost or duplicated.
Distinguish essential from desirable. Identify the functions without which the system is useless to the firm, such as conflict checks, trust or client account handling according to local rules, limitation date diarising and document storage, and separate them from conveniences.
Record regulatory constraints. Note any requirements of the regulator concerning client money, record retention, confidentiality and the location of data, and verify them against the rules of the relevant jurisdiction.
Define the user base. Count everyone who will need access, including part-time staff, locums and the occasional user, and consider whether the pricing model penalises growth. Per-seat pricing can make a firm reluctant to give access to those who would benefit, which undermines adoption. A firm-wide price with unlimited users removes that incentive.

Evaluating products and vendors

With requirements in hand, the firm can evaluate options on a principled basis. A demonstration conducted by the supplier shows the product at its best; the firm should insist on seeing its own scenarios. A useful practice is to supply the supplier with two or three real, anonymised workflows and ask to see them performed, or better, to carry them out personally in a trial environment.

The following questions are worth asking of any supplier, and the answers should be obtained in writing.

Where is client data stored and processed, and who may access it? What is the supplier's practice on subcontractors?
Can the firm export all its data, in a usable format, at any time and on leaving? What does that cost?
What is the exit procedure, and how long are data retained after termination?
How is the system backed up, and what are the arrangements for service interruption?
What support is included, through what channels, and in what hours?
How are changes to the product communicated, and can the firm decline or defer them?
How is the price determined, and what changes in the price as the firm grows?

The firm should read the contract with the care it would bring to any commercial agreement, paying particular attention to data protection obligations, limitations of liability, termination rights and the position on data return. Claims of security certification or compliance should be verified, not accepted on assertion.

Data migration: deciding what to bring across

The principle is to migrate what is needed and to archive the rest. A sensible approach divides existing records into three groups.

Category	Treatment	Reasoning
Live matters and current clients	Migrate in full, after cleansing	Fee earners need the history and documents to continue working without returning to old sources
Recently closed matters within the firm's retention period	Migrate in summary form, or archive in a searchable store	The firm may need to retrieve them, but they do not need full workflow functionality
Old closed matters and dormant contacts	Archive outside the new system, subject to the regulator's retention rules	Migrating them adds clutter and cost, and does not assist current work

Cleanse before migrating

Duplicate clients, misspelt names and inconsistent entity descriptions should be corrected before they are moved. The cleansing exercise also provides an occasion to review conflicts data, since a clean client list improves the reliability of every future conflict search. It is slow, unglamorous work, and it is easily underestimated. A firm should allocate real hours to it and should not leave it to the final week before go-live.

Verify after migrating

After migration, sample the results. Select a number of matters at random, and compare the migrated record with the original: client details, key dates, document counts, and any trust or client account balances where applicable. Record the checks and the outcome. Any discrepancy found in the sample suggests a systemic problem that should be investigated before the old system is switched off.

Retain the old system for a defined period

The old sources should remain accessible, in read-only form where possible, for a stated period after go-live. This reassures staff and provides a fallback, but it must have an end date. An indefinite overlap is how parallel systems become permanent.

A phased implementation programme

A phased approach reduces risk and builds confidence. The following structure suits most solo practitioners and small firms.

Phase one: foundation

Appoint the project owner, confirm the requirements, and configure the essentials: users and permissions, client and matter structures, the standard matter types, and basic document templates such as the engagement letter. Resist the temptation to configure every possibility. Prepare the migration dataset and complete cleansing.

Phase two: pilot

Run the system with a small group, perhaps one attorney, one assistant and the accounts function, on a limited number of new matters. A pilot exposes configuration errors and unclear procedures at low cost, and produces a group of informed users who can support colleagues afterwards. Collect the group's difficulties in a log, and resolve them before wider release.

Phase three: go-live

Move the whole firm on a defined date, preferably at a quiet point in the firm's calendar and not immediately before a major court term, closing or filing deadline. Establish that, from that date, new matters are opened only in the new system, and that existing live matters are migrated according to the plan. Make support visible: someone should be available during the first weeks to answer questions promptly, since small frustrations unanswered in the first fortnight harden into attitudes.

Phase four: consolidation

After go-live, review use at regular intervals. Introduce further features one at a time, only when the basic workflows are stable. Retire the old sources on the date announced. Use the pilot group and a user forum, even an informal one, to collect suggestions.

Training that is retained

Training should be shaped around tasks, not features. Staff do not need to know every menu; they need to know how to open a matter, record time, store and retrieve a document, send a document for signature, and produce an invoice. Training should therefore follow the firm's own workflows, using realistic examples from the firm's practice.

Train close to go-live, and repeat shortly afterwards, when staff have real questions.
Provide short written guides, one page per task, in the firm's own language and with the firm's own screens and examples.
Identify champions within each role group who can help colleagues informally.
Treat the least confident users as a priority, offering individual sessions without embarrassment.
Train the principal as thoroughly as anyone else, and ensure that the principal is seen to use the system.

Governance, policy and the human element

Technology adoption needs a short set of rules that are actually enforced. The firm should record, in a document of a page or two, what must be done in the system, by whom, and when. Examples include that every matter must be opened with a conflict check before work begins, that all client documents are saved to the matter and not to a personal drive, that time is recorded daily, and that correspondence is filed to the matter within an agreed period. These rules should be adopted by the principal and applied without exception.

The human element deserves explicit attention. Resistance is usually rational from the individual's point of view: the new system takes time to learn, exposes work to scrutiny, and may appear to threaten a person's role. Addressing these concerns openly, explaining the benefit to each group, and acknowledging that productivity will dip briefly after go-live, is more effective than insisting. Those who master the system early should be recognised, and difficulties should be treated as information about the design of the process, not as evidence of personal failing.

The firm should also consider how the system affects client relationships. If a client portal or e-signature function is introduced, clients should be told what to expect, and the firm should confirm that its engagement letters and privacy notices accurately describe how client information will be handled.

Measuring adoption and deciding what to do next

Success should be measured by use, not by the existence of a licence. Some practical indicators include the proportion of new matters opened in the system, the proportion of time recorded within an agreed period of its being worked, the proportion of client correspondence stored to the matter file, and the number of workarounds or parallel records still found on review. Qualitative indicators matter too: whether staff say that they can find what they need, and whether the principal trusts the reports.

The following arithmetic is illustrative only and is not market data. Suppose a firm with ten staff finds, after three months, that eight of the ten use the system for all matter work, and that two continue to keep parallel records. The firm has eighty per cent adoption by headcount, but the more important question is which two are not using it. If they are the two most senior fee earners, the practical position is poorer than the figure suggests, because their matters are the ones that are incompletely recorded. Any measure should therefore be read in the light of who is not complying and why.

When indicators are poor, diagnose before acting. Establish whether the cause is training, configuration, a missing feature, a process that does not fit, or simple reluctance. Remedies differ accordingly. A firm should be prepared, in the last resort, to conclude that a product does not suit it, and should have secured contractual rights to export its data so that the decision can be taken without being held hostage by the cost of leaving.

Practical next steps

Write down, in no more than half a page, the specific problems the firm expects technology to solve.
Appoint a project owner with authority and protected time, and secure the visible commitment of the principal.
Prepare a short requirements document, including regulatory and data protection constraints, and note the number of users who will need access.
Test candidate products against two or three of the firm's own real workflows, and obtain written answers to the questions on data location, export, exit and support.
Decide what data will be migrated, archived or left behind, and allocate time to cleanse the migrated data.
Plan a pilot with a small group before firm-wide release, and select a go-live date away from major deadlines.
Prepare task-based training and one-page guides, and name champions in each role group.
Adopt a short written policy on what must be recorded in the system, and apply it to everyone, including the principal.
Set an end date for the old systems and for the overlap period.
Review adoption indicators monthly for the first quarter, and adjust configuration, training or process according to the diagnosis.

How practice management software supports adoption

Adoption is easier when a single platform covers the core functions of matters, clients, documents, signature and billing, because staff then learn one environment instead of several, and the firm does not need to rely on private workarounds. A platform such as Legalytech, priced per firm with unlimited users, also allows every member of the team to be given access from the outset, which removes the temptation to restrict use for reasons of cost.

This article is provided for general information only and does not constitute legal advice. Practitioners should consult the rules of their own jurisdiction and regulator.