Procurement: When the Lowest Price Wins, the Business Pays

There's a conversation most companies refuse to have. It usually happens after a technology project collapses — after the new system has been limping along for six months, after the vendor has cycled through three different account managers, after the CFO walks into a room and asks why the project cost twice of what was budgeted. Someone eventually gets blamed. And more often, that someone is procurement.

But, actually, procurement didn't fail. They did exactly what they were trained to do. The real problem is that nobody trained them correctly for this. In fact, their process is a silo, intentionally isolated.

Walk into almost any midsized or large company and you'll find a procurement team that is genuinely good at what it knows. They can negotiate hard on price, manage supplier relationships, enforce process compliance, and keep a paper trail that would survive any audit. These are real skills. They matter. But at some point over the last decade, someone decided that these same teams should also be responsible for evaluating enterprise software, cloud infrastructure, cybersecurity platforms, AI solutions, and SaaS contracts — without giving them any of the tools, frameworks, or training that those decisions actually require or even asking them to apply the same process as if they were purchasing cups or cookies for the coffee break. That gap between responsibility and preparation is where millions of dollars quietly disappear every year.

The data on this has been sitting in plain sight for decades, and it's really shocking when you read it. Research by McKinsey & Company on more than 5,000 large IT projects found that they run, on average, 45% over budget, 7% over time, and deliver 56% less value than expected. Let that last number sit for a moment. More than half the value that was promised, sold, and approved never materializes. The Standish Group found that only 29% of IT project implementations are considered successful, while 19% are classified as outright failures. And roughly 17% of IT projects run the risk of failing so severely that they threaten the very existence of the company undertaking them.

There's one more number that deserves its own discussion: 45% of features and functions built into software projects are never used. Nearly half. Specified, developed, paid for, and ignored. That's not a technology problem. That's an alignment problem — one that was baked in long before any code was written or any contract was signed.

Most people assume these failures happen because of bad technology or poor implementation. But the evidence points somewhere else entirely. The true origin of many IT project failures isn't in the circuits or the software. It lies in something far more fundamental: procurement. The process by which solutions are sought and acquired, even before any system is switched on or any software is deployed, sets the trajectory of the entire project. And when that process is driven primarily by price, the trajectory tends to bend toward disappointment.

This is where things get a little inconvenient. Because the "lowest price" instinct isn't irrational. It's the rational response to a system that rewards cost savings as the primary metric of procurement success. When a team is measured on how much they negotiated off the list price, they optimize for that. When the approval process requires three quotes and a justification for not choosing the cheapest one, they gravitate toward the cheapest one. The incentive structure produces the behavior — and then everyone acts surprised when the behavior produces bad outcomes.

What gets lost in that dynamic is an entire dimension of decision-making called Total Cost of Ownership. Gartner's research reveals that long-term IT ownership costs, including maintenance, support, and downtime, are frequently underestimated. Those who evaluate technology solely on acquisition costs often massively underestimate the true financial burden. Additional costs from accessories, licenses, and initial setup alone can represent between 20% and 30% of the total amount — and that's before you account for data migration, system integration, user training, technical support over time, and the operational disruption that accompanies any significant technology change.

Approximately 50% of software project budgets end up being spent on correcting errors after implementation. Half the money. Not on innovation. Not on scaling. On fixing what went wrong, which, in most cases, was predictable if anyone had known what to look for during the evaluation process. McKinsey reports that CIOs estimate technical debt accounts for between 20% and 40% of their entire technology estate's value before depreciation. That debt doesn't announce itself. It accumulates quietly through years of procurement decisions made without long-term vision, and it ends up throttling the company's ability to move fast precisely when the market demands it.

There's also a structural disconnection that rarely gets named directly. Procurement teams are, by design, separated from the strategic conversations where technology decisions get their context. They receive a requirements document, a budget ceiling, and a deadline. They don't sit in the sessions where the business problem was defined, where the expected outcomes were discussed, or where the technical constraints were mapped. They remain in the procurement silo, waiting for the same instructions they always receive: buy cheap. From the very start of a project, there is a significant dissonance between what the buyer wants, what they think they want, and how they communicate that to a vendor. And when the vendor enters the picture, they are not always incentivized to correct the buyer's mistakes. They are merely responding to a Request for Proposal. That's the trap in its purest form. A buyer who doesn't know what questions to ask. A vendor with no structural reason to clarify. A contract that formalizes the misunderstanding. And a project that launches with that misunderstanding built into its foundation.

Too many organizations stop at price comparisons and overlook integration costs, amortization, disruption risk, and working-capital drag. The result is a decision that looks brilliant on a slide and disastrous in the P&L. This isn't a criticism of procurement professionals, it's a criticism of the conditions they're asked to operate in. In many organizations, procurement expertise has eroded over the past decade. Seasoned experts retire and companies often don't backfill their ranks as part of broader administrative reductions — a move that appears penny-wise in the short term but proves pound-foolish over time. 

What actually works — and there's evidence for this too — is treating technology procurement as a strategic discipline rather than an administrative function. Companies that apply strategic sourcing approaches achieve savings of between 5% and 20% of total spending. And more pointedly: one dollar saved through strategic procurement is equivalent to $6.75 in sales revenue. The math on investing in procurement capability isn't complicated. It just requires someone to make the argument clearly enough that leadership listens.

That argument starts with a simple reframe. The goal of technology procurement isn't to find the cheapest vendor. It's to find the vendor whose solution will generate the highest return (ROI) at an acceptable risk level over a realistic time horizon. That's a different question than "who gave us the lowest quote?" It requires different skills, different evaluation frameworks, and a different conversation between procurement and the rest of the business. Technology procurement transformation cannot be left to procurement teams alone. End-user departments need to partner closely to establish priorities and problem-solve alongside their procurement colleagues, creating shared accountability rather than isolated blame. 

None of this is complicated in theory. In practice, it requires someone to decide that procurement capability is worth investing in — that training a team to evaluate technology with financial rigor will return more than whatever that training costs. The companies that have made that decision tend to run fewer project postmortems. They also tend to have fewer uncomfortable conversations about why the system doesn't work the way anyone expected.

The next time a technology project goes sideways in your organization, resist the instinct to point at the vendor or the IT department first. Ask a harder question instead: Did anyone equip the procurement team to make that decision with real business criteria? If the answer is no, you've found your problem. And more importantly, you've found where to start fixing it. 

Sources:

- McKinsey & Company — *Delivering large-scale IT projects on time, on budget, and on value*

- Standish Group — *CHAOS Report* (via Sourcing Innovation, 2024)

- Gartner — *Total Cost of Ownership in IT procurement* (via ISM, 2025)

- ZipDo — *Essential Software Project Failure Statistics*, 2024

- Intact Tech — *Why So Many Government IT Projects Really Fail*, May 2024

- CIM — *Technology Procurement: Why It So Often Fails Before It Begins*, November 2025

- McKinsey & Company — *Procurement Efficiency: A Modern Strategy for State and Local Leaders*, October 2025

- Purchasing & Procurement Center — *Total Cost of Ownership: Strategies and Techniques*

- McKinsey & Company / Umbrex — *The McKinsey Eight-Step Sourcing Framework*, January 2026

- Netguru — *Build vs Buy Software: Hidden Costs That Change Everything*, September 2025