Originally published on LinkedIn, John’s Corner is where Fortimize CEO John Hamon shares the perspectives, challenges, and hard truths he sees from the front lines. View original publication.
The budget conversation and the delivery conversation are two different conversations, and the implementation industry has quietly agreed to only have the first one in front of the customer.
Hourly rates are easy to compare. You can put two bids side by side and see which is cheaper. The way a partner actually runs the project is not easy to compare. Procurement does not score it because it cannot. The partner who has invested in disciplined delivery cannot charge a premium for it, because the line item does not exist on the comparison sheet. So the partner who has not invested in disciplined delivery wins the bid. Every executive who has watched a Salesforce project slip from 12 months to 24 already knows this. The industry has just agreed not to say it out loud.
What the rate card cannot see
A Salesforce contract is, on paper, an agreement to deliver a defined scope at a defined price by a defined date. In practice, it is an agreement about how the partner will respond when the project hits the moments no SOW can anticipate: the integration that behaves differently in test from expectations, the business rule the operations team did not know they had until it broke, the regulatory question that surfaces in week 16, and the data quality problem that was nobody’s job to find.
Those moments are governed by something the buying process refuses to look at: the partner’s delivery methodology. Not the slide about it. The actual operating process the partner’s teams use when week twelve goes sideways. Do they have one? Do their teams follow it? Have the people in the room actually run the process before?
Procurement cannot score this, so procurement does not ask.
There is also a question the comparison sheet does not ask, which is how the cheap bid is being priced in the first place? A senior solution architect with 15 years in financial services costs a firm a real number, and that number does not fit inside a discounted rate card. So the discount is paid for somewhere. It is paid for with junior staffing, or offshore staffing, or both. That is not a hidden agenda. It is the business model showing through. A junior team takes 4 hours to do what a senior team does in 1. It needs 3 clarification cycles where a senior team needs none. It cannot push back on a bad requirement because it does not have the pattern recognition to know the requirement is bad. The lower rate buys you more hours, more rework, and more meetings to explain what should not need explaining. The line item that looked cheaper on the spreadsheet was always going to cost more on the invoice. Procurement cannot see this either.
The buying process selects the bid most likely to fail the work, in a category where independent data shows fewer than 1 in 3 projects succeed, and large ones succeed less than 1 time in 10.
What it costs you when it fails
That selection has consequences, and they are not the ones the comparison sheet was built to surface. A few years ago, the CAO of a Texas credit union walked into a situation her predecessor had signed up for: a loan application platform, built by the partner who had won the competitive bid, that did not work. It did not fail all at once. It failed in the way these systems fail: crashes that became routine, errors her team learned to work around, manual workarounds that became part of the job description. By the time we walked in, her loan officers had built a shadow process in spreadsheets, members were waiting longer than they had before the project started, and the line on her income statement that was supposed to grow was flat.
That was years ago. The pattern is not. I have watched it 3 times in the last 15 months, in 3 different verticals. A retail real estate firm whose tenant portal was 8 months past its go-live date when the partner was finally dropped. A nonprofit whose Salesforce build was so misarchitected that the assessment to fix it recommended starting over. A wealth management prospect that has now evaluated the same Marketing Cloud product 3 times, with 3 different partners, and has refused a fourth attempt because the institution no longer trusts itself to choose well.
The Texas credit union did not write off “trust.” It wrote off months of loan officer productivity, members lost to a competitor whose application worked, and a fee income trajectory that was supposed to fund the next hire. The retail real estate firm did not write off “an eight-month delay.” It wrote off the leasing season the portal was supposed to enable. The nonprofit is not writing off “a bad implementation.” It is writing off the operational program the system was supposed to run.
What the numbers say when you can find them
The implementation industry does not publish its failure rate, for reasons you can guess. The independent data is unkind. The Standish Group’s longitudinal study of IT projects finds that only 31% are fully successful: on time, on budget, and with the features promised. For large projects, the success rate drops below 10%. Half are challenged, meaning they go live with reduced scope or missed objectives. The remainder are canceled outright. McKinsey’s study with the University of Oxford of more than 5,400 large IT projects found average overruns of 45% on budget, 56% less value delivered than predicted, and 17% that went so far off the rails they threatened the survival of the company that bought them. Every additional year added 15% to the cost overrun.
If you think your institution is the exception because it operates in financial services, the data gets worse. IBM’s 2025 survey of banking CIOs found that 94% of core banking modernization projects exceed their planned timelines, and fewer than half of those CIOs reported meaningful gains in efficiency or customer experience after the work was done. Heavy investment, modest return, almost always late.
The reason these numbers matter to the procurement spreadsheet is that the spreadsheet is the wrong instrument for the problem. A 2022 academic analysis of large IT projects found that cost overruns do not follow a normal distribution. They follow a power-law distribution, the same distribution that describes earthquakes and stock market crashes. Most overruns are modest. A non-trivial minority are catastrophic, with mean tail overruns of 450% or more. The procurement spreadsheet assumes a symmetric range of outcomes and prices the bids against the middle. The real distribution is asymmetric, and the tail is where the money is destroyed.
If you want the same numbers at retail bank scale, look at TSB Bank, whose 2018 core banking migration cost roughly $440 million in customer compensation and emergency staffing, drove out the CEO, and sent 80,000 customers to competitors. That outcome was in the tail. The tail is where the math says some projects will land. The bid most likely to put your institution there is the bid that looked cheapest on the spreadsheet.
Now apply that geometry to your institution. The cheap bid is the slow bid. The slow bid is the compounding-overrun bid. The compounding-overrun bid is the bid that converts a one-year project into a two-and-a-half-year project. The rate card showed you the first number. It did not show you the second, because the spreadsheet your procurement team built was not asked to compute it.
The version of this that works
There is a different way to buy this work, and it is already working for institutions willing to ask the question their buying process is structured to avoid.
The model is called Delivery as a Service. The contract is written against goals, not against a 200-page scope document drafted before anyone knew what they actually needed. The team is capacity-based, not time-and-materials. Changes are absorbed by the model, not penalized through change orders. Prices are published, not negotiated through a procurement back-channel. Exits are flexible, not 18-month lock-ins. The people doing the work are the people you talk to.
Time-and-materials projects pay the partner more when the project takes longer. The incentives reward delay. Plain-language, capacity-based contracts pay the partner the same whether the project takes 10 weeks or 14, so the incentives reward speed and clarity. The customer ends up with a system their team will actually use, on a timeline their CFO can plan against, for a price their board can defend.
We rebuilt our delivery model recently, after more than a decade of watching the standard model fail clients we cared about. Our on-time, on-budget rate under the new model is 97.8%. Our average customer stays with us for more than 3 years. Those numbers are not vendor marketing. They are the comparison number to the McKinsey 45% overrun above. The industry distribution and the firm distribution should not look the way they look. They do, because the model is different, and the model is different because we stopped running the one that was failing the people we work for.
What to do with this
If you are about to put a Salesforce implementation out to bid, ask one question of every partner on the shortlist that procurement will not have asked for you. Send me your delivery methodology. Not the marketing version. The operating document your project teams actually use. Then ask one question of every reference: what did the partner do when the project hit the moment no SOW had anticipated?
The answers will rank your bids in an order procurement’s spreadsheet did not. That order is the one your income statement will be ranked by 6 quarters from now, whether you score it today or not.
Related: Salesforce Solutions for Real Estate
