Let’s Stop Crediting Technology for Success, and Blaming Technology for Failure.

Posted on June 18, 2026

0


Third in a series reading the 2026 Gartner Supply Chain Top 25 against the archive. The first traced an architecture; the second traced a determinant in both directions; this one names the rule the other two were circling.


In 2004, the company building a business to rival IBM’s at implementing SAP — the company whose pitch to the market was its mastery of the very systems in question — lost roughly four hundred million dollars in revenue trying to merge two of its own SAP installations. Hewlett-Packard could not make the technology work inside its own walls. Its CEO said so publicly. An analyst put the obvious question on the record at the time: who would hire HP for a large-scale SAP integration now, after its own chief executive had admitted the company couldn’t manage one?

Hold that next to a county in Colorado. Arapahoe County — eighteen hundred employees, a modest budget, no special technology expertise — implemented the same class of software, kept it plain-vanilla, brought it in on time and on budget in nine months, and cut its purchase-order cycle time by eighty percent.

Same technology. One of the most sophisticated technology organizations on earth failed with it; a small county government succeeded with it. If the technology were the variable, that result is impossible. So the technology is not the variable. That is the whole argument of this post, and I want to be clear at the outset that it is not a new one. I wrote it down in 2008.

The receipt is dated

❖ FIGURE 1 — SAP Procurement for Public Sector, CATA Alliance, 2008 (cover page)

Caption: The dated artifact. Authored as Chief Architect, CATA Alliance — the failure column and the success column, same vendor in both.

That year, as Chief Architect for the CATA Alliance, I published a white paper on SAP’s Procurement for Public Sector offering. It was not a hit piece on SAP; it took no position on whether an organization should buy SAP at all. It did something more useful. It lined up the failures and the successes side by side and asked what actually separated them. The failure column was not short — HP, Hershey, FoxMeyer, Cadbury Schweppes, the City of Houston, King County — organizations that lost tens or hundreds of millions, and in FoxMeyer’s case the company itself. The success column ran right beside it: Arapahoe County, Seattle Public Schools, Erie County, San Luis Obispo, the City of Ottawa.

Here is the detail that makes the paper a proof rather than an opinion. The same vendor appears in both columns. The technology is held constant by fact, not by assertion — and when the technology is held constant and the outcomes still diverge, the technology cannot be the thing that decided them. What decided them sat upstream of the software: whether the organization had aligned its people, its processes, and its real-world operating conditions before the platform arrived.

That is why the title runs in both directions. We reflexively credit the technology when a program succeeds and blame it when one fails, and both reflexes are wrong for the same reason. The technology is necessary and never sufficient. It is the last piece, not the first. Crediting it for the win is like crediting the scalpel for the surgery; blaming it for the loss is like blaming the scalpel for the diagnosis.

Why HP is the cleanest proof

HP is the clearest case I know for the first half of that claim, because HP maximized the very variable everyone assumes is decisive. This was not a naïve buyer who didn’t understand the software. This was a company whose entire market position rested on its expertise with the software — the integration practice, the resources, the brand, the stated ambition to out-implement IBM. And it still lost four hundred million dollars. Not to an unfamiliar technology, but to the work of merging two systems it knew intimately, inside a post-merger organization whose operating conditions had not been aligned first. The expertise was never the variable. The sequence was. As the paper asked at the time: if a high-technology company with deep experience in the product can’t make it work, what does that say about anyone else’s odds?

And the second half of the title lives in the same case. HP blamed the SAP rollout for its losses; the software became the story. But it was the same software thousands of organizations ran successfully. What was different was the merger ecosystem it was dropped into. HP did exactly what the title warns against — it blamed the technology for a failure that had been decided before the technology was ever switched on. My September 2010 post, written while the market was still calling HP the unbeatable competitor “bearing down the tracks,” was the real-time refusal to drink that particular Kool-Aid.

The other half, proven on the success side

Arapahoe County didn’t win because SAP was magic. It won because it kept the implementation plain, secured genuine management sponsorship, and refused to bend the organization around the software. The sharper demonstration sits one vendor over — and it is sharper precisely because the vendor is different. The Commonwealth of Virginia’s eVA procurement program, which I have documented since 2007, did not run on SAP at all. It launched in 2001 on Ariba — then an independent company, on an early and at the time unfamiliar software-as-a-service model, more than a decade before SAP acquired Ariba in 2012 — and it became one of the most durable public e-procurement programs on record. A comparable Canadian federal effort, with more money behind it, modeled itself on Virginia’s outcome, imported the same class of platform, and skipped the diagnosis that had produced the outcome in the first place. Same class of instrument, opposite song. Virginia’s own leadership put it plainly: they believed they would have succeeded with any vendor’s product. The variable was never the platform — and it was not the competence of the technologists either. Both efforts had capable people; one did the upstream work and the other didn’t. That the rule holds whether the logo reads SAP or Ariba is the whole point: it is a rule about organizations, not about software.

And there is a final turn that retires the “just buy the capability” instinct altogether. In 2012, SAP acquired Ariba — the original platform behind eVA — for $4.3 billion. When I scored all three phases on the Hansen Fit Score™, the pattern was hard to miss: after the acquisition the platform’s technology capability rose, while its outcome score — the probability the thing actually delivers in deployment — fell, and the distance between the two widened to the largest in the assessment series. The era had already supplied the controlled comparison in its cleanest form: Virginia ran Ariba to a durable success while Ontario’s OECM ran the same Ariba platform and lost twenty million dollars. Same vendor, same software, opposite outcomes — and then a four-billion-dollar transaction that lifted the capability and let the result slip. The money bought the asset; it could not buy the conditions that made the asset work. That is the whole thesis compressed into a single transaction: you cannot purchase a substrate.

Where HP sits in this series — said precisely

This is the third post in a short series assessing Gartner’s 2026 Supply Chain Top 25 against the Procurement Insights archive. The first traced an architecture — Cisco’s, at number four — that was operating two decades before the industry renamed it “agentic.” The second traced a determinant in both directions through Toyota, at number twelve, which fell on its ecosystem and climbed back on it. HP belongs in the series for a different reason, and I would rather be precise about it than tidy.

❖ FIGURE 2 — Gartner 2026 Global Supply Chain Top 25 and Masters

Caption: Cisco at four, Toyota at twelve, HP at twenty-two. © 2026 Gartner, Inc. Reproduced with attribution.

And HP sits on that pyramid too, at number twenty-two. But the company that lost the four hundred million in 2004 was the unified Hewlett-Packard, and that company split in 2015 into HP Inc. and Hewlett Packard Enterprise. The “hp” on the Top 25 is HP Inc.; the entity is not, strictly, the one that failed. So I am not going to hand you a neat redemption arc — HP fell, HP rose — because the corporate history won’t support it cleanly, and you’d be right to distrust me if I pretended it did. HP’s place in this series is not a comeback story. It is the proof of the rule: the most expert technology organization in the world failed with the technology, which is the most direct evidence I can put in front of you that expertise and technology are not what decide the outcome. The pyramid is the field that arrived. The 2008 paper is the explanation the pyramid doesn’t print.

This was never really about SAP

If this reads as a story about enterprise software and 2008, it isn’t — and that is the reason for telling it in 2026. The argument I made about SAP is the argument now playing out, almost word for word, about AI.

In 2025, MIT’s Project NANDA found that roughly ninety-five percent of enterprise generative-AI pilots produced no measurable return — and located the cause not in the models, the talent, or the infrastructure, but in what its authors called the learning gap: integration, context, organizational fit. The technology did not fail. Organizations failed to absorb it. The current fashion is to say the winners won because they chose to own their data and their AI platform — that “sovereignty” is the cause of the advantage. It isn’t. Sovereignty is what the winners could afford to pursue because they were already aligned; the discipline came first, and the AI arrived to prove it, exactly as SAP did eighteen years ago. You cannot buy a substrate. You can only build one — and then introduce the technology to an organization that can absorb it. I made that case at length in The Standard Wasn’t the Answer in 2008. Sovereignty Isn’t the Answer in 2026.

Why the archive is the point

None of this is hindsight, and that is what the archive is for. The cases were dated when I wrote them, which means the rule can be checked against the record rather than taken on faith. The receipts, 2008 to 2026:

The honest caveat

Two limits, because the claim is only as strong as them. The controlled comparisons here — the same technology producing opposite outcomes — carry the causal weight; a list of winners never could, because winners are selected after the fact and a pattern among them is not a cause. And HP, as I said above, is proof of the rule, not a redemption arc: the entity that failed and the entity on the pyramid are not the same company, and I won’t pretend they are. State both plainly and the argument gets harder to knock down, not easier.

So let’s stop

Stop crediting the technology when it works and blaming it when it doesn’t, because the credit and the blame belong to the same place — and it isn’t the technology. It is the alignment of people, process, and conditions the technology is dropped into: the substrate that was either built or skipped long before anyone pushed the button. HP had every advantage the technology-first story says should matter, and it wasn’t enough. A Colorado county had almost none of them, and it was. The difference was never in the box.

Truth is believing. Accuracy is knowing. We keep believing the technology is the cause. The record keeps showing it never was.

-30-

Truth Is Believing. Accuracy Is Knowing.

Jon Hansen is the creator of Implementation Physics™, a research-based framework developed over nearly three decades to explain why technology initiatives succeed or fail regardless of the technology being deployed. His work spans six technology generations — from ERP through Agentic AI — and includes the Metaprise™ model first articulated in the late 1990s. His research forms the foundation for the Hansen Method™, Hansen Fit Score™ (HFS™), Phase 0™ Readiness Assessment, and the ARA™ RAM 2025™ multimodel verification architecture. He currently serves as a Board Member of the CIPS Americas Chapter.

Posted in: Commentary