Valérian de Thézan de Gaussan · Data Engineering for process-heavy organizations

Failure Case Study #2: How to lose $400 million.

Here's how to avoid following Nike's path to a $400 million loss.

Nike grew rapidly and dominated the market in the 1990s. They gained a clear edge against competitors like Adidas and Reebok.

However, that huge success was held back by a slow supply-chain.

The manufacturing cycle would take 9 months at the time.

They needed to reduce the cycle to 6 months.

The goal of the Nike Supply Chain (NSC) project was to improve the manufacturing cycle.

In 1999, They hired i2 Technologies, a rising company in the supply-chain software sector, to build a proper system that would replace all the fragmented process and software Nike had at the time.

It did not turn out well.

In 2001, Phil Knight, CEO of Nike at the time, said in a press conference:

“This is what we get for our $400 million, huh ?”

Turns out the company would miss its third-quarter earnings by 30% due to “the new supply chain management software”.

Something in the NSC project went terribly wrong.

What happened

Nike had a clear vision: to reduce the manufacturing cycle. By reducing this cycle, it’s easier to respond to change, to new styles etc. Business-wise, this vision is solid.

i2 implemented that by trying to predict the demand through historical order data. A science that, even by today’s standards, is very difficult.

Lastly, Nike decided that they would switch to the new system without taking the time to deprecate the old one. Which means they would go from one system to the other in one flick of a switch.

They did the switch. And by the summer of 2000, the i2 software was slow, would lose data and disrupted the whole supply chain. Nike even had to manufacture some shoes at the last minute and send them by air cargo instead of boats, which is at least 10x more expensive.

A few months later, Nike build manual processes, ran by engineers to make up for the faulty software. The supply chain was working, everything was fixed, but the damage was done. It impacted Nike sales so much that even the cost of the software — between $10 million and $40 million according to various sources — is little compared to the $400 million impact on Nike.

Nike and i2 fought a lot, in class-action suits as well as in the press. Nike would blame i2 for the mismanagement of their stocks, i2 would respond that the software had nothing to do with their earnings problems.

It does not matter who was right. What matters is how they ended up in this situation.

Do not rush

Now, with hindsight, we can understand and draw lessons from this. Of course, I could tell you that the customer collaboration was wrong and that if they managed better their expectations, things would not have been that bad.

But that would be far from what’s essential here, and still what most people do not understand even today.

Instead of rushing to develop a finished product and failing miserably on delivery day, there is an alternative: an approach that is becoming more and more popular today. It’s called Continuous Delivery.

Continuous Delivery (CD) consists of constantly iterating through four phases: Design, Develop, Test and Release. The idea is to make this cycle as small as possible. By having a short cycle, we gain feedback on every feature shipped much sooner than if it was done in a classic, waterfall, way.

With early feedback, we can find in a matter of days or hours (that’s how short the cycle should be) that our design was flawed or our analysis wrong instead of months.

This simple practice makes a huge difference in our ability to craft great software. I said simple, but beware : it is not easy to set up.

If Nike and i2 had agreed on such a way of working, instead of rushing through and delivering an unfinished, buggy software that disrupted the supply chain, the project could have been years shorter, and millions cheaper.


Nike managed to put everything back in order in 2003. It took longer than expected and a lot more money than planned, but they eventually managed to reach their goal.

They were quickly back as a profit making company.

Not every company would have survived this.

Even 20 years later after the NSC project, clients and software providers still falls in the same trap. There is a way forward that does not involve unsatisfied clients, lawsuits and tons of money lost. It is about breaking the status quo in these organizations and make sure the good practices and flawless communication are put in place.