Operations & change
A decade inside Dutch law firms
2004—2014 · Netherlands
€80,000/year
Cost removed from the back office
13 people
Carried through the transformation
The situation
Two Dutch law firms, ten years, and the same underlying problem in both: the work was being done well and the machinery around it was not keeping up.
Law firms make this unusually visible. Fee-earning time is measured to the minute, so anything that interrupts it has a price everyone can see — which means change has to be planned around the work rather than imposed on it.
This is where the method came from.
What I did
Kolkman Solicitors, 2004–2007, as project manager. A firm-wide platform migration: a new office and case-handling system taken from requirements and vendor selection through data migration, staff training and post-implementation optimisation.
The constraint was the whole design. The roll-out had to happen with minimal disruption to fee-earning work, so sequencing mattered more than speed. I led the change management and delivered the training across the firm — which is to say I was still there after go-live, which is the part that decides whether a migration worked.
Holthuizen Solicitors, 2007–2014, as process manager. I was recruited to do two things that are usually given to two different people: re-engineer the back office, and design and build the firm's custom legal-workflow software.
The re-engineering took €80,000 a year out of back-office operating cost. I managed a team of thirteen full-time staff through that transformation — the same people whose work was being redesigned.
The software went from requirements through to deployment, including case management and document management. Built for the process as redesigned, not for the process as found.
What changed
€80,000 a year, permanently, at the second firm. A system migration at the first that the fee-earners barely noticed. Thirteen people who came through a transformation still doing the work afterwards.
The more durable outcome is the shape it established. Map how it actually works, redesign it, build the thing that makes the new way permanent, then stay until people are using it. Seven years at one firm is long enough to find out whether that holds, and it did.
Everything since has been the same method in a different sector.
What I'd do differently
The system I built for Holthuizen still runs the firm today, fourteen years on. They still describe it on their website as how they work.
I used to read that as the whole point, and part of me still does — a system people are still using more than a decade later is the only proof of adoption that means anything. But it also means fourteen years of technology has happened around it, and I would very much like to take it forward. There is a version of that system built on what is available now that would do considerably more for them, and I would enjoy building it.
The thing I would design differently is not the software. It is what I left behind alongside it. I built something durable, and I did not build in the mechanism that keeps it current — no review cadence, no named owner on their side whose job it was to ask, every couple of years, what this should become next. When a system simply works, nothing prompts that conversation. It should have been prompted by design.
So: build it to last, and build in the reason to revisit it. I would still do the first. I would do the second properly.