The change process that ran itself
The situation I walked into
At a large business I worked with, the whole process for controlling and costing project changes ran on two Excel spreadsheets. One big sheet tracked the changes across the project. A second sheet, sitting alongside it, held the detail behind each one. Every time a change came in, someone had to open both files, type the change in by hand, work out which budget line it belonged against, and put it in the right place. Then they had to make sure the paperwork underneath, the documents, the drawings, the costs, still lined up with what the sheets now said.
It worked, because the people running it were good at their jobs and held it together. But it was fragile in two ways that mattered.
The first was obvious. The entire change process for live projects worth a great deal sat in two files that one wrong keystroke, one mis-typed code, one row deleted by accident could quietly break, and nobody would know until much later.
The second was subtler, and it is the one most businesses share. The process only really engaged with a change once it had already been approved. The early part, spotting a change coming, warning the client, building up the detail before anyone signs anything off, was happening in people's heads and in emails, not in the system. So the business could tell you what it had agreed to. It could not reliably show you what was coming, or the working behind how a change had been priced. That is not a criticism of anyone. It is what happens when a business grows faster than the systems underneath it, and good people simply keep it moving.
What I did
I designed a proper change-control system to replace the two spreadsheets, and a small development team built it to that design. The idea was simple to say and harder to do. A change should flow through one controlled route, from the first early warning all the way to the final sign-off, instead of being retyped across a set of files that only a few people fully understood.
Three things made it work.
First, every change went onto a standard template that captured the hours, the time and the cost against the actual pieces of work it affected, not a rough number typed into a cell. That gave you the real detail behind a change before it was ever approved, not after.
Second, that template was tied to a common coding structure, one shared set of codes the whole business used. So the moment a change was logged, it landed against the correct budget line automatically, instead of someone deciding by hand where it should go. The same codes ran through the plan, the documents and the costs, which meant a change moved through all of them joined up rather than being re-entered in each place.
Third, the planning side fed the same structure, and the master register of everything the project owed, and where each item stood, generated itself off the back of that. The register kept itself current as work happened. Nobody had to remember to update it after the fact.
So a change now flowed one way. Someone spots it internally. The manager agrees it is real. An early warning goes to the client before any money is committed. The client says scope it. The detail gets built on the template. It goes back for sign-off, the client accepts or declines, and if it is accepted it flows straight into the cost, the plan and the documents, coded correctly, on its own. One route, every time.
By the time I left, that system was live and fully operational, running the change process across real projects at full tilt. It no longer depended on two spreadsheets and the two or three people who knew how to hold them together.
The outcome
The fragile part was gone. A change ran through one route, coded correctly, with the register and the costs following on their own. Just as importantly, the business could now see change coming instead of only recording it after the event.
The knowledge that used to live in a few heads and two files now lived in the process itself. On one project the same discipline let us stop treating every single change as its own little project to be tracked separately, and instead fold each approved change back into the one plan under the same codes. What had been chaos to keep on top of became one clear picture.
That is the real win. Not that it was faster, though it was. It carried on working the same way whether the people who built it were in the room or not.
What it means for you
Most owner-led businesses have a version of those two spreadsheets. A process that only really works because you personally hold it together. You know the order things go in, you catch the errors before they bite, you remember the exception, you carry the detail in your head. It runs because you run it.
That is not a failing. It is what happens when you build a business and carry it in the early years, because there is nobody else to. It only becomes a problem when you want to step back, take a holiday without your phone, or a buyer starts asking what happens to all of that if you leave. The fix is the same one I put into that large business, scaled down to fit yours. Get the process out of your head and the spreadsheets, and into a simple system that does the same thing every time, so the business keeps running the same way whether you are there or not. That is the "Run without you" work I do with owners. If any of this sounds familiar, I am happy to talk it through.
The Ratio Check is a free, five-minute read on where your business actually stands, and it is the best place to start.