Clothing retailer, J.Crew, reported weaker than expected second-quarter earnings due to severe problems following a website and call center upgrade. The fiasco caused cost the company $3 million in addition to lost sales and dissatisfied customers.
The company's 10-Q SEC filing describes what happened:
During the second quarter of fiscal 2008 we implemented certain Direct channel systems upgrades which impacted our ability to capture, process, ship and service customer orders. As a result, our Direct sales growth rate was lower than recent quarterly trends. We expect the impact of the systems upgrades to continue into the second half of fiscal 2008.
In plain English, J.Crew couldn't process orders or ship clothing to customers after deploying a website upgrade. Ouch, that one hurt.
James Scully, company CFO, provided details during an earnings call (transcription from Seeking Alpha):
In order to properly support our multi-channel, multi-brand strategy, we were required to make some significant investments in the direct business. These includes the following: a new platform for our website to allow for multiple brands, enhanced functionality, and increased growth capacity; a new order management system to improve the overall customer experience in our call center and drive future efficiencies; and a new direct warehouse management system to support our multi-branch strategy. On the weekend of June 28th, after taking our website down for 24 hours, we cut over to the new systems. Over the next several weeks, we experienced issues related to the site performance, order fulfillment, and call center performance....
The merchandise margin deterioration resulted from unplanned customer accommodations related to the direct system initiatives in the form of free and upgraded shipping, increased markdown activity as a result of our inability to transfer store markdowns to the direct channel, and increased freight expenses as a result of transferring inventory between stores combined with an overall increase in freight transportation costs....
In other words, the company screwed up customer orders. The J.Crew Aficionada blog described it this way:
As some of us have experienced first hand, many orders have been short-shipped or canceled due to lack of inventory (despite showing as "in stock" online). I really do hope that J.Crew can sort out the inventory issues this weekend to show in-stock items only on their website.
In a visceral demonstration of customer impact, one poor guy documented his J.Crew experience, which included being charged $9,208.50 for shipping three shirts. Here's the receipt, along with a photo showing the baby-sized shirt J.Crew sent him by mistake:
THE PROJECT FAILURES ANALYSIS
There's something special about companies that deploy mission-critical, customer facing systems without sufficient testing. Although we can only speculate why this happened, CFO Scully acknowledged the screw-up:
[We should have been] more conservative in our internal planning in terms of the potential disruption related to the direct business, which would have led us to be more conservative in setting expectations externally with our customers and our other constituents.
In fairness, once management understood the enormity of the situation, the company did take steps to satisfy customers, including offering discounts and other incentives. In the earnings call, J.Crew CEO, Millard Drexel, focused on not alienating customers:
[T]he risk was having a little more inventory but for us, more importantly, we wanted to make up to any customers and we didn’t want to just piss off more people.
Discussing this situation, we can't ignore the recent ERP failure at jeans retailer Levi Strauss. In that case, Levi's reported a 98% drop in net income when implementation problems prevented the company from shipping product to retailers.
My take. The post-mortem analysis should focus on a key question: did management or the project team drive this failure?
In one scenario, management forced a premature rollout despite warnings from the project team, which knew the system wasn't ready. We all know cases where management pressured a software team to ship code before it was ready, despite protests and warnings from developers -- such moments are pure Dilbert but nonetheless happen all the time.
Sometimes a rollout is dictated by the desire to get it done before a busy season, which typically become quiet times for IT. You want to get a system live and de-bugged before any critical season. I think this is what happened here.
Another, equally plausible, scenario is the implementation team itself didn't recognize poorly-tested flaws that could not withstand the rigors of going live. Sadly, the annals of project failure are filled with stories about project teams that didn't pay sufficient attention to testing and data integration before going live.
Paula points out that management accepted full blame in this case:
It sounds more like that which they bought (and I’m assuming they did not build, but bought) was less mature than they thought it was. But if you read carefully, they’re not saying they were too aggressive in implementation times, nor are they saying they should have allowed more time for implementation. Management is saying they should have planned their sales numbers less aggressively to accommodate problems that could (and did) occur. That’s fascinating really. Management is falling on its sword and actually not blaming IT at all.