We tried it before and it didn't work.

Many years ago, I was fortunate enough to have been selected by my employer to participate in a fairly new, very rigorous process improvement program called Six Sigma. Six Sigma was created by Motorola in the 80s, but was popularized in the 90s by GE. I worked for a Fortune 500 at the time; and it seemed all big corporations were trying to follow in Jack Welch’s footsteps after he made the program famous.

Wikipedia says "Six Sigma seeks to improve the quality of process outputs by identifying and removing the causes of defects (errors) and minimizing variability in manufacturing and business processes. It uses a set of quality management methods, including statistical methods, and creates a special infrastructure of people within the organization who are experts in the methods. Each Six Sigma project carried out within an organization follows a defined sequence of steps and has quantified value targets, for example: reduce process cycle time, reduce pollution, reduce costs, increase customer satisfaction, and increase profits."




In reality, a Six Sigma black belt program consists of a combination of intense classroom training combined with real-world projects in which substantial measurable business process improvements must be obtained prior to earning your certification. The classroom training is extremely heavy on statistics, total cost modeling, and learning how to replicate and predict results through procedure. However, by far, the absolute most important thing I got out of the program wasn't learning statistics or how to use Minitab software. No, the most important thing I learned was Change Management. In fact, change management is probably the single most important aspect of implementing a successful Six Sigma program even though in most definitions you don't even see it mentioned.




So why is a Six Sigma initiative's success so dependent on change management?

Because: "We tried it before and it didn't work."

Yes, those dreaded words that we've all heard before and many of us are guilty of using ourselves. I can't tell you how many times I've tried to start a new program, implement a new supplier, adopt a new technology, or change a business process and have been hit with the deal killer “We tried it before and it didn't work”. For many people, especially the less sophisticated workers, that statement becomes the de facto statement for keeping with the status quo. Don't like change, or don't want to do any extra work? Simple, blame the last failure and avoid trying anything different than what we are doing today.

The other day, I was wearing my salesman hat and presented to an IT sourcing manager about the benefits of my firm's telecommunications sourcing solution.  She was very excited about our capabilities and loved what she heard about the market intelligence we would bring to the table, the results we typically obtain for our clients, and the support she would receive in migrating their WAN to a new carrier. But then we talked about budget. It became clear that a typical fixed fee or consulting rate was not aligned with her budgetary restrictions. When I discussed our alternative, our contingency model that funds us through savings, I was hit with the dreaded “We tried it before and it didn’t work”. She didn’t even want to talk it through, her reasoning is that they had a terrible experience with a provider working on contingency in the past and that it was not a good fit for her business, her words “we got burned”. Conversation closed, she liked us, wanted our services, but did not have a budget for a consultant and did not want to explore a contingency model because it didn’t work for her once in the past.


Now, as I see it, there are 4 main reasons any initiative can fail:

1. The supplier (or product/service) does not perform properly 
2. You (your company) does not perform properly 
3. The relationship and expectations between you and your suppliers are not managed properly
   
   And in extremely unlikely situations;
4. The overall premise for the initiative was flawed and was destined to fail despite the best people, suppliers and efforts in the world.

It’s certainly easiest to take the path of least resistance and blame the supplier (situation 1) when your initiative goes awry. Situation 4, is an incredibly rare circumstance in which all of your assumptions about a product, service, process, technology, solution or supplier were wrong and cannot be resolved through adapting or replacing your attempted solution. But, the reality is, most projects or initiates fail because of one of the first three issues. But, that’s a good thing, because it means that with adjustment you can likely make your initiative successful.

• If the product fails, find out why. Can the supplier correct it? Is it the right spec? Did something happen in shipping or transportation that caused damage? Can someone else make one that works better? 
• If the service fails, figure out why. Did you set your SLAs properly? Did you write a contract that committed the supplier properly to those SLAs? Did the supplier staff your initiative properly? Did you flat out choose the wrong supplier? 
• Did your team drop the ball? Did your team have maverick buyers or rogue employees? Did you not give the supplier what they needed to be successful? Where the assumptions you made incorrect, or did you rely on bad data? Could you implement better internal controls and procedures to make sure next time you are successful? 
• Does your supplier actually know what is expected of them? Is it documented? ...in writing? Are you treating the supplier as a disposable commodity, or a business partner?

As companies are continuing to feel the pressure to be lean, both end-users and procurement professionals are being tasked with finding new, alternative ways to reduce costs. However, in many cases they rely on the “We tried it before and it didn’t work” solution and seek out the status quo. My previous example of the sourcing manager who “got burned” by a contingency provider in the past is a perfect example of seeking out the status quo.

Think of this analogy. You need a car to get to work. You buy a car from a non-reputable used car dealer based on some poor assumptions. That car turns out to be a lemon, and breaks down the week after you buy it. You also find out that the dealer grossly misrepresented the vehicle as it had been in a flood. The dealer refuses to accept a return or honor the warranty. You take them to court, but they go bankrupt before your court date. For a year and a half, you pump money into repairing the car so that you can get to work, and finally give up. You still need transportation, do you say "we tried it before and it didn’t work"?

Of course not; you likely still need a car to get to work. Instead of giving up, if you have the financial ability, you’ll give car ownership another shot. Only this time, you’ll spend a bit more time researching the car, defining your requirement, researching the dealer (supplier), ensuring that the warranty can be honored in other places, and you may even take your prospective next ‘ride’ to a mechanic for a third-party independent analysis (benchmarking).

So next time a stakeholder tells you to back down because something you are proposing has been tried before, don’t just walk away. Put it on that stakeholder to walk through the reasons why it didn’t work in the past, and don’t settle for a generic answer that it simply will not work or that a supplier failed. Just as you would build out a RFP scorecard, stick to facts and metrics. Quantifying both successes and failures helps you to understand where and how you could adapt a failed solution to make it a successful solution. Without doing so, you’re guaranteed to be overspending.  Change management is as critical of a component to success in Six Sigma projects as it is in procurement and supply chain initiatives.  Without the ability to change thinking, processes and your company culture, you're destined for mediocrity.