There are some popular process improvement or business improvement methodologies out there, and some that have received poor press. The right one for you is the one that will defeat your greatest enemy.
Most of us can name at least a generous handful of different business improvement or process improvement methodologies that have either come and stayed for a while or come and gone quickly. Some of us can even name a few that the rest of us have forgotten. With so much of a fad phenomenon in the improvement methodology track record, how do we choose one to adopt for our own needs?
I have a theory concerning the fad phenomenon that plagues so many methodologies; well, two that go together really. Indulge me just a little, because I think it is important to understand the phenomenon in order to pick the methodology or “trend” that you need.
First, the truly effective methodologies often incorporate mostly common sense. Eventually, enough businesses adopt or incorporate enough of the common sense that personnel that migrate among businesses over their careers meet others with the same inculcation of common sense and what was once a reasonably new presentation of combined ideas becomes old hat. It is no longer perceived to be especially constructive to invest in expensive training or consultations to introduce the ideas.
Unfortunately, often as the process I described takes place, the total package of common sense ideas loses a few elements or some important interpretation or understanding. That leaves us in a sort of limbo where enough of the original understanding persists to make expensive training efforts lose value, but enough has been misunderstood or forgotten that the full potency of the package no longer exists either.
Second, we often jump on the wrong methodology for our needs. We learn about some methodology that other businesses are using to make significant and competitive improvements and we take notice. Sometimes our leaders, or boards of directors, or even customers or contractual partners direct us to do what others do in order to improve our own performance.
The adoption of a methodology because others do it well, I believe, leads to much of the bad press some of these methods get. I say so because not everyone feels or achieves the same benefit from the program. When the adoption of the program fails to achieve the results advertised, word gets around.
The programs fail, generally, for two reasons. Either it was not properly recreated or adopted, or it was simply the wrong tool for the job. Let me give some examples.
A colleague of mine, a couple of years ago, called me from his new job where he had been hired to teach Design for Six Sigma to a business of software engineers. At first thought that may not sound weird, but to a DFSS guy, that’s a nightmare. The primary focus of Design for Six Sigma is to eliminate variation in the outcome of the product, the quality of the product, and the systems that produce the product. Software doesn’t experience variation. It’s a mismatch and he wanted to talk through the challenge ahead of him.
Another business owner and I talked some time ago about a different problem. The business leader he and his co-owners hired to run the business decided that Lean would be the methodology to improve the manufacturing business’s performance. Performance significantly declined and the owners had to step in and put things back on track, and find a new leader.
There is certainly more to the story than a failed adoption of Lean, but that failure is significant. In this case, the lean experts tried to apply Lean, a new methodology to this particular business, to an already highly efficient business. Between inappropriately applying “textbook” solutions to existing processes and the learning curve of adopting a new ideology, the program did more harm than good. The business probably didn’t really need a better way to be efficient in the first place, it was already highly so.
One business I worked for invested heavily in adopting an Outcome-Driven Innovation methodology. It even paid for it’s own custom deployment of it. There was a significant mismatch, however. The business didn’t scale up it’s ability to directly engage customers to match. The methodology is deeply dependent upon direct customer input, but it wasn’t perceived as feasible to do what the program demanded.
One last example: a small business owner asked me recently if I thought Lean would help him pull his business back into the black. He was struggling. After discussing his challenges I recommended against it. While there might be a few opportunities to make some things more efficient, his real need was to increase revenue. Increasing profit through better efficiency can come later, but without more revenue, discussions of profitability are less meaningful.
In the four examples above, we have potential tales for the failure of Design for Six Sigma, Lean, and Outcome-Driven Innovation. Truly, though, it wasn’t the failure of the methodologies per se that caused problems, it was either a failure to correctly employ or commit to the methodology, or it was a mismatch where the methodology was not what the business really needed, or both.
That is my point. The popular programs fail because they are not properly executed, or because they are the wrong solution for the business’s problem. Often, the former happens because of the latter.
I believe it is very important to understand that point. If we are going to adopt a program to improve our business, then we must adopt one that will solve our most important problems or satisfy our greatest needs.
Based on that, here is my advice. Identify your business’ enemy. Then either select or develop a methodology that declares war upon and eradicates that enemy. If that methodology isn’t mostly common sense, it will be difficult to inculcate and make successful, so focus on common-sense ideas.
A software design group does not need to declare war on variation. In spite of that, my friend and colleague is successful in improving performance by modifying his deployment of DFSS. He standardized the development approach on the DFSS problem-solving methodology and incorporated all of the applicable elements around designing in a way that predicts performance before design is complete, minimizing differences between program structures and coded elements to make re-use easier and performance more predictable. He focused on reducing variation between designs rather than between each product (there is none because every copy of the same released program code is identical).
An already highly efficient manufacturing firm probably will not see much improvement for the adoption of Lean. The owners of the manufacturing business in my example above declare war on time, then cost, in that order; quality is already a deeply ingrained value. The competitive advantage the firm possesses is rapid delivery of every customer’s uniquely tailored product. They deliver in days what the competitors deliver in weeks.
Because of that, time is critical. It is most important to be able to go from order to delivery as rapidly as possible. In some cases, that means making decisions that are not necessarily true to the Lean philosophy. If an extra step for a machine or a person saves a second of time down stream, they accept the “waste” step.
If you need a solution to a problem, ask this very important question, “Are we willing to commit to the changes or actions that this solution demands?” If the honest answer is, “no,” then it is not the right solution. Don’t spend hundreds of thousands of dollars to adopt a solution that you aren’t going to utilize. By the way, we must answer the question honestly.
Just because other businesses make good on a methodology, don’t assume that it’s right for yours. The small business mentioned above would have done itself in trying to adopt Lean to solve its problem. Adopting a program, or developing a program, requires an investment.
An already hungry and skinny business doesn’t need to invest more on a program to make it leaner. Instead, it needs to invest in a program that produces more income.
What is your business’s greatest challenge? What is your enemy? Here are some popular or common challenges to get you thinking.
- On-time delivery
- Innovation or market-capturing designs
- Waste or inefficiency
- Customer service
- Variation or consistency
- Failing to adapt
- Short revenue or sales
- Market perceptions or brand loyalty
The above list is a starting place. Your own worst enemy may or may not be one of the common ones above. If it is a common problem, chances are you can identify an existing methodology to address it. If yours is not common, you may need to develop your own battleground strategy, like my friends who declare total war on time from order to delivery.
Do not be reluctant to customize an existing methodology to suit your own business’s culture or needs, like my friend introducing DFSS to a software design group. I say that with one important caveat in mind. Do not modify the system because you think it will make it easier. That is usually a mistake.
Modify a system because the change is right or necessary for you. Understand and never forget that you are declaring war. War is not easy; it is about defeating the enemy! Do not invite the mistake of a failed deployment because you cut corners or ignored advice.
Before adopting or developing an improvement methodology, identify your greatest enemy. With that enemy in mind, select or invent the weapon you need to eradicate your enemy. Make sure it is mostly common sense. Declare war and don’t look back. Methodologies work when we commit to the one that effectively destroys the greatest threats to our success.
Stay wise, friends.
If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com.