A culture of excellence

A couple weeks ago, I attended a fascinating webinar called, "Creating a Culture Committed to Excellence." I was interested in the subject because I've often felt that a company's culture has a decisive effect on how it behaves, far more decisive than its Quality Management System. And I'm sure you've all seen the Internet meme about the relative importance of culture and strategy. But I've never had any clear or practical ideas how to create a culture of excellence.

Meme from an article by Fred Waswa on LinkedIn, March 19, 2020

The point of the webinar was that you really can create such a culture. I didn't get the complete recipe — it was only one talk, and the speaker works for a consulting firm that charges good money for this kind of thing — but the basic idea was to identify nine fundamental principles that define a culture of excellence and then determine which good management practices embody and enforce those principles. The speaker said that for small organizations, they had developed a list of 51 good management practices to implement; for large organizations, the list doubled in size to 102.

(In case you are curious, the consulting firm is called Organizational Excellence Specialists. The founder and principal is Dawn Ringrose. They are a Canadian company located in British Columbia, and you can find the website here: https://organizationalexcellencespecialists.ca/.)

The nine principles are as follows:

1. Leadership involvement
2. Alignment
3. Focus on the customer
4. People involvement (cooperation and teamwork)
5. Prevention-based process management
6. Partnership development
7. Continuous improvement
8. Data-based decision making
9. Societal commitment

This list might look familiar. In fact, it should. The ISO 9001:2015 standard gives an almost-identical list of "Quality management principles in clause 0.2. That list has seven elements instead of nine, and runs as follows:

The quality management principles are:

• customer focus; → matches (3) focus on the customer
• leadership; → matches (1) leadership involvement, and (2) alignment
• engagement of people; → matches (4) people involvement
• process approach; → matches (5) prevention-based process management
• improvement; → matches (7) continuous improvement
• evidence-based decision making; → matches (8) data-based decision making
• relationship management. → matches (6) partnership development, and (9) societal commitment

What's important, though, is not that the nine principles are unoriginal. If anything, that's a benefit: it means that when a company implements a program like this one to achieve excellence, their work should be fully consistent with the measures they have already taken (or might take in the future) to achieve Quality. It's reassuring to hear that excellence and Quality have something to do with each other.

No, the important part is that someone has thought through what concrete activities — what good management practices — serve to implement these principles in the real world, to plant and nurture them in soil where they might not have otherwise sprouted on their own. I have not myself worked with Organizational Excellence Specialists, so I can't vouch directly for the impact of their work (though their website has a full page of testimonials from satisfied customers). But I welcome the attention to culture. For all of us in Quality, that has to be the next frontier. 

       

Is employee engagement out of date?

Last week, Fast Company published an article that argued, "Employee engagement is out. Here’s a better metric."

It's a good article. The basic point isn't that there's anything wrong with employee engagement as such, but just that it's not a cure-all. By itself, employee engagement won't solve all your problems, any more than the perfect process or any other quick-and-easy panacea.

But surely that should have been obvious all along. Wasn't it? The fundamental point is that if you want good work — if you want Quality — then the people doing the work have to care about what they are doing. Only when you care about your work will it be any good. And the connection with employee engagement is a negative one: disengaged employees are a lot less likely to care about their work. So yes, if you want to see good work you should encourage employee engagement — but only as one tool among others, in order to remove one of the well-known obstacles to Quality. You can think of employee engagement as just one more of those techniques or gimmicks we talked about last week, along with preventive maintenance, calibration, and statistical process control. It is as if the whole corporate push for employee engagement over the past years had been the result of some massive, economy-wide Lessons Learned activity which identified employee disengagement as one more way that things can go wrong, and which therefore defined measures to prevent it.

In fact, the article then goes on to recommend "great work" as a better goal than employee engagement, and the definition of "great work" involves key behaviors that should look pretty familiar: continual improvement, Gemba walks, cross-functional problem-solving, Quality circles, and the other standard tools of the Quality trade. Specifically, the article says:

Here are the five key behaviors that employees who produce great work demonstrate:

• They ask the right questions, like “How might this task/process/problem be made easier/faster/safer/better?”
• They go and see, which may mean standing on an assembly line or watching users interact with a product.
• They talk to an outer circle, gathering information and insight from a broad array of experts.
• They improve the mix, continually fine-tuning and improving upon their work.
• They deliver the difference, remaining laser-focused on positive outcomes.

Don't these all sound familiar?

I'm not trying to criticize the article. Quite the contrary; I agree with it. My only point is that everything it reports is exactly what we should all have expected, because there are no silver bullets.

All the same, caring about what you do is remarkably powerful.     

        

Lessons learned and the growth of Quality methods

Before I leave the topic of problem-solving, I want to look back briefly at the idea of "Lessons Learned." We talked about this when looking at the anatomy of an 8D, and at that time I said this step (D7) is where you widen your scope to see if the same problem you just solved might be about to show up somewhere else. In that context it's a risk-mitigation step, and of course that's a perfectly good way to understand it.

But in a larger sense, the idea of Lessons Learned underlies the entire field of Quality itself. It is not going too far to see the whole collection of Quality methods as the output of a huge, ongoing, worldwide Lessons Learned activity.

Laws of motion from Scientific law - Wikipedia

For consider: Quality is not primarily a theoretical system. Unlike geometry, it does not proceed from axioms. Unlike physics, it does not rest on natural laws. There are no famous equations that have revolutionized the field. Rather, Quality is a collection of techniques for avoiding problems and getting what you want. And each of these techniques grew, logically, out of analyzing problems when they happened to find out how they happened so that future generations could make sure they never happened again.

• Because things never turn out the way you expect, Quality systems require testing after development (and often many other times as well).
• Because machines break down after they've been used for a while, Quality systems require preventive maintenance.
• Because measuring tools can slide into inaccuracy over time, Quality systems require calibration.
• Because customers and contractors often remember the project differently, Quality systems require written specifications, contract review, and (where appropriate) formal customer acceptance.
• Because no two people ever walk out of a meeting with exactly the same understanding of what went on, Quality systems require meeting minutes and other similar administrative tools. 

Even the most mathematical part of Quality — I mean the introduction of statistical methods by W. Edwards Deming — was introduced as a way to solve the problem of variability of output in industrial production. There's no obvious a priori reason why statistics should have such an important place in the practice of Quality; but when you realize that one of the big problems to be solved has to do with variable outputs, statistical analysis and control becomes a logical approach to take.

And this is why the Quality system for an aircraft manufacturer is so very different from the (mostly informal) Quality system for a hamburger stand. Each of them has a system of some kind — the hamburger stand has to do something to make sure the hamburgers come out OK — but the problems they are trying to solve are very different. Therefore the Lessons Learned that they have to apply are very different. And therefore their Quality systems have almost nothing in common.

Robert Pirsig.
Photograph by Ian Glendinning.
(c) 2005 Dr Anthony McWatt

Outside of commercial or industrial applications, discussions of Quality-with-a-capital-Q are often associated with Robert Pirsig, so it is interesting that he says the exact same thing I am saying here. When he talks about teaching rhetoric (English composition) and introducing all the normal rules for improving the Quality of a piece of writing, he explains:

At first the classes were excited by [an earlier] exercise [about identifying good writing], but as time went on they became bored. What he meant by Quality was obvious.... Their question now was, "All right, we know what Quality is. How do we get it?"

Now, at last, the standard rhetoric texts came into their own. The principles expounded in them were ... not ultimates in themselves, but just techniques, gimmicks, for producing what really counted and stood independently of the techniques — Quality.... He showed how the aspect of Quality called unity, the hanging-together-ness of a story, could be improved with a technique called an outline. The authority of an argument could be jacked up with a technique called footnotes.... And if a student turned in a bunch of dumb references or a sloppy outline that showed he was just fulfilling an assignment by rote, he could be told that while his paper may have fulfilled the letter of the assignment it obviously didn't fulfill the goal of Quality, and was therefore worthless.*

It's the same in industry and commerce, and in every place where the Quality business makes an appearance. What matters is Quality — getting what you want. All the structures and methods that come along with formal Quality systems are just techniques or gimmicks to keep things from going wrong, which is why following them blindly is never enough by itself to guarantee Quality. And we discovered every last one of them by analyzing problems and looking for Lessons Learned.

__________

* Robert Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry into Values (New York: William Morrow & Co., 1974, 1999), p. 208. In his later and more philosophical book Lila, Pirsig refers to these same kinds of gimmicks as "latching-mechanisms."           

What about human error? Part 2 of 2

Last week I talked about the concept of "human error" — and especially about why we in the Quality business always insist that "There's no such thing as human error" when it's obvious that there is. I argued that while of course we all know that humans make mistakes, that's never the place to stop in an incident-investigation: focusing hard on human error makes your participants clam up if they are afraid of being blamed, and it shuts off the chance to find systemic improvements that could make future mistakes less likely. Another way to say this is to say that human error is a symptom but not a cause. Somewhere in your system, there is something else that triggered or allowed the human error to happen, and that's the thing you want to find and control.

But if human error is a symptom then we really need to understand what kinds of human error we might encounter, because each different kind of error is probably a symptom of a different cause and therefore has to be treated in a different way. If you go to the doctor because of pain, he'll treat you differently depending whether the pain is in your head or your elbow.

Fortunately this work has already been analyzed and tabulated. The information that I provide below comes from a website page owned and administered by the United Kingdom's Crown Health and Safety Executive, and I gratefully acknowledge permission to use it, as follows: This blog post contains public sector information published by the Health and Safety Executive and licensed under the Open Government License. The full text of the Open Government License for public sector information can be found here.

So, what are the different kinds of human error?

In the first place, a failure is either:

• Inadvertent (an error)
• Deliberate (a violation)

Errors can be either:

• Action errors (where our action is not as planned)
• Thinking errors (where our action is as planned but we planned the wrong thing)

Action errors can be either:

• Slips (where we do something wrong)
• Example: Flip a switch up instead of down.
• Example: Transpose digits during data entry.
• Lapses (where we fail to do something right)
• Example: Forget to signal before turning at an intersection.
• Example: Skip a step in a safety-critical procedure.

Thinking errors can be either:

• Rule-based mistakes (where we misapply a good rule or else apply a bad rule)
• Example: Misjudge passing the car in front of you, because you would have plenty of room if you were in your own car, but you are in your friend's car which has a lot less power.
• Knowledge-based mistakes (where we have no rules and try to figure it out from scratch)
• Example: Rely on an out-of-date map to plan your route through an unfamiliar town.

Finally, violations can be either:

• Routine (where there is no meaningful enforcement, so everyone ignores the rule)
• Example: A lot of cars on the freeway ignore the posted speed limit.
• Situational (where we cut corners in certain cases, because of features specific to those cases)
• Example: You document your design reviews scrupulously for new designs, but never document them for subsequent Engineering Changes because they always look so obvious you can't see taking the time to write them down.
• Exceptional (where we take a calculated risk in breaking the rules in order to address a highly-unusual situation)
• Example: A huge production order in your factory is due by Friday. On Tuesday, one of your machines comes due for preventive maintenance, but you keep it running (rather than shutting it down the way you are supposed to) because that's the only way to meet the production deadline.

That's the list.

Now what do we do about them?

Notice first of all that an approach which works for one kind of failure really won't help with another kind. Requiring someone to fill out a checklist is very likely to prevent lapses, but it will be completely useless in preventing (say) exceptional violations. A checklist, after all, helps the memory, and in case of a lapse the operator just forgot a step. But in the case of an exceptional violation, the operator knows perfectly well what steps he is choosing to skip — and why — so a reminder (in the form of a checklist) will make no difference at all.

The kinds of steps to consider are things like these.

You can download a useful reminder table, which summarizes all this information and more, from my Downloads Page.