Continuous Improvement Strategies: What to do depends on where you are

I was talking with Bill, an executive at a construction firm. “I’ve been reading about continuous improvement,” Bill said, “how would you implement something like that here?”

This is music to a CI consultant’s ears, but I didn’t launch into a description of the ideal CI implementation. Instead I asked, “Bill, suppose I said ‘how would you build a building?’ What would you say?”

Bill smiled. “Well, I’d ask you the purpose of the building and then I’d want to know something about the site.”

“Exactly.” We kept talking and ultimately ended up doing some work together. I’ve had similar conversations with others.

“What are you trying to do and why?” is the “purpose of CI” discussion and is often driven by words like “better, faster, cheaper or less risky.” It’s a conversation of competitive context and strategic priorities. The “site condition” follows the question, “What else is going on that might have an impact on how we implement CI?”

My Results-Alliance colleague, Dr. Richard Taylor, and I have come up with four common “site conditions,” we’ve seen in CI implementations:

Initiation - this a “greenfield site,” a company that has never done a formal CI initiative before. There may be challenges because every company culture is different, but CI concepts are fresh.

Acceleration – this is one kind of “brownfield site,” a company that started CI and then got bogged down. This is like a construction site where an owner/contractor started to build a foundation and then asked for help, “fast-tracking” construction. There’s a good plan, no need for demolition. It just needs to be speeded up and strengthened.

Re-formation – this site involves some construction difficulty. It may be one where leadership support was an afterthought or one where different brands of CI (Lean, Six Sigma, Agile, etc.) have been tried multiple times. Implementing CI in these environments is tricky. It requires revisiting purpose and building on what is still solid.

Transformation – As a CI “site condition,” it’s a company with a mature CI program - supported by leadership, good CI training, established experts, who deliver significant improvements every year. Where the ‘T’ word is used CI can be perceived as “incremental” and a “bigger change” is needed. CI experts are not called to the table. “You guys are ‘nuts and bolts,’ we are looking for “Big Ideas, you know, Design.”

Each of these four site conditions requires different strategic actions to have successful continuous improvement:

Actions for CI Initiation

Last year I posted an article The CI Initiative Roadmap, in which I outlined an approach to implementing CI. While the components of implementation that I listed, Leadership, Training and Infrastructure, can be applied in each of the four site conditions, when initiating CI, one should address them in that order.

Leadership: Start by building leadership commitment. Facilitate agreement among leaders as to why the company needs to improve, and which strategic priorities might lend themselves to process improvement.

Facilitate agreement on a problem-solving model. (Ric Taylor and I have become methodology agnostic, but we believe you should pick one and stick with it.)

Agree how training and infrastructure will be funded. CI initiatives can quickly become self-funding if some portion of the cost savings and revenue enhancements are applied to the effort and not just absorbed in the budget.

Training: Next train a single function or business unit with “just-in-time” training. There are many decisions about who gets trained when, whether to have CI experts or train everyone, how much training and how long, etc. We believe in starting slowly.

Infrastructure: Clearly the training and CI toolkit needs to be built from the very beginning. We believe that one should build benefits tracking and project databases, sooner rather than later. It is OK if celebrations and rewards evolve later.

Improving something quickly is important to pace and sustainability of CI. Therefore be deliberate about selecting the first improvement projects. Leaders should help teams pick high strategic impact projects that engage many people. A filtering matrix I have used to facilitate this discussion is shown below:

Ric and I would recommend against picking the very engaging but low impact project. While “moving the water-cooler” projects may be fun teaching opportunities, they can undermine the seriousness of CI and make it hard to build momentum.

Executives want to start with the highest impact projects and will trade-off engagement for results. High engagement/ high impact projects may be just “too tough” to start with and low engagement/ high impact projects build a class of CI “experts,” while everyone else disconnects from CI. Picking middle ground is often the best place to begin.

Actions for CI Acceleration

Accelerating CI depends on why the initiative has bogged down. There are many reasons, but let’s focus on two, “not invented here” (NIH) and failing to translate or replicate projects.

NIH, happens when one group of people rejects CI because another group has had success, “That’s all well and good for Operations, but Sales is a personal business,” or “Of course the Service SPU likes CI, they’re driven by response time. We have hard technical specs to hit.”

CI works in service or tech and in operations and sales; there are processes to improve everywhere. The only way to handle NIH is not to argue it straight on. Revisit strategic priorities and identify which will respond to process improvement. Get the numbers for missed technical specs, for example, or the data about new sales as a percentage of prospecting calls. Encourage leaders to talk about the number comparisons within a group –“We’re here today, next quarter we need to be here.” Emphasizing the “delta” is the soul of improvement –“now vs. then” not us vs. them.”

Failing to translate or replicate when picking CI projects leads to a lack of learning, a key component of sustaining results. The real money in CI is in replicating projects; translating the activities from one project to the next saves time. Continually starting fresh, with a brand new challenge is a way to induce CI burnout.

I heard a good example of the benefits of replication from Shaun, a manager whose team had given up on CI. He lamented,

“My people had been trained and re-trained; they were just tired of coming up with new projects. Unfortunately, I had committed to my boss that we would make improvements in three key areas. We were far behind.”

“So I told everybody to go on CI Connect [the company CI project database] and come to our next meeting with at least one project that someone else did that we could just implement. Let’s ‘steal with pride’ I said. At the next meeting we argued about which one to do first. We finally agreed on Charlene’s idea and I gave her a PowerPoint slide I’d made up with the ‘Stealios Award’ written on it, I handwrote her name in. Then I said we’d do the same thing again next week. After a while people were fighting over these awards and I was giving out so many I had to start spending money, 99¢ apiece for a plastic award frame. We blew through our improvement goals.”

I congratulated Shaun on the idea. “Nah, I stole it from another SPU,” he said. Translation and project replication accelerates learning, results, and sustainability.

Actions for CI Re-formation

Re-forming will have unique actions depending on the difficulty constraining CI. I’ll focus on two constraints, competing methodologies and “justified impatience.”

The secret to success at CI is to pick one methodology and stick with it. This kind of discipline is not human nature. So someone says, “What we really need is ____” (a different methodology) it confuses people and slows everything down. The solution to this is not to shut one group down in favor of another’s favorite methodology. Neither can you just look the other way because it can turn into “best-practice-Armageddon.”

Engage the loudest voices and imagine yourselves integrating a merger. Facilitate a discussion about aspects of methodology which can be autonomous and which might be strategically interdependent. You might use this filtering matrix to guide discussion:

Getting everyone on the same page makes communication easier and saves time.

What do I mean by “justified impatience?” Too many times I have arrived to help a company with their CI initiative and heard business leaders say, “Maybe we chose the wrong people to be CI experts, maybe they need to be re-trained, I don’t know, everything takes forever!”

I have been on far too many sites where the word ‘process’ is a synonym for “bureaucracy.”

I arrived at one site where CI experts had spent two years attempting to map every process in the company. They hadn’t improved anything, “yet.” These CI experts were told to “get on with the value-added part of your career, somewhere else,” and the company started over.

We tell CI trainees to “respect the rigor of the methodology,” but also to “improve something quickly.” There are many quick wins: clarifying roles and responsibilities saves cycle time; if seven people each does work differently adopt one process; create a two bin materials storage to avoid stock-outs; translate earlier projects and so on.

Where “justified impatience” exists, correct perception by scoping huge projects down to solve it in stages or emphasize interim “good” solutions while the “great new system” is designed or clarify timing expectations with the sponsor up front and meet schedules.

Actions for CI Transformation

When I was at Gemini Consulting, the ‘T’ word meant large scale multi-dimensional change. Today it has evolved to mean “Digital Transformation” - new business models to respond to disruptive technology, a kind of whole company re-invention through innovation. Some consider innovation as fundamentally different from improvement. I posted an article describing the Innovation and Improvement Continuum wherein I posited that the similarities outweighed the difference. Both methodologies use the same thinking and tools, but innovation frequently has a longer time horizon and is more product than process focused. Because Innovation often has a larger risk-reward investment profile it requires stage gate evaluation with go/no go decisions as I described in Implementing Innovation.

Continuous improvement brings out some people’s discomfort with change; transformation is likely to engender more of that feeling. Here are a few ideas to keep in mind:

Transformation is worthy of an article by itself, but as a “site condition,” it is an indication of a need for next phase of improvement, not an opportunity to “throw the CI baby out with the bathwater.”

Starting to implement continuous improvement or innovation, like building a building, requires an understanding of purpose and the CI site condition. Of course, every site is unique, but I hope this post will start you thinking about what might shape how you implement CI on your site.

What has worked for you in implementing CI? What pitfalls have you experienced? How can we improve the way we improve?  

• I was talking with Bill, an executive at a construction firm. “I’ve been reading about continuous improvement,” Bill said, “how would you implement something like that here?” 
• Methodological cross training
• A third custom methodology that both groups use
• A set of circumstances under which to use one methodology or the other
• Common language and interface protocols when the two methodologies must work together.
• Innovation often happens outside of an industry context; scanning for new technologies and business models them pays off.
• Innovation still requires a “define phase” – innovate within a “job to be done” or underlying functionality.
• Innovation still requires customer focus. Customers may not be able to tell you what they want (e.g. portable music – Sony Walkman, “1000 songs in your pocket” – iPod) but to “delight them with the stuff they don’t even know they want yet” you have to think like a customer.
• Every new product or service doesn’t necessarily require a new process.
• When automating processes, redesign before automating. Otherwise you’ll just turbocharge rework.
• Rapid prototyping is a powerful process that will speed time to market, but it still requires documentation, testing and evaluation.
• The adoption of new technology takes planning. It’s never as instantaneous as early adopters assume nor as slow as late adopters imagine.