The person who owns it now

The person I think about when I think about this engagement isn't the CEO and isn't me. It's their safety and compliance lead — the person who owned the part of the business the crews can't go out without, who came into the project as a subject-matter expert because somebody had to explain how the work actually happened, and who by go-live was running walkthroughs I wasn't on. He put his commitment in writing to the whole company before we cut over, and he'd cleared his own calendar to do it. That's not a detail I'd usually put in a case study, but it's the one that explains everything after it.

Where they started

About three-quarters of the operation ran outside any system. Jobs were scheduled and re-scheduled across crews by phone, text and chat threads; the app they had for job management couldn't be changed, so people had built their own ways around it; and quoting had to carry real cost-to-margin — what a day of work actually costs to deliver — when the tools only knew how to hold a flat rate. None of that is unusual. What was unusual was how much of the business was being held in a few people's heads, and how well it was working anyway. The system wasn't broken so much as absent, and the people were carrying it.

What we built, with them

I'd rather describe this by what it does than by what it is. One record per job, and everything the job touches hangs off it — the quote, the days of work, the people and equipment allocated to each day, the invoice at the end. Pricing comes from cost, gets marked up by rule, and if a coordinator overrides it the system asks why and keeps the answer. The people doing the work have their own way in; the office was never the only user. Each role sees the job in the shape it needs, and the requests that used to be a message in a group — supplies, changes, problems on site — are records someone owns. We modelled all of that before we built any screen, and the screens were the easy part once the model held.

How we did it

We went to the field first. I asked the people doing the work what they actually did, and whether they kept a spreadsheet somewhere, and why — because the spreadsheet is the most honest description of the process you're going to get. Somebody built it to get through their day when the system couldn't.

We cut over the office and the field app together, on one morning, and we kept the old chat channel open for the first month on purpose. That was a choice, not a compromise; a backup you've said out loud is a backup people stop needing, and one you've banned is one they use quietly. The rules the business already had — who can be booked, what has to be in place before a job starts, when it's ready to bill — now get enforced by the system instead of remembered by a person. And their admin was in the room for all of it. Walkthroughs, not handovers.

What changed

It went live at the start of August and it has been live and stable since. The crews can't start a job without it now, which is the plainest test I know of whether a system became the operating layer or stayed beside it. A revised, signed job reconciled to the penny. The CEO joined a call he didn't need to be on to thank the team for the months of work, unprompted. And their own account manager is now building profitability and forecasting on top of the data, which we never built for. That's the outcome I'd point at: the platform holds their business well enough that they can ask it questions we didn't anticipate.

What I'd do again

The first thing I'd do again is go to the people in the field before I touched anything, and ask them what they actually do — and then ask whether they keep a spreadsheet somewhere, and why. The spreadsheet is never the problem. It's the most honest description of the process you're going to get, because somebody built it to get through their day when the system couldn't, and most of what we ended up building was already sketched in one of those.

The second is modelling the business before building any surface. The hardest part of this one was connecting what got quoted to what got delivered to what got billed, because those are three different shapes of the same job and the old tools had let them drift apart. We spent real time arguing about which record should carry what, and once we agreed — the work carries what a day needs, the money sits on the lines, and one container just holds the relationships — the implementation got simpler, not harder. I'd have that argument again. What I'd say now, though, is that you cannot define that process from the outside, and neither could they. There was no process for reconciling a job because there had never been a system to reconcile it in. We had to build enough of the thing for people to see it and touch it, and then write the process for what they were now able to do — which is the opposite of the order a specification wants.

The third is keeping their admin in the room for all of it. He came in as the safety and compliance lead, not as an IT person, and by go-live he was running walkthroughs I wasn't on. That's the whole point of the engagement as far as I'm concerned. A build that only works while I'm in the account hasn't finished; it has just changed who the bottleneck is. The thing I didn't expect was how fast the trust moved — about a month in, the team stopped checking the numbers against anything else, from the first inquiry through to the invoice. Nobody announced that. It just stopped happening, and that's what I'd point at if you asked me whether it worked.

Who did the work

This was delivered with a prime partner who held the client relationship and built the reporting on top, and a methodology partner who carried the architecture and the change management. I was the builder. It wouldn't have been the same engagement without either of them.