Why Some Systems Transform Firms and Others Collect Dust

You've probably seen it happen. A firm invests in a law firm management system: case management, billing, document automation, the works. Six months later the team is still coordinating on WhatsApp. The accountant still keeps a separate spreadsheet. Someone still prints the cause list every morning. The system is there and it is running, but nobody is living inside it.

Then there's another firm of similar size, practice areas and budget, where the system has changed how work gets done. Deadlines don't depend on memory. Client communication is consistent. Billing is accurate and on time. The team trusts the platform because it reflects how they actually work.

Same category of software, very different outcomes. What made the difference?

What the research says

The Standish Group's CHAOS report, one of the most comprehensive studies of technology projects, analysed over 50,000 projects globally and found that 66% end in partial or total failure. Two out of every three. Not because of bad technology or thin budgets. The software worked. The money was there.

KPMG found that 70% of organisations suffered at least one project failure within a twelve-month period. McKinsey found that 17% of large IT projects go so badly that they threaten the existence of the company. Perhaps the most telling number: 45% of features built into software projects are never used.

IBM studied over 1,500 change practitioners worldwide to understand why. The answer wasn't technical. The biggest barriers were human: changing mindsets and attitudes (58%), corporate culture (49%) and lack of senior management support (32%).

The researchers noted that these challenges were flagged as harder to solve even when given sufficient resources. Money doesn't fix them. More features don't fix them. Only human commitment does. That is the dividing line between systems that transform a firm and systems that collect dust.

How a law firm management system becomes a filing cabinet

It usually starts with good intentions. A managing partner recognises the firm needs better systems, researches the options, sits through demos and approves the investment. The software is installed. The team is trained. Then daily life takes over.

The managing partner, the busiest person in the firm, steps back into their caseload. The associates attend training but return to the habits they know. A senior partner asks for something printed because that is what feels reliable. Someone starts a WhatsApp group for a matter because it is faster than learning the task module. The accountant keeps the Excel sheet running alongside the billing system, just in case.

None of these decisions feels wrong in the moment. Each is a small, rational response to time pressure. But they accumulate. Within months the firm is running the new system alongside all the old ones: WhatsApp groups, printed documents, Excel sheets, email chains, physical diaries. Not two systems but eighteen parallel ones. More complexity than before, not less.

The system didn't fail. It was never fully adopted. The firm bought a new tool and continued to think in the old one.

Why law firms are especially vulnerable

This pattern can happen anywhere, but law firms face a combination of pressures that makes it almost predictable.

Everyone is stretched. Managing partners carry enormous responsibility. Associates juggle multiple matters. Support staff keep the firm running hour by hour. Finding real, focused thinking time for a technology project is a sacrifice. The people who most need the system to work are the ones with the least time to invest in making it work.

The profession rewards caution. Lawyers are trained to verify, to document, to rely on precedent. When a partner says "I need a printed copy", it often reflects a legitimate professional instinct: physical documents feel verifiable and defensible. In Kenya, where many court processes still require physical filing, that instinct is frequently correct. It's wisdom, not stubbornness.

Trust is earned through experience, not installation. When someone prefers their WhatsApp group to an automated reminder, they are making a reasonable judgment: "I trust a human response more than a notification from something I haven't fully learned." The system has to prove itself through daily reliability before it can replace the habits that currently keep the firm safe.

These aren't obstacles to be bulldozed. They are realities to be respected and designed around.

What makes the difference

If the research points to one thing consistently, it is this: the systems that transform firms are the ones where leadership stayed involved. Not as a sponsor who approved the budget, but as a participant who helped shape what the system became.

This doesn't mean a managing partner needs to become a technologist. It means being present, at least periodically, when the important questions are asked:

• What are our firm's values, and how should they show up in our daily workflows?
• What does consistency look like across our practice areas?
• How do we want to handle client communication?
• What policies should the system enforce, and which ones are we not enforcing today?
• Where are we losing time, trust or talent because of gaps in how we work?

These are leadership questions, not technology questions, and only the people who carry the firm's vision can answer them.

The system then becomes the mechanism that holds those answers in place: daily, consistently, without fatigue. It isn't the software that transforms the firm. It is the policies and values embedded in the software. Those have to come from the firm's leadership. No vendor can invent them for you.

What a transformed firm looks like

When leadership invests the time and the firm embraces the change, the results are quietly remarkable.

A new client walks in. Their information is captured once, at the point of contact, not scribbled on paper to be entered later. A matter is opened, linked to the client, assigned to an advocate and structured around milestones that reflect how the firm actually delivers its services. Every instruction from the client is logged with dates, details and the responsible person. Nothing depends on someone remembering.

A deadline approaches. The system surfaces it, not as a notification that fires into the void but as part of a visible workflow where the team can see what is pending, who is responsible and what has been done. The managing partner doesn't need to chase anyone on WhatsApp.

A bill goes out. It is generated from work recorded against the matter, guided by the fee structures the firm has set, with a complete audit trail. The accountant isn't reconciling three spreadsheets. There is one source of truth.

And when a new associate joins, they don't spend weeks working out how things are done by watching and guessing. The system itself teaches them the firm's processes, standards and expectations. The way the firm works is documented in the workflows they use every day, not in a manual that sits in a drawer.

This is what happens when a firm treats technology adoption as a practice transformation rather than a software installation.

The partnership that makes it possible

The firms that succeed don't just buy a system. They enter a partnership, and the process usually looks like this.

It starts with understanding: an honest assessment of how the firm operates today. Not a features checklist but a conversation about workflows, pain points, practice areas and culture. What's working, what's breaking, and what do the partners care about that isn't being enforced?

Then comes configuration, working alongside someone inside the firm who understands the daily reality of the practice, to shape the system around how the firm actually works. Not a generic template. Not best practices borrowed from a firm in London. The firm's own processes, made visible and consistent.

Then comes the hardest part: the transition. Changing habits. Learning to trust the system over the workarounds. Having the managing partner reinforce the new way of working rather than approve it from a distance. This phase takes patience, support and commitment from both sides.

The firms that get through this phase are the ones that transform. The firms that skip it are the ones whose systems collect dust.

How I ended up here

I didn't start my career in legal technology. I never even thought it existed. When a client first approached me with a legal tech project, I was reluctant. I told her I didn't understand it and didn't want to do it, and let her go and get it elsewhere. She did. She came back. I said no again. She came back a third time.

Maybe she saw something in me that I didn't see in myself. But I didn't finally say yes because I suddenly understood legal tech. I said yes because I could see her business was suffering and I wanted to help. I also needed real assurance that she would give her all to the project, because to me this was more sacrifice than business opportunity. I was in the middle of parallel projects. I didn't care how much she would pay me. What I cared about was whether she truly needed this and was willing to do what it would take.

She had already tried twice with other providers and failed. She was desperate. I did not want to be the third failure, the one that would ruin our friendship and damage her business beyond recovery. Budget wasn't her problem, and my technical ability wasn't the obstacle either. The obstacle would be communication, commitment, patience and the willingness to change.

So before we wrote a single line of code, I asked for something unusual: a four-hour meeting. Tuesday, 8am to 12pm. For an advocate of her standing that was a serious stretch; an advocate will almost never give you that kind of uninterrupted time. But I needed to understand what mattered to her, not just what she thought she wanted in a system.

Before that meeting I sent her a thirty-page document. Not a proposal. Not a quote. A framework for thinking through what we were about to build together. And I insisted on one principle from the start: systems are built by engineers, but they are architected by those who need them.

Contracts are important; they protect interests. But sometimes they are also one of the biggest obstacles to real partnership. What held this project together wasn't a legal agreement. It was a mutual promise to show up.

The first few months were overwhelming for her. This is where I learned something that changed how I work. As developers, we instinctively want to abstract everything: simplify, hide the complexity, make it easy. That is often where we fail, because when you shield your client from the process they never develop a relationship with what you're building. When you develop with them, when they are in the room making decisions and seeing the system take shape around their own thinking, something different happens. They develop a sense of ownership. Once something tangible is up, they embrace it naturally.

All I did as an engineer was write the code. My client decided she wanted the button green, not blue. She wanted a task called an "instruction", not a "task", because that is what advocates call it. She dictated almost everything. The system became hers, not mine.

Seven months later the project was done. What started as a sacrifice turned into a business opportunity and a masterclass in building systems that people actually want to use.

But is it sustainable? Can you do this with two hundred firms? Honestly, no, not at scale. That is where the philosophy behind SISU OPUS came from: one law firm at a time.

When I went back over my failed projects, the pattern was undeniable. It was never about money; I've been fortunate to work with clients for whom an invoice is never a point of contention. It was about time. The decision-makers who signed the cheque and disappeared were the ones whose systems collected dust. The one who stayed in the room and fought through the discomfort of changing how her firm operated was the one whose firm was transformed.

Before you decide

That experience, and every project since, taught me that the questions worth asking before a technology investment have very little to do with technology. Whether you work with us or someone else, these are the ones I'd invite you to sit with.

What problem am I actually trying to solve? Not "go digital"; that is a direction, not a problem. What specific friction, risk or inefficiency is costing your firm right now?

Am I ready to invest my own time? Even a few hours a week, consistently, over months? The managing partner's presence, even periodic, changes the trajectory of a project.

Have I thought about the policies and values I want this system to enforce? Technology is a container. What matters is what you put inside it.

Am I prepared for the discomfort of changing habits? Mine, my partners' and my team's? Ways of working that have been good enough for years will be challenged. That is uncomfortable. It is also where transformation begins.

Am I willing to help build this, rather than only approve it? The systems that work are the ones where the people who need them helped architect them. A green button instead of blue. An "instruction" instead of a "task". These details seem small, but they are the difference between a system your team tolerates and one they embrace.

If these questions energise you rather than exhaust you, if reading them makes you think yes, this is the kind of thinking our firm needs to do, then you are ready, and not only to buy a system. You are ready to build something that changes how your firm works.