Special ERP Note: Lessons from Lumber Liquidators

A special contribution to our continuing discussion of Implementation Success

If you're in the ERP world and haven't heard about Lumber Liquidators you will.

Key excerpts from Lumber Liquidators Q3 2010 earnings report are provided in this post.

Three important points before we dive into the data:

First, substitute ERP for SAP in every instance—this is a cross-platform problem.

Two, applaud Lumber Liquidators for manning up to their problems, not pointing fingers (at least publicly), and moving ahead to fix their troublesome investment.

And three, please note that no one blames the system—it’s Lumber Liquidators inability to use the system that impacted Q3 revenue and profitability.

Enough said, here’s the headline of the Press Release—yikes!

Lumber Liquidators Announces Third Quarter 2010 Financial Results

~ SAP System Implementation Impacts Third Quarter Results 

This is the first line of the earnings release:

Lumber Liquidators (NYSE: LL), the largest specialty retailer of hardwood flooring in the U.S., today announced financial results for the third quarter and nine months ended September 30, 2010.

Standard stuff, but here’s what immediately  follows:

SAP System Implementation

On August 22, 2010, Lumber Liquidators implemented the most significant phase of its integrated business solution from SAP, including an enhanced point-of-sale solution, a warehouse management and inventory control system, an integrated merchandising and product allocation system, and related management reporting functionality.

All critical information was converted from the previous information system and the Company has continued to operate its business without interruption since the conversion.

Here’s the bad news:

However, the implementation significantly impacted third quarter 2010 results by reducing productivity, primarily across store and warehouse operations, including less effective conversion of customer demand into invoiced sales, less efficient product allocation and distribution, and the general need for additional resources to operate the business.

Let’s get specific:

The Company estimates that reduced productivity resulted in approximately $12 million to $14 million in unrealized net sales during the third quarter.

SG&A expenses for the third quarter of 2010 reflect one-time costs of approximately $0.5 million related to the SAP implementation, primarily resulting from increased payroll and warehousing costs.

The Company estimates that reduced productivity subsequent to the system implementation increased inventory carrying levels by approximately $8.0 million.

That’s $20 - $25 million in additional cost, largely because people were not prepared to use their new ERP system! 

Jeffrey W. Griffiths, Lumber Liquidators' President and Chief Executive Officer, commented, "While we are confident that over the longer-term the implementation of our new SAP system will significantly benefit the business, our performance in the third quarter reflects declines in productivity both at the store-level and in the flow of product through our warehouse following implementation."

“Overall, we remain focused on improving our operations and building a foundation for long-term success."

And in closing. . .

Sincere accolades to Lumber Liquidators' executives for doing the right thing after the fact—admitting the hit and committing to long-term success.  If you’ve ever shopped at a Lumber Liquidators you know they’re a quality outfit.

I don’t know what Lumber Liquidators spent to prepare their people for ERP or (more important) how they prepared their people for ERP.

But it was clearly not enough.

The Program's NOT The Problem!

I noted in a previous post that program credibility is a core requirement for program success. 

“You simply must make people believe you can and will complete what you have started, even if this has not been true in the past.”

In this post I’d like to review exactly how some of our clients have successfully grown program credibility.  My aim is to provide some concrete examples you can apply toward future projects.

Bury the Past

People are shockingly quick to tell us how their organizations have failed in the past:

“Has anyone told you about Project Forward?  It’s called ‘Project Forever’ for a reason, you know.”

Even worse, it’s dismaying how often past failures are considered relevant to your future efforts.

“We’ve tried and failed to do this so many times in the past, why should this project be different?”

It’s imperative to accept the inevitable, unfavorable comparisons with past efforts.  This requires admission you’ve failed, consideration why prior projects failed, and a credible demonstration of why things are different this time.

One practical suggestion is to address right up front why your next project is different from past efforts.  But give good reasons—failure to really differentiate ensures your current initiative is lumped with past disasters.  And be bold: call out the elephant in the room before it squashes support for your next project.

Leaders to the Front, Please

I don’t think you can underestimate the extent to which people expect, even demand executive attention and commitment to top projects.

“We all know this isn’t Tom’s top priority, why should it be mine?”

The imperative here is to trump talk with action.  Everyone knows which projects receive resources and which subsist on lip service. 

Executive commitment is measured by the answers to two questions that test a sponsor’s mettle: 


* Will you use your political capital to help us when other leaders and managers are putting up roadblocks?

* Will you ensure we have the resources we need, including the specific people we need?

Every organization should slim their program list down so it includes only those programs the organization and its leaders will adequately and consistently resource and support.

And all talk about top priorities must be consistently backed by political muscle and capable resources throughout the project lifecycle (however ugly it may be).

WHO Matters Most

The final determinant of program credibility is the most powerful but the most difficult to influence. 

Program credibility—the fundamental belief we can and will complete a program—results when the majority believes the people they work with and the people (or person) they work for also believe the program is credible.

The challenge here is indirect.  You cannot tell people to believe you can succeed.  You have to repeatedly make the case and help people across the organization believe.

I think this is where most change management programs fail.  You know the story, the program checks all the boxes on the change management checklist yet falls flat on its face.  Why?  Because the program failed miserably at the grass-roots level!  Despite the balloons, banners, pronouncements, and events people at all levels continue to doubt this program is different from every past failure.  Or they observe that the program really isn’t a top priority because Joe, the boss’ pet hot shot, was detailed to a competing program.  They’re never given a reason to believe we can succeed so they doubt we can.

To end, program success requires a shared belief you can succeed. You can build this belief.  It just takes departures from the past, real leadership commitment, and a consistent, credible effort to grow support amongst the people who really decide program success. 

The System's NOT The Problem (Part One)

Prior posts focused on implementing technology.  I’d like to take a step back to consider how people actually use the systems we’ve implemented, or more specifically to address how people exploit the information we pour into them.

The answer, of course, is it depends.

If you ask,”How well do we use information to operate our business, to do things like tally revenues, pay the bills, account for people and the like, the answer has to be ‘pretty well’.”

If you instead ask, “How well do we use information to better our business?” the answer is far less encouraging.

Consider the following charts.  You can quibble with the data points (endlessly) but the main messages resonate with me.

Both charts show the results of a survey of over 1,300 managers polled by the Harvard Business Review.  In the first chart (below) the left axis lists four important information uses.   The top (blue) bars show the percent of respondents who say their organizations use information to effectively improve service, sales, loyalty, and collaboration.  The second (red) bars show the percent of respondents who say the ability to achieve each objective is important to their business.

The gaps within each set of bars is dismaying: collectively, these gaps indicate a persistent inability to use information to serve customers, grow sales, and increase collaboration—in other words, to better our business.

I don’t think these gaps are terribly surprising.  Most organizations have volumes of information about what has happened.  Most own scads of information that could be used to make good things happen, but somehow fail to prospectively use information to make something new, important, valuable happen.

My second chart suggests why organizations don’t use information prospectively: information is as fragmented, isolated, and silo’ed as our organizations (all together now, D’OOHH!).

I don’t know if information utilization would really improve if there was “unified view” available to all—what I need to see as a customer service manager varies from what you might want to know as a salesperson. 

But I do subscribe strongly to the idea that organizations fail to effectively use information because information is bound too tightly by existing organizational structures.

Perhaps we need a new “information structure”—a commitment to making information access and use largely independent of existing organization lines.  Data collection could continue to conform to organization structures; accounting will collect the bills, sales will still book the sale; but profound changes in how information is compiled, accessed, and USED are in order.

But what would that look like?  And more to the point how would we get there? 

More thoughts on these practical considerations in future posts. 

Program Assessments Illuminate Real Problems

I thought it would be useful and interesting to share actual Assessments of three  programs.

My intent is to highlight a framework Meridian uses to help clients ensure program success. 

Each evaluation was completed by Meridian as part of our Program Delivery Assurance services.  In each case we were engaged by business leaders to provide a frank evaluation of the current state of three very different ERP programs and (more important) to advise whether and how to proceed with their ERP efforts.

This post highlights three ERP programs to provide a measure of cross-program comparability.  In practice our framework has been used to evaluate and guide a wide range of programs.

It’s important to note that we believe our charge is to find the best way to move forward.  Sure “shut down” is a last option, but it’s not considered lightly.  Experience shows that in most cases when there’s a will there’s a way to succeed with almost any program.

Summary evaluations of each program are shown in the following table (extensive analyses underpin each judgment).  A note on how we conducted these ERP evaluations follows in a separate post.

Program Dimensions	Program A	Program B	Program C
Planning	Murky	Very light	Good
Scope Management	“Bitten off far more than you can chew”	Too accommodating, creeping	Good scope management
Fit with Culture	Challenging—“we do everything at  once”	Standardization at odds with culture	Poor—individual fiefdoms threatened
Sponsorship	Confused but fixable	Sincere, though accountability is missing	Low—executives view as an IT initiative
Priority	Depends who you ask	Large program, not treated that way	One of many “top priorities”
Relationship with Business	Broken—no one really owns, champions this program	Not viewed as a business sponsored project	Very poor, business takes lead from sponsors, ignores
Program Management	“Can’t get to where we want to go with current approach”	Put together rapidly/recently	Good though playing catch-up
SI Support	Shared disaster	None	Arms length, to the letter of contract, no more
Use of Methodology	Making it up	Largely following vendor roadmap	Unclear beyond original design
Change Management	Too little too late	Inconsistent across locations, organizations	Nonexistent
Training	Incomplete at-best	Too technical, no opportunity to practice	Always “next on the agenda” but not addressed
Technical Development	Good	Good	Fragmented, configuring by line of business
Master Data	Adequate	Fragmented, no MD Process	Fragmented, managing by line of business
Testing	Scary bad, willing to seriously compromise	Inadequate time, depth to approach	Good, vendor standard approach
Cutover/Go Live	Expect a ‘scary’ Go Live experience	Focusing on pilot, not on larger Go Live	Fragmented planning, poor timelines

Scary stuff: we note problems along virtually every dimension of program performance.  Of course these programs were all clearly at-risk, hence the need for our Assessment services.

I highlighted (colored cells) the core problems we observed within each ERP program.  These highlights provide an easy way to summarize why each ERP program was struggling.

• Program A:  Program A was far too “ad hoc”—one week on the ground suggested this organization was making it up as they went (with little to show for their imaginative efforts).  The crux of the problem lay in the relationship between the client and their systems integrator—or more accurately the complete lack of a relationship which meant no one was in charge, planning and leading the ERP effort.

• Program B:  Can you be “too nice” to implement ERP?  I think so; this company bordered on this condition.  No one really wanted to hold the reins and drive the program forward; the Program Management Office was overwhelmed and incapable of forming the center of gravity and effort required to really drive a program of this scope and complexity.

• Program C:  “Do as I say, not as I do” might characterize this floundering program.  The project team was sincere, but their business executives weren’t and the Systems Integrator divined that this might not be their next great reference account.  Interesting, it took a real executive intervention, with shouts and tears, to “break the fever” and get this program back on track.

I don’t think it’s appropriate to tell specifically what happened with each program.  Suffice to say that each company had some level of ERP success (in fact two of the three were ultimately wildly successful).

My point in sharing these cases is two-fold:

• There are myriad reasons programs struggle.  Once struggling the key is honestly assessing where you are, understanding why you are where you are, and taking appropriate action, however unpopular.  If you’re not willing to do this then you probably should pull the plug!

• It’s far better to stay out of these unhappy positions by regularly and honestly assessing program progress and risks.  But don’t depend on those closest to you for this assessment.  It’s human nature to want the stoplights to stay green even if they should be blinking red!