Why Data Must Come Before Systems

A paper on law firm data architecture and transformation sequencing. September 2025.

This paper is the second in a series. The first — “The Matter Lifecycle as Organising Principle” — establishes that a law firm TOM is, by definition, a matter lifecycle ecosystem design. This paper addresses what that requires architecturally before any system is selected.

If the matter lifecycle is the organising principle of a law firm TOM, two requirements follow before any system is selected or any design begins. First, the current state of the lifecycle must be documented — the actual process as it operates today, not as it is supposed to operate. Second, the firm must commit to owning its data independently of any operational platform.

Neither requirement is novel. Both are consistently skipped. The consequences are the same each time.

The Current-State Requirement

Every law firm that commissions a TOM programme has a functioning matter lifecycle already. It has to. A firm that cannot move matters from origination to billing is not a law firm — it is a collection of lawyers. The lifecycle works. Partners have made money, clients have been served, regulators have not intervened.

What does not work is the friction around it.

What friction looks like in practice

Friction in the matter lifecycle is not dramatic. It does not announce itself. It accumulates in the gaps between stages — in the handoffs that depend on one person being available, the data that has to be re-entered because two systems do not talk, the time entry that happens on Friday for work done on Tuesday, the billing narrative that requires three rounds of partner review because the draft was never going to be right first time.

In a firm of any scale, this friction has a measurable cost:

• Time to bill — the gap between work performed and invoice issued. Every day of delay is working capital tied up unnecessarily.
• Write-offs — time recorded but not billed because it cannot be justified to the client. Often a symptom of late or inaccurate time entry, not of overwork.
• Partner review cycles — the number of iterations a bill goes through before it leaves the firm. Driven by inconsistent narrative quality, billing guideline non-compliance, or data that does not match the client’s expectations.
• Compliance cycle time — how long the intake and AML process takes from instruction received to matter opened. In firms without integrated workflows this routinely runs to days for what could be hours.
• Exception handling — the proportion of matters that require manual intervention at any stage because they fall outside what the process can handle automatically.

STP — Straight-Through Processing — is the measure of how much of the lifecycle a firm can move through without manual intervention. It is not a measure of transformation success. It is a measure of friction. A firm with high STP has not transformed — it has removed the friction from a lifecycle that was already working. That is the correct ambition for a TOM programme.

Why current-state documentation is always skipped

The standard sequence in a law firm transformation programme is:

(1) Commission a programme (2) Select technology (3) Design future-state processes (4) Implement (5) Discover that the future state does not fit how the firm actually works (6) Remediate

Current-state documentation — the systematic mapping of every stage of the lifecycle as it actually operates today, in every practice group, with every variation — is almost never done before step (2). It is expensive, time-consuming, and unglamorous. It produces a document that describes what already exists rather than what will exist. Senior stakeholders find it difficult to fund.

It is also the most important work in the programme.

Without it, future-state design is built on assumptions about how the firm currently works. Those assumptions are drawn from interviews with people who describe how the process is supposed to work, not how it does work. The two are rarely the same. Partners describe the policy. Finance describes the system. Associates describe what they actually do. These three descriptions will not agree. Research published by the Harvard Law School Forum on Corporate Governance found that while 70% of legal executives report satisfaction with their current legal technology, legal operations professionals report that only 30% of team members are effectively using the available technologies, and 76% work outside the tools entirely. The people who commission systems and the people who use them inhabit different operational realities.

When the gap between assumed and actual current state is discovered at implementation — and it will be discovered — the programme faces a choice between redesigning the solution (expensive, time-consuming) or configuring the system to accommodate the actual current state (which means encoding the friction rather than removing it).

What current-state documentation must contain

For each stage of the matter lifecycle:

• The system or systems currently used — not the system that is supposed to be used; the system actually used, including manual workarounds and shadow processes
• The data inputs required — what information must exist before the stage can begin
• The data outputs produced — what information is created or modified during the stage
• The handoff mechanism — how does work pass from this stage to the next, and who triggers it
• The manual steps — what cannot currently be done by a system and must be done by a person
• The known friction points — where does the process slow down, fail, or require exception handling
• The compliance requirements — what must be evidenced, by whom, and by when
• The variation — does this stage work differently in different practice groups, for different matter types, or for different client categories

This is a discovery exercise, not a design exercise. Its output is not a recommendation. It is a map. The map is the specification from which everything else is derived.

The sequencing risk

Current-state documentation is typically scheduled as a discovery phase activity — positioned after mobilisation and before solution design. In practice, by the time discovery begins, the technology has already been selected, the implementation partner is already engaged, and the solution design templates are already loaded. Discovery becomes a validation exercise: does what we find confirm the decisions already made?

This is the wrong sequence. Current-state documentation should precede technology selection, not follow it. The discipline required: no technology selection, no solution design, and no integration architecture before the current-state lifecycle map exists and has been validated by the people who actually do the work.

Sources

• CLOC / Morgan Lewis, Matter Life Cycle Management, August 2022.
• Harvard Law School Forum on Corporate Governance, Change Management for the Legal Function, February 2023.
• John Watts, Why tech-driven legal change fails, LPM Magazine, October 2025.

The Missing Data Layer

Law firms think in two dimensions: people and systems. A transformation programme is typically a question about headcount and technology — who does the work, and what platform supports them.

Data is the missing third dimension. Not reporting data — dashboards, KPIs, management information. Operational data truth: who are the firm’s clients, what are the matters, who are the parties and related entities, what is the firm’s complete relationship history. The data that the matter lifecycle produces and consumes at every stage, from origination through to closure.

This data currently exists. It is not missing. What is missing is a firm-level commitment to owning it.

The data is trapped inside the systems that generated it

The practice management system holds the matter economics. The conflict platform holds the clearance history. The CRM holds the relationship intelligence. Each system owns the data that passed through it — and that ownership is incidental, not designed. Systems accumulate data as a byproduct of doing their operational job. None of them was built to be the firm’s authoritative data source. That role was inherited because the system happened to be the one everyone used, not because it was the right architectural decision.

The consequence: the matter lifecycle as a whole has no data home. Each stage is served by the system that manages it. The transitions between stages — where data must pass from one system to the next — are where the lifecycle fragments, where accuracy degrades, and where re-keying fills the gap that architecture should have closed.

The commitment required is not primarily a technology decision. It is a governance decision.

A system built for a specific set of operational requirements should not be forced into the additional role of firm-wide data master. Every operational system optimises for its own domain. When it is also expected to serve as the authoritative source of truth for entities the whole firm depends on, it does that second job poorly — because it was designed for the first.

The right answer is a dedicated data layer, governed by the firm rather than by any vendor, that holds the entities the firm needs to function as one firm: clients, matters, parties, relationships. Operational systems write to it and read from it. They do not own it. When a system is replaced or supplemented, the data remains with the firm. The matter lifecycle becomes, at that point, an architectural reality rather than a process description.

This is the foundation AI requires

The connection between data ownership and AI capability is not aspirational — it is mechanical. An agentic system cannot act reliably on data it cannot address. If client identity is distributed across systems with no common record, no agent can answer the question “who is this client, what is the firm’s complete history with them, and what does the relationship network look like?” with any reliability. The AI layer works when the data layer is coherent. It produces noise when it is not.

The sequencing implication

The data commitment comes before system selection, not after. A firm that selects its operational platforms first and attempts to build a data layer around whatever those platforms produce will find that the data model is inherited from the vendors, not designed by the firm. This is the same pattern that produces TOM programmes built around technology rather than around operating model: a platform selected first becomes the constraint on everything that follows.

The matter lifecycle is the organising principle. The data layer is what makes that principle operational.

The Commitment

The current-state requirement and the data commitment are not two separate prerequisites. They are the same work approached from different directions.

Documenting the current state of the matter lifecycle (the first requirement) reveals, stage by stage, what data the lifecycle produces and consumes, where it lives, who owns it, and where it is lost in the gaps between systems. That exercise is the foundation of the data model. The data commitment (the second requirement) is the decision to take that model and make it permanent — to give it a home that is not inside any operational system, that persists across system changes, and that the firm governs.

Together they amount to a single proposition: before any system is selected, the firm must know what it has, and it must decide who owns it.

This is a mindset shift as much as an architectural one. Law firms are accustomed to thinking about transformation in terms of people and systems. Adding data as a first-class dimension — not as a reporting concern, not as a technology afterthought, but as the operational foundation the lifecycle runs on — is the shift that determines whether a transformation programme delivers lasting change or delivers a new set of platforms that fragment the lifecycle in a new configuration.

The new skills this commitment requires are real. A firm that takes this seriously needs people who own the data: a Data Governor with the authority to make binding decisions about what the definitive version of a record is; a Data Manager who curates it day to day; and the engineering capability to connect operational systems to the data layer and keep them synchronised.

These are not technology roles. They are organisational roles, and in a partnership the governance question — who has the authority to say “this is the correct version of this client record” and have that be binding — is the hardest part of the commitment to make. The technology to support it is solved. The authority to govern it is the constraint.

Part of a series: see also “The Matter Lifecycle as Organising Principle,” “AI in the Matter Lifecycle,” and “Law Firm Transformation: A Practitioner’s Guide.”