Repaired an Enterprise Budgeting Tool at a Fortune 50
A national insurer ran its yearly budgeting on one tool used across more than 100 locations. The year I took care of it, the systems under it had changed. I could have torn it out and built a new one. Instead I worked with what was already there and fixed what was broken, so every location kept running.
A budgeting process that every location in the company depended on kept running, even though the systems under it had changed. No one had to relearn it. Nothing broke. The cycle finished on time.
I did not come in to tear the tool out and build a new one. I worked with what was already there and made the change that was needed. That is the thing I want you to know about how I work. There is a whole range between fixing what you have and rebuilding it from the ground up, and the right answer lands somewhere different every time. My job is to read your situation and pick the point on that range that actually serves you. This time, that meant keeping what worked and fixing what was broken, so your people were not left with something they did not trust.
A tool behind 100+ locations, and the ground under it had shifted.
A Fortune-50 national insurer ran its yearly budgeting on one Excel tool. More than 100 locations used it. Each location planned its next year in the tool, department by department, and those plans fed a request that another team reviewed and funded. This was not a simple spreadsheet. It walked each person through the steps, pulled last year's numbers from the company database, sorted every line to the right department and location, and showed each person only what they were allowed to see. I came in for the summer to get it ready for the new budget year. The problem was that the systems under it had changed, so last year's version did not work anymore. It had to be fixed to keep running, in every location, without making life harder for the people who used it.
I did not rebuild it. I fixed what was already there.
I did not build this tool. It was already in use across the whole company when I got there. My job was to learn it, fix what the system changes had broken, and keep it running. So I taught myself the language it was written in, Excel VBA, from scratch. The workbook held more tabs than could fit across the screen, and behind them sat a sixty-page printout of code. I read it line by line until I understood how it pulled the data, sorted it, and guided each person to a finished budget.
My first thought was to make it better. I rebuilt a few sections and made them cleaner than I found them. Then I stopped. The job was to keep it working everywhere. The people using it did not like surprises, and the one full-time person who watched over it had to be able to fix it after I left. A new version that no one trusts is worse than a steady one that everyone can run. So I changed my approach. I kept the parts that worked, stayed inside what the users already knew, and changed only the pieces the system change actually forced me to. Then I made sure everything still added up against last year's numbers.
The hard part was knowing what to leave alone.
The hard part was never the code. It was knowing what to change and what to leave alone. Every project sits somewhere on a range, from fixing what is already there to rebuilding it from scratch, and a job like this one sat far toward the careful end. Just because I could rebuild the whole thing did not mean I should. A big change in a large company costs more than the work itself. People have to be retrained. Things break in new places. And the team has to trust the tool enough to keep using it after you walk out the door. Spread that across 100+ locations, and a full rebuild becomes the risky, expensive choice. Working with what was already there, and fixing only what was needed, kept the whole thing steady.
That is how K1 works with a company's systems today. I am not tied to any one tool or trade, and I am not tied to one way of solving things either. Sometimes the answer is a clean rebuild. Sometimes it is tying into what you already have. Most of the time it is somewhere in between, and the skill is reading which. I learned that inside a Fortune-50 insurer's budgeting system, where the right answer was to keep what worked and fix what was broken, and I have used that judgment on every system I have touched since.
Have something that looks like this pattern?
Free. 15 minutes. I will know in the first 5 if I can help.