The Culture of Continuous Improvement

Managers have a great set of tools at their disposal that can be deployed to help ensure their businesses are continuously providing products and services efficiently. These tools fall under the umbrella of continuous improvement. But they only work if used in the right way—which requires understanding what continuous improvement is really all about.

Too often I have seen a “continuous improvement” project justified by a large payback only to be reversed a few years later—a cycle that defies comprehension. Consider the example where an operator in an assembly process had to go to the warehouse and get raw materials every time they ran out. To give the operator more time on assembly, there was a cost-saving project executed where logistics personnel would affect the movement of raw material so that the operator would dedicate more time to the assembly station. The extra production was seen as the value of the project and thus the justification for any costs for developing a signal to the logistics person to deliver the parts. After the change had been made, another manager realized that the logistics workers were paid more than the operators, so they put in another project to have the operators get their own raw materials when they needed them. That project was justified by the difference in pay multiplied by the estimated hours required per year. From an executive perspective, there have been two projects done, each with cost savings. As far as the operator is concerned, nothing has changed. This does not represent a cycle of cost savings but a manipulation of scope and accounting rules. And that’s not continuous improvement.

Continuous improvement is about shifting the focus from capital equipment to operational culture. After World War II, manufacturing responded to the need to ramp up production by buying equipment as quickly and with as much capacity as possible. Mass ad hoc capital purchases seemed to be an efficient response to the urgent needs of growth but inherently created inefficiencies on a system level (akin to a house being built one room at a time). Toyota was the first company to push back on the capital equipment approach (mostly as a result of a lack of resources) and showed through lean manufacturing that there are better approaches to scaling than just buying capital equipment.

This was the first appearance of continuous improvement anywhere, but similar non-capital approaches such as Six Sigma (a statistical approach to continuous improvement), Business Process Reengineering (a management layer approach to continuous improvement), and Total Productive Maintenance (a maintenance approach to continuous improvement) found ways to improve productivity, flexibility, and quality through focusing on coordination rather than equipment. Each of these creates a different approach to improving output rather than blindly investing in capital equipment (typically, the most expensive approach). However, the one thing they all have in common is that they push decision-making down to where the worker is closest to the issue.

This sounds like a decentralized approach (and it can often start that way). However, continuous improvement cannot endure for any length of time if it does not align with business strategy! The best first discussion for continuous improvement involves how the business strategy should be reflected in the process metrics and if there is evidence in the process metrics to show alignment. If the strategy implies low cost, then cost metrics should be front and centre. If the strategy calls for a shorter lead time, then order-fulfillment metrics will play a larger role. If the company is technology driven, then the metrics may be less operational and more “time-to-market”-type coordination metrics. In any event, the process metrics (and thereby the process dashboard) must be scrubbed to confirm alignment and highlight gaps. This should generate urgency for the continuous improvement program around a focused set of metrics as opposed to a general attempt to “save money” or “make things better.”

The current business climate lends itself to improved production using continuous Improvement. Companies in all industries and regions are complaining about the same issues: lack of skilled workers (or workers of any kind); disruption of long supply chains and the resulting introduction of increased logistics costs and instability; and demands on management’s attention toward non-value-added activities such as worker motivation and regulation. The symptoms are recent, but the problems are much more enduring than one expects.

In a 2023 report entitled Rekindling US productivity for a new era, the McKinsey Global Institute highlighted that in the past 15 years the U.S. labour productivity growth rate has averaged just 1.4 per cent. Looking at OECD data for labour productivity, we see that the productivity improvement average of the OECD has declined and that Canada and U.S. productivity growth has been steadily low. Conversely, Japan showed exceptional growth from the 1980s to 1990s; this is consistent with the successes associated with lean manufacturing, notwithstanding the tapering off as lean companies expanded to other geographies.

FIGURE 1: Annual Labour Productivity Growth Rate by Decade

Current macroeconomic factors like inflation and a tight labour market make a compelling case for the need for doing more with less. This is not the type of gap that can be filled by disparate projects each saving a little bit but rather calls for a coordinated effort to do more with less on a corporate-culture level. The time is ripe for a successful continuous improvement boost.

CI Culture: Secret Ingredient and Achilles Heel

Lean has been credited for taking Toyota from obscurity to the top of the automotive industry in the last half of the 20th century. During the rise of Toyota, many attributed Toyota’s success to such things as low labour costs, cooperative unions, a worker culture of job-for-life, and other aspects of Toyota’s Japanese environment—all of which have been outlasted by Toyota’s success. As well, Toyota invited competitors to tour its facilities, implying that the improvements were neither just low-hanging fruit nor a fluke, but rather a predictable approach to continued improvement that can be sustained even after competitors know its “secrets.” Competitors such as GM, Ford, and Chrysler were happy to copy specific tools in assuming they could replicate the Toyota success, but they were disappointed with their results.

I worked as an engineer at General Motors, and it was enlightening to see the frustration of North American automakers with Toyota. The most apt example was the implementation of the Andon cord.

On the automotive assembly lines at Toyota in Japan, cables hung from the ceiling near each operator station that could be pulled to stop the assembly line. The idea was that if any operator saw a problem with a part, they could stop the line and effectively call all knowledgeable employees to best address a production concern. The team was immediately assembled (including the operator) to address any issues before the line was started again. This tool was used by Toyota to perfect its assembly line production quality and was considered a big contributor to the success of lean manufacturing. We adopted the Andon tool at the plant where I worked in North America by installing Andon cords on the assembly line. Now understand that when the assembly line stops, the plant effectively stops making money—often to the tune of thousands of dollars per minute. So as much as there was a cable the operator could use to stop the line if anything was amiss, the operators and supervisors were discouraged from ever pulling it, thus negating any benefit. Toyota embraced a culture where the line operator (the closest person to the decision of whether the product is good or bad) was the most valuable person in the plant for this decision. Conversely, in North America, the impression was that the higher your salary, the more valuable you were, making the line operator one of the least valuable people in the plant. So, if any operator pulled the cable for any reason it was seen as a way to get out of work and typically the first person to respond to the action was the plant superintendent telling the supervisors to get the line running again, regardless of the issue, before any investigation or discussion could happen. The problem was never that the automotive plant I worked at didn’t implement the lean tools; the problem was that nobody at GM at the time embraced lean manufacturing as a cultural change.

Other continuous improvement methodologies found similar success when they started but tended to sputter. Six Sigma was a very statistically-based methodology and worked well in high-tech environments where statistical knowledge was common. Unlike lean, which focused on the assembler, Six Sigma focused on the engineer closest to the point of variability for the product or process. In an engineering environment it was very successful—less so when the companies tried to extend that success to non-engineering areas such as marketing or accounting. Again, you could teach marketers the tools of Six Sigma but the statistical culture was elusive anytime you moved away from engineering.

There are many other ways to improve decisions through continuous improvement by focusing on a culture in the organization that can positively affect the outcome (middle managers for Business Process Reengineering or maintenance roles for Total Productive Maintenance, for example). But taking your eye off the culture removes the superpower. More recently for most continuous improvement methodologies, there has been a focus on replicating the tools and ignoring the culture—which has had disastrous effects. The methodology no longer works once mass markets try to sell solutions in the form of either consulting implementations or bestowed certifications: the tacit cultural connection is too often overlooked. This problem of trying to replicate the tool of continuous improvement without regard for the culture is a problem we have been facing for the last two decades.

Figuring Out Trust

When lean manufacturing first started, the only consultants people trusted were those directly from Toyota City in Japan. The thinking was that if you worked at Toyota then you must have been exposed to lean manufacturing and might even be an expert in it. From what I understood, those implementations were very successful. However, over time there were outside offerings of consulting in lean manufacturing. In the beginning, there were maybe a dozen tools and some foundational principles that you needed to employ. As time went on and consulting dollars grew, there were more tools (and correspondingly more consultants to offer these tools) that did not seem to add anything to the canon of continuous improvement.

Similarly, early successes in Six Sigma came from Motorola, so consultants who had experience at Motorola became coveted. After the Jack Welch-driven GE successes in Six Sigma, the pedigree became muddied to the point where there were many competing offerings of dubious value to bring Six Sigma to your company. With the publishing of Michael George’s Lean Six Sigma, people quickly realized that tools applied to lean manufacturing could also be applied to Six Sigma and vice versa.

As much as this is very true and insightful, it does not mean that a lean manufacturing project is interchangeable with a Six Sigma project, as most people implied. In fact, many other disciplines could be drawn on to lend insightful tools to either lean manufacturing or Six Sigma projects—and that did happen—but that did not mean that somehow you could lump these projects together.

The difference was always the management culture: lean manufacturing projects were directed at the operator culture and Six Sigma projects were directed at the engineering culture. The problem was that if you had never seen a proper lean manufacturing or Six Sigma project, then you could be led to believe that any implementation of lean or Six Sigma tools constituted a success. This is very far from the truth if the cultural context is not considered.

It wasn’t long before certification programs embraced this one-size-fits-all notion and claimed that teaching tools in the absence of the context of implementation was sufficient. Some offerings went as far as creating new tools to differentiate themselves and make them sound superior. This is tantamount to certifying a Class-A mechanic by simply giving them a quiz on the tools on the bench without ever getting them to look at a car.

The tools are indeed important, but not sufficient. And including new tools (perhaps akin to a plug puller invented in-house) does not make the certification more credible. There has to be something between “only trusting employees who worked at Henry Ford’s Rouge River plant in 1908” and “limiting the testing to a description of tools” with which we should be able to certify a mechanic—and there is. Furthermore, if you have a bad mechanic, you will know it by your car not working. If you have never seen a successful implementation of continuous improvement, then you will likely be fooled by someone who can only talk you through the tools.

The shibboleth is whether the consultant or graduate talks about cultural issues in implementation (because cultural issues make up more than half of most projects) and how they see your culture changing. If your continuous improvement resource is not talking about culture, then they are probably not what you want.

Building Solid CI Foundations

Sometimes, companies who have neglected operations erroneously feel they can leapfrog operational issues by moving directly to continuous improvement. It is imperative to understand the operations as a system before you begin any good continuous improvement regime. There are two modes of failure for continuous improvement initiatives, and the first is the mode where operations management staff knowledge is weak, so you are making mismanagement more efficient. Managing the flow of parts through a factory of machines or managing staff to provide services is really managing a system. The erroneous assumption is that doubling the input to a system will double the output. Managers without an understanding of the systems view of operations will find themselves frustrated and throwing resources at problems without getting the desired results.

In these cases where operations management is lacking, no amount of continuous improvement of any kind can help. The first step in these situations is to develop process maps and capacity models to understand how bottlenecks can be identified and addressed and where part/information flows get lost. In a situation where bottlenecks are not managed, any savings will evaporate once the schedule changes or when a machine breaks down (if these savings ever existed at all).

Conversely, if a person with knowledge of operations management is brought in, then there will be a lot of savings in balancing lines, coordinating efforts, and the like—but it will not be continuous improvement as much as just doing the right thing.

Symptoms of a poor operations management foundation include:

  1. Trying to work all departments as much as possible all of the time
  2. Frequently changing improvement project focus—often when projects have barely started
  3. A lack of coordination between operations and other parts of the company like marketing or R&D

These symptoms are all a result of poor operations management, and adding operations management skills will address these faster than addressing each symptom directly. Getting a handle on the system of operations management supersedes any continuous improvement effort.

Once you clarify your operational situation, you may see a need to purchase new equipment, shift resources, or rethink product/service offerings—but all of this has to happen before you begin any continuous improvement efforts.

Avoiding the Cost-Savings Trap

Once you have identified bottlenecks and begun managing your operations as a system, there is still a lot of potential to improve. As much as clarifying your operations may expose obvious process improvement projects, not all projects are of equal value. Taiichi Ohno identified the seven wastes to help him create the Toyota Production System, which became lean manufacturing. The seven wastes are: transportation, inventory, movement, waiting, over-production, over-processing, and defects. (You can remember them with the mnemonic “TIM WOOD.”) If you idly watch operations with these wastes in mind, it is easy to see many opportunities for improvement, and each opportunity will have a different payback. The first problem you have to address is: How do you compare and measure these projects?

“If you are strictly following continuous improvement, you will not do all the projects you can do but rather only the projects you must do. This can only be dictated by a high-level metric that matters to the company—and it is not cost savings.”

Unlike the first failure mode, where the culprit is a lack of operations management acumen, the second failure mode in implementing continuous improvement is using the wrong metric in project selection. Too often, “dollars saved” or ROI is used as the differentiator for continuous improvement projects, and that quickly becomes problematic. These metrics are fine for other projects that can be viewed in isolation, but the very word “continuous” in the term “continuous improvement” should indicate that there is some coordination involved. If you have to decide between buying one big oven or two smaller ovens, then use whatever metric you want because purchasing ovens is not a continuous improvement project. Each project should be decided within the scope of project effect (i.e., stakeholders and processes affected)—continuous improvement projects affect everything. For continuous improvement to be effective, a metric has to be chosen that represents all projects in full scope.

At one of my former employers, time-to-market was important to success, so we chose “days-to-market” as the measure of the continuous improvement program. Not all projects could directly be associated with days-to-market, but the exercise was still immensely helpful given that the projects that did not directly associate were either put in a suite of projects that collectively were associated with the metric or immediately dropped.

If you are strictly following continuous improvement, you will not do all the projects you can do but rather only the projects you must do. This can only be dictated by a high-level metric that matters to the company—and it is not cost savings.

As noted in the introduction, continuous improvement projects are sold too often by highlighting cost savings. Consultants or newly-minted certified CI graduates will point out project after project that will return money to the company. This is a trap that companies have been falling into for the last 20 years at least. Continuous improvement naturally returns cost savings (and plenty of it), but projects are difficult, disruptive, and not worth doing unless they move the company in a positive direction.

In other words, if you are doing continuous improvement right, then you are activating a culture. Thus, you might as well activate the culture in the direction of growth for your company. Don’t waste your time on anything less.

The Problem with Low-Hanging Fruit

Often in continuous improvement circles, “low-hanging fruit” (simple projects for disproportionally high returns) is cited as the reason for wanting to carry out continuous improvement, as if these projects are there for the taking for anyone with CI credentials. This notion both mocks the field of operations management and diminishes the value of continuous improvement credentials.

It is true that completing a simple project for a sizable return helps in creating momentum and can benefit a continuous improvement culture. However, this is only true if the advantage is converted to a culture of positive change.

Often the opposite is true: that low-hanging fruit poisons the culture and arrests any long-term improvement chances. Often, low-hanging-fruit projects involve making a better decision than was previously made, which invariably involves calling out someone who did not do their job as well as should have been expected. Sometimes management will suppress criticism of the employees by saying that the benefit of the low-hanging-fruit project is that the company has the knowledge to do it better once identified. Lean has always embraced “making mistakes visible” because once you see the issues you can properly address them. However, low-hanging fruit tends not to educate the culture on what can be improved as much as divide the culture between those looking for mistakes and those who made them.

The point of continuous improvement is always a positive cultural change, and low-hanging fruit often has the opposite effect: creating a culture where workers are actively trying not to get caught by the continuous improvement police.

Stabilize, Synchronize, and Standardize

You have identified your bottlenecks (or at least narrowed down the list). You have chosen a population whose change in culture will bring better results for your company. You have a list of projects that you feel could return savings and/or move the company in the right direction based on a cultural shift in that target population. You will need to group the projects into outcomes and dismiss the projects that do not align with the direction your company is going in. You will likely have projects on your list that have a very low return but enable bigger projects. In fact, it is worth walking through the operations environment again and looking for just such projects, given that you now know what you need to enable.

Some of the projects on your list will clearly be more central to the improvement effort than others and the processes within those projects will get a lot of attention. Stabilizing these processes will go a long way to creating a better environment for change and higher chances of success for effort. When I say “stabilize” here, I mean consistency across shifts, departments, and plants.

It is odd to ask if an operational area is stable given that people show up every day, execute the prescribed tasks, and produce an outcome that is favourable to the company. But the question is: Does this happen consistently? More specifically: Do all shifts and all departments take the same approach when faced with the same tasks in the same environments for a consistent outcome? It is important to the efficiency of all projects (and indeed the whole exercise) for these to be made consistent. If two departments have different approaches for the same tasks, then you should be compelled to standardize the process across departments so future projects do not have to consider the different approaches in their execution.

The best way to audit this stability is by watching a new employee get trained for the job. If there is no structured training, then you can assume there is no stability. Even if there is a published training document or standard operating procedure document, there is no guarantee that it is being followed. When you find different approaches to similar tasks, there are two benefits that can come from standardizing the approaches: (1) an opportunity to compare approaches to arrive at a best practice, and (2) a predictable approach that can be analyzed when an improvement project is required.

From stabilization, you move to assessing and improving the flow of materials and information. That step is followed by adjusting metrics and management lines to make all of the improvements part of the standard.

If you have gotten this far in your implementation, then you are clearly doing it right. Alternatively, if you have been following a fake continuous improvement implementation then you will soon be disappointed at the results. You will likely have collected incremental cost savings of $100,000 here or maybe $1,000,000 there, and when you add it up over time it will sum to a big number only for people to realize that it was all a lie: there is no way the company is that much richer. This realization will garner negative reaction to continuous improvement as a methodology, hampering future attempts.

In the chart at the end of this article, “Three Approaches to Continuous Improvement,” I have tried to list what a good implementation will look like compared to what the implementation would look like using fake continuous improvement (as outlined above) or applying continuous improvement in the absence of good operations management practices.

To say this problem is new would belie history.

Consider this quote from Restoring Our Competitive Edge: Competing Through Manufacturing, a book about the effect of a lack of process improvement by Robert Hayes and Steven Wheelwright:

 This deterioration in America’s productivity growth rate—compared both with historical experience and current rates of its major foreign competitors—fueled inflation, undermined the country’s ability to compete in international markets, and, ultimately, constrained improvements in its standard of living.

 Even though the quote comes from a book published in 1984, it both has relevance today and highlights our lacklustre response of the last 40 years. Companies can show a better return for investors by doing share buy-backs, changing the jurisdiction of taxation, extending patents, or using other tricks that do not affect GDP. But the best way to help people in the economy is to create new products and services or provide existing products and services more efficiently. That is what we need more of!

Continuous improvement is a great set of tools to help provide existing products and services more efficiently, but only if it is done right. Japan did it right in the last half of the 20th century by empowering its corporate culture to make a high-quality car at a low price; our more recent attempts have been less successful notwithstanding more consultants and trained “experts” who purport to help. But if you are not enabling a culture in your organization to take the operations in a new direction then you are likely not doing it right.

Note: VSM refers to value stream mapping.

About the Author

Dino Pupulin is an engineer and executive who has taught business at the Ivey Business School at Western University and George Brown College, and assisted class instruction at the Schulich School….Read Dino Pupulin's full bio

Leave a Reply

Please submit respectful comments only, including full name, professional title, and contact information (only name and title will be posted). Required fields are marked *