A $5 million project cost Levi Strauss $192.5 million. That is not the interesting part.

Free AI Tool · CIOPages

Get Your Personalized Career Growth Plan

Answer four short sections about your role, competencies, and aspirations. Our AI generates a comprehensive, actionable plan — with certification recommendations, networking strategy, and a 3-year roadmap — tailored specifically to technology executives.

~8 minutes CIOPages AI Advisor Download as Word Refresh for current market

Build My Career Plan

In 2003, Levi Strauss decided to fix its IT.

The company was 150 years old and operating in more than 110 countries, running what amounted to a patchwork of incompatible country-specific systems. The plan was to consolidate onto a single SAP platform. Deloitte was hired to lead it. The proposed budget was under $5 million.

Then Walmart required the new system to interface with its supply chain management system. Financial reporting and internal controls proved insufficient, to the point that Levi Strauss came close to restating quarterly and annual results. During the switchover the company could not fill orders and closed all three of its US distribution centers for a week.

In the second quarter of 2008 it took a $192.5 million charge against earnings. Its CIO, David Bergen, resigned.

A five-million-dollar project produced a two-hundred-million-dollar loss. That is a forty-fold miss, and the natural reaction is that somebody was unusually incompetent.

The research says otherwise.

The average is the trap

Bent Flyvbjerg and Alexander Budzier, then at Oxford’s Saïd Business School, assembled what they described as the largest study of IT change initiatives conducted: 1,471 projects, budgets and forecast benefits compared against actual costs and results. ERP, management information, CRM. The average project cost $167 million; the largest was $33 billion.

The average cost overrun was 27%.

If you stopped there — and most people do — you would conclude that IT projects run about a quarter over, which is annoying but survivable, and roughly what you would budget for anyway.

When they graphed the overruns, the distribution had a fat tail. One project in six was a black swan: a cost overrun averaging 200% and a schedule overrun of almost 70%.

This is the finding, and it is not the one people repeat. IT projects are not unusually prone to going somewhat over budget. They are unusually prone to going catastrophically over budget. Those are different risks, they call for different responses, and the average hides the one that can end you.

Black swans do not kill healthy companies

The worst outcomes cluster in organizations that were already under pressure — eroding margins, rising costs, debt to service — where a runaway technology program compounds a problem that already existed.

Kmart was losing ground to Walmart and Target when it began a $1.4 billion IT modernization in 2000. By 2001 the new system was so heavily customized that maintenance costs looked prohibitive, so the company launched a further $600 million effort to update its supply chain software. That went off the rails in 2002. Both projects contributed to the bankruptcy filing that year, and the eventual merger with Sears shed more than 600 stores and 67,000 employees.

Auto Windscreens was the UK’s second-largest automotive glass company in 2006, with 1,100 employees and £63 million in revenue. It moved order management from Oracle to Metrix and began implementing a Microsoft ERP system. In the fourth quarter of 2010, falling sales, inventory problems and IT spending together forced it into bankruptcy.

And more than a decade before the study, Hershey’s new order-taking and fulfillment system prevented it shipping $100 million of confectionery in time for Halloween, producing an 18.6% drop in quarterly earnings.

None of these companies set out to bet the business on a systems project. Each one did.

What the study does not say

The sample drew heavily on public agencies — 92% — and US-based projects, 83%. The authors report finding little difference between those and the private and European projects in the remainder, but a sample dominated by public-sector megaprojects averaging $167 million is not a direct read on a mid-market ERP replacement.

The shape of the finding almost certainly transfers. The specific one-in-six should not be quoted as though it were measured on your portfolio.

The two questions

Flyvbjerg and Budzier propose a stress test, and its value is that it asks about survival rather than probability.

First: is the company strong enough to absorb the hit if its largest technology project runs over budget by 400% or more and delivers only a quarter to a half of the projected benefits?

Second: can it take the hit if 15% of its medium-sized technology projects — not the flagship everyone is watching, the secondary ones nobody is — exceed cost estimates by 200%?

Both questions sound comfortably hypothetical. The data says they are not. And note where the second one points: at the projects with no executive sponsor watching them, which is where the governance attention is not.

It is not inevitable

The same paper documents a counter-case worth more than the failures.

Emirates Bank decided in April 2006 to revamp parts of its core banking system and kicked off the project after twelve months of planning. Mid-project, the bank merged with the National Bank of Dubai, which meant the system now had to serve both institutions, on an 18-month deadline, with every component — branch systems, ATMs, online banking, call centers — cutting over simultaneously.

The project completed in November 2009. Schedule slipped 7%. Costs ran 18% over the original estimate. The merger had roughly doubled the scope.

What the team did is unglamorous: held the schedule after the merger, refused scope changes, broke the work into discrete modules, kept the team from turning over, framed it as a business program rather than a technical one, and measured every activity against a single target — readiness to go live.

Nothing there is a methodology. It is mostly a refusal to let the project grow.

What to do with a fat tail

Most IT risk management is built around the average case, which is why it fails on the cases that matter. A 27% contingency is protection against the ordinary outcome and no protection at all against the one in six.

The practical shift is to stop asking how likely the worst case is and start asking whether you would survive it. That question has an answer, it does not require forecasting, and it is answerable this quarter.

And if the answer for any single program is no, the problem is not the estimate. It is that the program is too large to be attempted in one piece.

Sources: Bent Flyvbjerg and Alexander Budzier, "Why Your IT Project May Be Riskier Than You Think", Harvard Business Review, vol. 89 no. 9, September 2011, pp. 23-25 — all figures, company cases and the stress-test questions are drawn from that article.