Operational Excellence in 7 Quotes From Its Founding Fathers

Georges Lteif

Georges Lteif

Software Engineer

Last Updated on May 10, 2022.
Subscribe now to stay posted!
About Us
7 min read

1. Overview

Operational excellence has its origins in the automotive industry. Pioneers like Shigeo Shingo, Taiichi Ohno, and W. Edwards Deming laid down a set of principles that were to become the foundation of successful business management across many industries.

In this article, I have selected a few quotes from these leaders that are both inspiring and highly relevant to any industry today, IT being one of those.

Operational Excellent in IT?

Operational Excellence can be applied fairly well to any service-oriented type of business. While manufacturing can be viewed as a prime example, IT is not very far behind.

I’m hoping that these quotes and their interpretations (which are heavily inspired by the fantastic book The Toyota Way by Jeffrey K. Liker) can be a useful tool to crystallize the ideas and concepts that underlie Operational Excellence.


Table of Contents


2. Operational Excellence in Software Development

Operational Excellence started in the car manufacturing industry and was perfected by Toyota in what is now known as The Toyota Way and the Toyota Production System (or TPS).

The concepts of lean manufacturing and Six Sigma then followed and as time went by, many different industries picked up on some of the tools and techniques and applied them with varying degrees of success.

The reader might ask, and rightly so, if there is such a thing as Operational Excellence in Software Development and, if indeed there is, what does it look like.

As you go on with this article, you will notice that the ideas and concepts we have presented are applicable to any industry where these three criteria are met:

Criteria 1: Service-Oriented Business

Service-oriented businesses share many similarities with the manufacturing industry. In fact, they all start with a client request that goes through a series of production processes before getting delivered to the customer. A company that provides goods and services can greatly benefit from applying the concepts of Operational Excellence.

Criteria 2: Size and Complexity

If the production processes involved in producing the goods were simple and easy, there would need not be any talk about improvement. This is certainly not the case in car manufacturing for example and alas, this applies equally well to IT. In fact, the tasks required to successfully deliver quality software are indeed complex and heavy.

To succeed, a group of co-workers needs to collaborate in a very tight and cost-efficient manner.

Criteria 3: Changing Environment

The environment is highly dynamic and constantly changing in such a way that transformation, adaptation, and continuous improvement must be ever-present if the company wishes to stay in the game.

And there is no better place to talk about constant change and complex jobs than in the technology industry in general but more specifically so in the field of Information Technology and Software Development.


3. Principles of Operational Excellence

The following quotes embody the main concepts of Operational Excellence as we understand and use them in this series of articles.

As you will probably notice, these concepts are not always technical. Oftentimes, they present metaphysical and philosophical aspects as well.

3.1 Ultimate Purpose of an Organization


In management, the first concern of the company is the happiness of people who are connected with it. If the people do not feel happy and cannot be made happy, that company does not deserve to exist.
Kaoru Ishikawa

Probably ever since the Industrial Revolution in the mid 19th century, the sole purpose of a corporation was to maximize its shareholder’s profit and outperform its competitors just to stay in the game.

That picture has now started to change.

In an article that appeared in the Harvard Business Review, there is a transformation that is happening at the C-Suite level in regards to an organization’s mission:

That strategic impulse—to identify a higher-purpose mission that galvanizes the organization—is a common thread among the Transformation 20, a new study by Innosight of the world’s most transformative companies. Fortifying this new view, the Business Roundtable last month released a statement signed by 181 CEOs stating that serving shareholders can no longer be the main purpose of a corporation; rather, it needs to be about serving society, through innovation, commitment to a healthy environment and economic opportunity for all.
The Top 20 Business Transformations of the Last Decade, by Scott D. Anthony,  Alasdair Trotter, and Evan I. Schwartz

Without a long-term altruistic goal, the organization has little or no incentive for sacrificing short-term financial goals to invest in its human assets.

3.2 Continuous Improvement


Are you too busy for improvement? Frequently, I am rebuffed by people who say they are too busy and have no time for such activities. I make it a point to respond by telling people, look, you’ll stop being busy either when you die or when the company goes bankrupt.
Shigeo Shingo

Achieving Operational Excellence requires a relentless drive toward continuous improvement. And for that to happen, there are three necessary ingredients that need to be present.

Firstly, continuous improvement cannot happen sporadically or in spurts; it has to be engrained into the processes of the system.

To illustrate this concept, we need to look at the andon system that Toyota uses to signal a quality problem. The andon basically refers to the light signal for help. When the signal is lit, the production line is stopped and the issue is investigated and resolved before work resumes. Stopping the production line, even for a few seconds, was unthinkable outside Toyota.

The second ingredient has to do with company culture and the setting up of the reward and punishment system. How many times throughout your career have you heard the phrase “it’s not my problem”?

The third ingredient is about improving the processes. For this, Toyota has devised and perfected the Kaizen system of workshops whereby teams convene to discuss, improve, and apply the recommended changes.

To conclude this section, and circling back to software development processes, our main subject of interest, we find that continuous improvement has been observed in the last principle of the Agile manifesto:

Agile Principle

Continuous Improvement

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

3.3 Seeing for Yourself


Observe the production floor without preconceptions and with a blank mind.
Taiichi Ohno

“Go and see for yourself” is a philosophy advocated by Taiichi Ohno and is known as Genchi Genbutsu.

Most managers today rely heavily on reports from their subordinates to obtain a snapshot of the situation on the ground. It is considered a waste of time to go and see for yourself.

Moreover, the practice of “going and seeing for yourself” may perhaps be seen to convey a feeling of mistrust or a knack for micro-management, something a manager would probably want to avoid.

Reports however can be misleading. Data can be inaccurate or biased. It is also at best an indicator of what’s happening rather than a full description of the underlying processes.

Finally, observing a process with an experienced eye can also yield vital information that may not be visible to someone with lesser time on the job.

3.4 Root Cause Analysis


Repeat ‘why’ five times about every matter.
Taiichi Ohno

Have you ever conducted a post-mortem exercise and were really disappointed with the results?

In most cases, the data retrieved during the investigation is taken at face value and lacks the necessary depth that’s required for a proper understanding of the circumstances that led to the failure.

Asking “why” 5 times guarantees that level of thoroughness during an investigation but, more importantly, it underlines the seriousness and commitment to finding and resolving quality issues.

3.5 Eliminating Non-Value Adding Effort or Waste


When you buy bananas all you want is the fruit not the skin, but you have to pay for the skin also. It is a waste. And you the customer should not have to pay for the waste.
Shigeo Shingo

Any activity or artifact of the production processes that do not add value to the final product is considered a waste of time and resources.

Waste can only be eliminated by close observation of the production processes and mapping those steps which add value to the final product.

In case you are still wondering what the definition of business value is, it is really those things that the customer is willing to pay for.

To get an idea of how this works, consider the example of baking a fresh pie.

The process starts when the customer places an order and ends when she receives her pie. Calculate the time spent working on the pie vs the time spent taking the order, inquiring about the weather, waiting for the oven to heat, waiting for the pie to cool, and many other little things here and there. You might be astonished by the result.

The whole idea behind the production optimization philosophy is that TPS or lean manufacturing advocates lie in or around eliminating all forms of waste.

3.6 Support From Leadership


…every successful quality revolution has included the participation of upper management. We know of no exceptions.
Joseph M. Juran

To illustrate this point, let’s go back to Software Development and Agile.

Although Agile project management has been around for two decades now, adoption has been relatively slow for many reasons.

According to the 14th State of Agile Survey, 46% of respondents cited “NOT ENOUGH LEADERSHIP PARTICIPATION” as a challenge and/or barrier to adopting and scaling Agile practices in their organization.

System-wide changes (such as the adoption of new project management methodologies like Agile) can carry a risk of disruption of business processes. This is why it needs to be sanctioned, perhaps even driven by higher management, otherwise, they have no hope of being accomplished.

This applies to major quality problems as well.

Quality issues that make it all the way up to the end-user are usually not isolated patches or mistakes committed unwittingly here and there.

In fact, they must be systematic defects in some of the processes. Fixing them will require changes on different levels and this is why individual initiatives may prove to be futile.

Successfully fixing systematic issues needs to involve the whole hierarchy and requires explicit sponsorship from the leadership.

3.7 Change and Resistance to Change


Two basic rules of life are: 1) Change is inevitable. 2) Everybody resists change.
W. Edwards Deming

One of the major paradigm shifts that occurred with the Agile movement was the attitude towards changing requirements. 

The traditional approach to software development usually consisted of requirements gathering phase at the very beginning of the project that was eventually followed by a design phase and then execution according to a certain plan.

In that scheme of things, there was little room for either improvement or iterations; any change in the requirements clearly constituted an amount of rework and a measurable waste of time and effort.

To avoid that, traditional project delivery methodologies stuck to the original plan trying to deliver on time and on budget even when the end result did not actually meet the stakeholder’s expectations or produce the promised values.

The state of software development had become untenable. Something needed to be changed in the way that change was perceived.

Transformation of Project Delivery

People had to acknowledge that change was inevitable and the processes of software development had to find ways to deal with it.

Modifying production processes through Agile and DevOps to engrain change in the software development DNA as a constant, ever-present factor was a major step toward Operational Excellence in Software Development.

This is where the principles of Agile, with regards to the ever-changing nature of software projects and requirements, became invaluable.

Shorter iterations, frequent software drops, earlier user feedback, and automated testing were adopted to better respond to change.


4. Further Reading


Technical Risk Management and Decision Analysis — Introduction and Fundamental Principles

1. Overview I could not find a better way to start an article on Risk and Risk Management than by quoting the opening lines of Donald Lessard and Roger Miller’s 2001 paper that, briefly but lucidly, summarizes the nature of large engineering endeavours. It goes like this: This article leans heavily on three handbooks thatContinue reading “Technical Risk Management and Decision Analysis — Introduction and Fundamental Principles”

Complexity and Complex Systems From Life on Earth to the Universe: A Brief Introduction

1. Overview Dealing with complexity is an integral part of our lives, even if we do not realise it.  An organisation can be modelled as a complex system from the scale of megacorporations right down to the smallest teams. The architecture of software solutions can be equally complicated, and megaprojects and implementations are certainly involved.Continue reading “Complexity and Complex Systems From Life on Earth to the Universe: A Brief Introduction”

Book Review: Programming the Universe — A Quantum Computer Scientist Takes on the Cosmos

Synopsis Most physical theories adopt a mechanistic view when examining natural phenomena where any system can be modelled as a machine whose initial conditions and dynamics govern its future behaviour. In this book, Programming the Universe — A Computer Scientist Takes on the Cosmos, Professor Seth Lloyd proposes a radically different approach centred around aContinue reading “Book Review: Programming the Universe — A Quantum Computer Scientist Takes on the Cosmos”

From Abstract Concepts to Tangible Value: Software Architecture in Modern IT Systems

1. Overview Software design and architecture are two very elusive concepts; even Wikipedia’s entries (ref. architecture, design) are somewhat fuzzy and do not clearly distinguish between the two. The Agile manifesto’s statement on architecture and design is especially brief and raises more questions than answers. The most common definition of software architecture is as follows:Continue reading “From Abstract Concepts to Tangible Value: Software Architecture in Modern IT Systems”

Business Requirements and Stakeholder Management: An Essential Guide to Definition and Application in IT Projects

1. Overview The complexity of business requirements in IT projects has experienced exponential growth due to pressures by increasingly sophisticated client preferences, novel technologies, and fierce competition. Consider, for example, the case of financial payments. In the mid-80s, most payment transactions occurred inside bank branches, and only the biggest banks offered services on ATM orContinue reading “Business Requirements and Stakeholder Management: An Essential Guide to Definition and Application in IT Projects”

Loading…

Something went wrong. Please refresh the page and/or try again.