The Quote I Signed Off On, One Year Ago
Last night I pulled a quote out of the second drawer of my office desk — the one I'd sent up for approval a year ago. The corner of the page was slightly folded, and in the upper left, my hastily scrawled signature still read "Approved / 2025-08." Next to the numbers there was a highlighter underline an executive had drawn that day. I remember him asking, "Is this everything?" I answered, "Yes." Looking at it again now, I can see exactly where that answer went wrong.
If the four-line scorecard from the previous post was a tool for getting past the approval meeting, this post is about what happens twelve months after you clear it. Approval is the starting line — the twelve months that follow are what determine the true shape of the quote.
Actual vs. Projected — Dev Cost Was Right; What Came After Wasn't
Development cost itself landed roughly inside the projected range, with a margin of error around 10%. Surprisingly, this is where things don't go badly off. The problem came next. Ops, retraining, integration, and monitoring quietly ate away 25 to 40 percent of the initial quote. Domestic reports treat 20 to 40 percent of dev cost recurring as annual ops as a normal range. A Flexera survey found that 79% of companies exceeded their AI budget over the past twelve months.
The more painful part is how often the projection missed. Between 80 and 85 percent of respondents were off on their AI infrastructure budget by more than 25 percent. Only one in four companies could see in real time how much they were spending. The rest wait until the quarter closes to be surprised by the bill.
A Gartner survey released this past April found that among AI use cases, 28% fully met ROI expectations while 20% failed outright. The remaining half sit in a gray zone. Laying the quote back out on the desk, I can see we spent a stretch of time wandering that same gray zone.
Three Lessons Left Standing After a Year
What sticks with you, alongside the specific numbers, is really just a handful of sentences. If I were starting over, what would I do differently? Three things come to mind.
First, it shouldn't have been "start small" — it should have been "run it small." A PoC succeeding and a PoC running every day are two different things. The integration layer, log monitoring, the retraining pipeline, an internal helpdesk — those four quietly add 25 to 40 percent onto the starting price. The PoC budget sense we covered in Part 2 is a tool for asking "does it work?" — not "is this sustainable to run every day?" If I did it over, I'd carve out a separate three-month operations-simulation budget from day one, entirely apart from the PoC budget.
Second, the number on the approval sheet needs to be redrawn as a three-year total. Slicing it at one year distorts things badly. Year one is typically the period where costs are overstated and results are understated. Initial integration costs concentrate in that year, while the learning curve pushes results out. Recalculate on a three-year horizon and the quote's whole expression changes. This lines up precisely with domestic observations that most projects take one to three years to realize results. Take the ops cost we covered in Part 4, add it three times, place it side by side with dev cost, and walk into the approval meeting — the executive's question itself changes.
Third, "ownership" turned out to be far more expensive than "model selection." This was the most unexpected finding. Early on we burned weeks on which model to use, build vs. API. But looking back a year later, the spots where budget leaks show up are always integration — before or after the model, never the model itself. Global surveys report the same: 68% of AI projects stall at integration, not the model. And the reason they stall at integration is usually not technical — it's ownership. On projects where a business sponsor and a technical sponsor aren't both named on paper, no one treats the budget leak as their own problem.
The One Sentence Running Through the Six-Part Series
Across the six posts of this series, I covered budget sense, the PoC, in-house LLM vs. API, ops cost, the ROI scorecard, and today's retrospective. It looks like six topics, but the sentence left standing after writing them all was one. AI adoption is not a technology decision — it's a budget decision, and the budget decision, in the end, was about ownership.
Honestly, I didn't have this conclusion in hand from the start. When I was writing Part 1, I still thought this was a series about "how to size a budget well." As the posts stacked up, the point of view drifted sideways. That naming the person accountable for a number, right next to it on the approval sheet, matters more than getting the number itself right — this was something I saw over and over in the reactions from a handful of teams who took last post's scorecard back into their own work.
A year from now, when you pull this series back out of the drawer and want no regrets about the decision, start by writing two names on the approval sheet — right next to the numbers, today. A business sponsor and a technical sponsor. If those names are blank, no matter how carefully the numbers on the quote are drawn, there will be no reason to pull it back out a year later.
If there's room to run a retrospective workshop together, or to recalculate the three-year total cost with us, a 30-minute conversation is one way to start. Redrawing the approval sheet doesn't take long.