Five laws of administration

It's the last week of the year, so let's end on a light note. Here are five general principles that I've picked up from working in many organizations over the years.

Hard, but easy

1. The more sophisticated a task, the easier it is to get authorization to proceed.

2. The more far-reaching the implications of a proposed policy, the easier it is to get approval.

Easy, but hard

3. The easier a task is to describe, the more time it takes to complete.

4. Procedures that are easy to write, are hard to implement.

Law of purchase requests

5. No Purchase Request can be approved until the cost* of the discussions justifying the decision exceeds the cost of the item to be purchased.

Do you have others? Send me yours.

And to all my readers, have a very Happy New Year!

__________

* (calculated as the sum across all participants of the hours spent in discussion times each participant's hourly rate of pay) 

          

Working yourself out of a job

We sometimes hear that the goal of a certain position is to "work yourself out of a job." If your job is to set up a system, or train people on a new process, or facilitate some kind of sea-change in an organization, the idea is that you will only be successful when they no longer need you: when the "New Normal" has become routine—just regular, old "normal." So long as the organization still needs you, the change isn't complete yet, and the "New Normal" is still new; but this means you haven't done your job. On the other hand once you succeed, there's nothing more to change and you become superfluous. Bye! It's been great working with you!

Is the Quality business like that? Sometimes it feels like there should be something self-limiting about our work. Yes, at a production level someone will always have to do preventive maintenance on the machinery, or calibration of the measuring tools, because these things wear out with use. But how many times to we have to redesign the production system? Once it's up and running, once our widgets are rolling smoothly off the line, do we really have to do it again and again? Or what about the management system? Surely there the case for leaving it alone is even stronger, once we've ironed the wrinkles out. 

Besides, if there's nothing self-limiting about our work, then we run the risk of standards and compliance "eating the world" in Scotlyn's* felicitous phrase—expanding to the point where they drive out value-added production.

Now, I don't support Quality eating the world. (In my discussion with Scotlyn I proposed a "Goldilocks" model for our role.) But neither do I expect us ever to work ourselves out of a job. At the operational level, this is just because randomness means there will always be errors to fix. But at a systems level, this is for two different but related reasons.

One reason is innovation. As long as we sell into competitive markets, competing widget-manufacturers will introduce improvements to steal market share. Then we will have to improve our own widgets—at the very least, by playing catch-up; or, preferably, by leap-frogging their improvements to build something even better. Either way, our production methods will have to change: there will be new materials, new designs, new assembly methods, and the rest.

In time, product innovations will also drive changes to the company organization, and therefore inevitably to the management system. Maybe our early widgets were mechanical, but now we are going to add software: that means we need to hire software engineers, to build a software department, and to implement a software design process. Maybe the latest trend is to advertise widgets on social media: that means we need to hire people who understand social media and keep current with it, resulting in still more changes. And so on. Even if the high-level architecture of our systems remains the same, the details will have to change.

The other reason is that there is no perfect process. Sooner or later, flaws will open up in any process you use; and when they get bad enough, you will have to resolve them. But the improved process you put in place will have flaws of its own. And so on.

You've heard me say this before. But I was discussing it with a friend yesterday, and I actually stopped to ask: "Is that really true? Can we be certain that every process has hidden flaws?"

Of course, she said. Don't be silly. Here, think of it like this: First, the universe is infinite. The Butterfly Effect guarantees that any action—any change, any intervention—will have an infinite chain of consequences. But our minds are finite. So there will always be consequences that we cannot anticipate, and therefore cannot plan or intend. The likelihood that all of those consequences will prove beneficial is vanishingly small. So yes, every time you intervene to make an improvement, that improvement will contain the seeds of new flaws. It might not be worth it to you to address those flaws until later—but they are still there.

So there you have it. Every process has hidden flaws. Every improvement has a shelf-life, after which it will require further intervention and improvement of its own. And those of us who work with Quality systems are not at risk of working ourselves out of a job. 

In other news, today is the Winter Solstice. The calendar year is rapidly winding to a close. For some businesses, this means people have time off to recharge; for others, it means a last-minute flurry of activity to get a few more things done before the New Year. Whichever case describes your situation, I hope the season goes well for you. I'll be here next week, but in the meantime let me wish you a good holiday season and a very happy New Year.

__________

* Scotlyn is a reader with whom I engaged in a four-part discussion over a year ago, on the relative value of Quality standards, compliance, documentation, and certification, compared to actual production. The series started with this post here.      

           

What if there's no contract?

Last week's post, in which I argued that a poorly-designed Quality Management System can actually prevent customer satisfaction, generated some interesting discussions. One of the most productive threads was started by Robert Baron, whose first comment was deceptively simple: "What the Customer 'really' wants is what is in the contract."

But what if there is no contract? This happens a lot in daily life. Go to the corner store for a loaf of bread, send your kids to school, pay your taxes, or connect to a public utility for electricity or water: in any of these cases, typically either there is no formal written contract, or else the "contract" is a fixed boilerplate of terms and conditions that you personally have no power to negotiate. Either way, it's a far cry from the simple model we often use in the Quality business where a Customer and a Supplier interact according to the fixed rules of a negotiated contract. And when we leave that model behind, two questions suddenly arise: What does the Customer want? and Why should the Supplier care?

The answers differ, depending on the details. Who is the Supplier, and what kind of service are they offering? So let's look at two cases: the corner store, and the public utility.

The corner store

Here the answers are pretty easy. What the Customer wants is that the goods for sale be as advertised, and that they meet commonly-accepted criteria of quality. 

• If it's a grocery store, the food should be fresh and free of vermin. 
• If it's an antique store, the articles should truly be antiques, and any flaws or frailties should be disclosed by the seller. 
• If it's a gas station, the pump should dispense what it says on the sign (gasoline or diesel, octane level, leaded or unleaded) and the fuel should be stored at a uniform temperature and pressure so that the customer gets the amount she pays for. 

These criteria are all universally accepted; and for that reason, they are generally backed up by force of law.

It's also easy to see why the Supplier cares: for this kind of store there is typically plenty of competition. If your store gets a reputation for bad quality or poor customer service, it's pretty easy for customers to take their money somewhere else. 

The public utility

When we look at public utilities, nothing is so simple.

What does the Customer want? A public utility provides some kind of good or service that most customers take for granted most of the time. So what the customer really wants, probably, is not to have to think about the good or service at all, but to rely on it implicitly. In other words, what the customer wants is not to have to deal with the public utility in the first place. Clearly it is impossible for any utility to satisfy this want.

Failing that, the customer wants her problem solved, quickly and completely, on her schedule and at her convenience. The utility might or might not be able to do this, but they probably have other customers with other problems that have to be solved at the same time. So the odds are not high that this want can be satisfied either. 

Is this a problem? For those of us who receive the services, yes it can be. But for the utilities, it's not so clear. Last year we discussed the question "Who is the customer for government agencies?" and some of the same ambiguity affects public utilities. In important ways, the people served by utilities aren't even their real customers: the real customers—the ones the utilities have to satisfy—are the regulatory bodies that oversee them, who can approve rate changes or impose penalties for misbehavior. And those of us who receive the services? It's simply not important to the utilities—as organizations*—to make us happy. 

Why should the Supplier care? In the case of a public utility, there's no serious threat of competition. Generally a utility has a guaranteed monopoly on the provision of its service; in very rare cases, it might be possible for someone on the fringe of PG&E territory to switch to SCE instead, but the total numbers are no more than a rounding error. (When I was young, telephone service was subject to the same kind of monopoly; but that's no longer true.) Since a utility's real customers are the regulatory bodies, what matters to the utility is to avoid any hostile interaction with those bodies. And that concern has a kind of trickle-down effect on those of us who receive the services. For while it's true (as I just noted) that it's generally not important to the utilities to make us happy, nonetheless what is important is to make us happy-enough that we don't make trouble with the regulators ... or the legislature. Since most of us are willing to tolerate a certain level of inconvenience in our lives without complaining, that's what we get most of the time. 

In fact, I would guess that this dynamic is at the root of the problem my mother faced in last week's post. 

• It is very likely that the regulatory body overseeing her Electric Company requires them to have a QMS with calculable metrics. 
• It is even plausible that the regulatory body requires them to report their metrics regularly, which would explain why it is so important for those metrics to be always green. 
• But it is also likely that this requirement was imposed with no input from the public—or, more exactly, with no input from any member of the public who understands QMSes. 😀 

So there was no one in the room to insist on a loop in the procedure that checks back with the customer before closing a trouble ticket, and the point was simply overlooked. You could call it "human error."

Note that this line of thought, if true, also tells us how to improve the situation. Find the regulatory body responsible for overseeing the Electric Company, and register a complaint with them. But remember that the regulatory body is another very large organization; so getting them to respond in a helpful way might be almost as difficult as getting a helpful response from the Electric Company.

This sounds like a depressing conclusion, but I don't think it has to be. What it shows us is that the system-level analysis of an organization's management system works: it is a tool that gives meaningful results. If it shows us that some problems are harder to solve than others, at least we know what's involved. 

As for Quality, our results are a lot like when we examined Quality in government: it's the same but different. The basic Quality principles apply robustly even when there is no negotiated contract spelling out all the terms explicitly. But of course the details depend on the individual case.

__________

* To be very clear, I'm not saying a word against the human beings who work for the utilities! I am certain that, like in any organization, most of them are hard-working and care about doing their jobs as well as they possibly can. But the system they work inside-of has goals of its own, based on what the organization needs. And that's what I am talking about here.    

          

What does your customer really want?

The idea of Quality is based on customer satisfaction. But sometimes the systems that we set up to satisfy our customers end up getting in the way. It's scary to think that your QMS might end up decreasing customer satisfaction, but when organizations get large and complex these things can happen.

My mother's yard wasn't nearly this bad!
But she still wanted to be careful.

For example, sometime last year the Electric Company in my mother's area had to do some work on the lines in the neighborhood; and after they were done, she found a line down at one end of her backyard. Of course my Mom wasn't about to touch a downed power line, so she called the company to report it. 

They scheduled a day for someone to come take care of the problem and asked her to stay home all that day, so she would be there when the technician arrived. My Mom made arrangements to spend the day at home ... and the service technician never showed up. 

This happened several times.

But each time, they had given her a Work Order number. So finally when she called them back she asked, "What's the status of Work Order #1234567?" 

The agent looked it up and told her, "That was closed in our system the next day."

"Can you tell me how it was closed? Because no technician ever came out here."

"Let me check. Hmm ... according to our records we forwarded the call to a contracting company that handles service work for us. And as soon as we transferred the call to them we closed it in our system so it wouldn't be double-tracked."

"How can I talk to the contracting company?"

"Hmm. I don't know if I have a number you can call...."

In the end, she never spoke to the contracting company. Before she had time to follow it up, the Phone Company had come out on a totally unrelated issue. When he was done with his work, the telephone technician told her, "By the way, ma'am, I found there was a downed line in your backyard. That was a telephone cable related to a service you don't have anymore, so I just cut it off so it won't be in your way." And—just like that—her problem was resolved.

Why could the Electric Company never resolve it? One answer is that the downed line wasn't an electric line, but there's more to it than that. Another fundamental issue is that their Service department was clearly organized around closing out trouble tickets rather than around solving customer problems. When my Mom told me about her conversation with the Service department, I could see right away how someone could have set up this system: 

Let's see .... We need a procedure to take calls, to record calls, to assign calls, and to track calls. Then we can measure the efficiency of the department by calculating how fast calls get closed out. If all calls are closed fast enough, our metrics will turn green and we will be doing a good job. Hooray!

It all looks very logical until you put it in practice and realize that the cycle doesn't include a step to check with customers whether their problems have actually been addressed. Also there seem to be no fail-safes to protect against information getting lost when tasks are passed from one actor to another (in this case, from the Service department to the contractor doing the work).

This is why you have to ask yourself, every step of the way, "What does my customer really want?" It's not easy. In complex organizations, it is only natural to fall back on trusting the systems and the metrics. But systems can fail, and metrics can lead you astray. 

Don't let them. Remember your customer.

          

"But it's such a small change!"

Now that ISO TC 176 has formally announced the decision to start work on a revision of ISO 9001 (see this announcement from 3 August 2023), this may be a good time to revisit the question what constitutes a big change rather than a small one. What's interesting is that often you can't tell from the outside how big an impact a change is going to have.

The question matters because every change introduces churn and disruption. When a global standard like ISO 9001 introduces new requirements or changes old ones, organizations across the world have to stop what they are doing, evaluate the change to see what it means for them, and then make the appropriate changes in their own operations; that last step includes planning the changes (clause 6.3), updating the relevant documented information (clause 7.5.3.2c), introducing the changes in a controlled way (clause 8.5.6), auditing them for effectiveness (clause 9.2.2a) and reviewing the results (clause 9.3.2b). 

Is the serving large or small? Depending on your context (in this case,
the size of the plate) the same serving can look very different!

It's never easy. So it's always a relief when the changes turn out to be small and not big. But what makes for a big change?

It turns out that the answer depends very narrowly on the specific organization's current Quality Management System. Changes that are trivial for one organization might be huge for another.

This point was driven home to me back when the 2008 edition of the standard was being rolled out. At that time I worked for a regional office of a mid-sized global company. My office had started as an independent company of its own, and we still handled many of our operations the way we always had in the past (rather than integrating fully into all of our parent's systems). It made our QMS a little complicated 😀, but in practice it worked fine.

When ISO 9001 rolled from the 2000 edition to the 2008 edition, I looked through the changes. Mostly they looked superficial—minor changes to wording or sentence structure that made the text less ambiguous or more readable. 

• Passive verbs were replaced by active verbs. 
• The phrase "regulatory requirements" was replaced by "statutory or regulatory requirements." 
• Instead of being told to "identify" the processes in its QMS, the organization was told to "determine" them. 

This was the kind of change that I found throughout the document. And when I discussed the changes with our certification auditor (who was always very collegial when he was off-duty), he agreed completely. Neither of us found anything in the document to worry about.

Meanwhile the Home Office reacted to these same changes with panic. During Quality department staff meetings, I kept hearing that the updates in the 2008 edition were momentous, that they could require us to change everything. I didn't like to tell my colleagues they were wrong, but for some time I had no idea what worried them so.

Turns out they were worried over one provision. At one point, seemingly as an afterthought, the authors of the 2008 edition shed light on a requirement that had been more or less implicit before but never spelled out in words: in a clarification of clause 4.1 ("General requirements") the new edition now stated:

NOTE 3: Ensuring control over outsourced processes does not absolve the organization of the responsibility of conformity to all customer, statutory and regulatory requirements.

Why did this alarm the Home Office? I learned that they regularly outsourced certain processes that they did not have the capability to perform themselves, and the contracts with their suppliers made the suppliers responsible for all conformity issues involved. In other words, the Home Office had no systems in place to allow them to accept or exercise this level of responsibility; and the new edition of the standard meant they had to build those systems from scratch in a hurry. 

Our office, by contrast, had always taken that responsibility for granted, even when it wasn't explicitly stated. (You remember I said that many of our operations were left over from when we had been independent.) So for us, locally, this Note required literally no change at all to anything we were doing. And I'm pretty sure (from talking to other people later) that the authors of the standard thought the Note was no more than a restatement of something that had been implied all along.

You never can tell what changes are going to look big until you check the individual cases one at a time. It's remarkable, really.      

           

"Does ISO 9001 really require THAT?"

Everyone who works with ISO 9001 has run into That Person—the one who is convinced that the standard requires something crazy. Maybe it's the person who insists you have to document your paper clip usage ... or the one who tells you that auditors can write findings based on their judgement or opinions, or on a hunch that you might be doing something they personally don't like. Maybe it's The Stupid Label Guy. (See also this post here.) Sometimes, regrettably, it can even be your auditor, so that you have to have a long conversation during the Closing Meeting about why this or that topic really has no place in the report.

Arguing with these people can be exhausting. And sometimes it leaves you wondering, "Am I the crazy one?" When the plain sense of the words obviously means one thing to you, but That Person is totally convinced that it means something else instead, it's natural to wonder if maybe you are confused. Is there anywhere you can go to get an answer? Can anyone provide a clear, unambiguous, authoritative ruling on what the standard really means?

Yes, someone can. For myself, I spent way too many years in this business before I found out about them. So let me save you a little time, I hope, by telling you about them now.  

The authorities in question are a subgroup of the ISO Technical Committee 176, the committee responsible for writing ISO 9001. Their formal designation is ISO/TC 176/SC 2/TG 04, or ISO Technical Committee 176, Subcommittee 2, Task Group 4. And their whole job is to give authoritative answers to questions about what the standard requires.

Note the limitations. They are not there to give advice on how you might best implement the requirements of the standard. They won't analyze your business's special circumstances to suggest what you in particular will find efficient or useful. That's consulting, and there are lots of people willing to do it for a fee. But if you have a straightforward, Yes/No question—something like, "Does ISO 9001 require us to hang a printed copy of our Quality Policy in the lobby, signed by the CEO?"—TG 04 can give you a clear Yes or No that settles what the standard actually means.

There are a few other restrictions. To keep the volume of requests manageable, TG 04 replies only to member bodies—that is, national standards organizations who are themselves members of TC 176. If you or I, as private individuals, have questions of interpretation, our first stop should be our national standards organization. (Since I'm American, for me that means ANSI.) All questions must be phrased so that they can be answered Yes or No. And the website warns questioners not to expect an immediate reply: "As it is an official process, that involves developing consensus among the members of ISO/TC 176/SC 2 to agree on any proposed interpretation, a quick response cannot be expected." You can find a list of detailed guidelines at this link here. 

Still, it's nice to know that this group exists. When That Person tries to tie you in knots by insisting on something crazy because they think "ISO 9001 requires it," it's nice to know there's somewhere to turn to get a clear answer.

And it's especially nice to know you don't have to put a label on your coffee maker. 😀  

          

Life as a conductor

Last week I talked about the role Quality personnel have in an organization, even though they are not directly engaged in production or sales. And it put me in mind of a comparison that Rose Duncan made some weeks ago. (I've quoted Rose before, briefly in this post here.) Rose's image was simple and memorable, and it would have delighted me even more back when I was five years old and loved trains. 😀

She wrote:

Your quality management system / QSE is like a train.

You need an engine and carriages.

You can attach as many as you want: beautiful ones, compliant ones, expensive ones, simple ones, complex ones, unique ones, a few, or a lot...

But let's be clear:

The engine is the leadership.

Their job is to pull the train.

You [in Quality] are the conductor.

Her post went on from there, and mostly it was about leadership. Her main point was that without leadership, the organization goes nowhere.

But I was struck by the idea of Quality as the conductor. What I commented at the time was:

The conductor doesn't personally load the coal (or diesel). The conductor doesn't hop down into the yard to hook up the cars manually. The conductor doesn't choose what speed to go around a tight curve. The conductor doesn't personally do ANY of those things! But you've got to have a conductor.

But then I went to look up, What exactly does a conductor really do? According to Wikipedia, the tasks of a conductor include:

• Ensuring that the train follows applicable safety rules and practices
• Making sure that the train stays on schedule starting from the stations
• Opening and closing power operated doors
• Selling and checking tickets, and other customer service duties
• Ensuring that any cars and cargo are picked up and dropped off properly
• Completing en-route paperwork
• Directing the train's movement while operating in reverse
• Coupling or uncoupling cars
• Assisting with the setting out or picking up of rolling stock

And seriously? That doesn't look like a bad match, mutatis mutandis. Let's look at it again, more slowly.

• Ensuring that the train follows applicable safety rules and practices Quality regularly has to check that the organization is following all applicable regulations, including legal and contractual ones. Some of these checks might be carried out by a Facilities Department or a Safety Committee. And yes, strictly speaking legal or safety regulations might be out of scope for the QMS, depending on how it has been defined. But Quality has a clear interest in the topic of regulations in general.
• Making sure that the train stays on schedule starting from the stations Again, schedule maintenance might be most immediately managed by Project Management or Production Management. But if the organization regularly fails to meet its committed delivery dates, there's going to be a long talk during internal audits about why.
• Opening and closing power operated doors Remember that this is an analogy. If the train represents your system, then the doors are points in your process that accept inputs or release outputs. Presumably you have requirements that your inputs and outputs have to meet. Quality safeguards that those requirements are met, and therefore functions as a "doorkeeper."
• Selling and checking tickets, and other customer service duties Tickets are how you make sure that "passengers" (which Rose later identifies with your employees) are in the right places (roles / functions) at the right times. Quality checks that training requirements have been met, and that resources are adequate.
• Ensuring that any cars and cargo are picked up and dropped off properly This is again related to inputs and outputs, as above.
• Completing en-route paperwork Everyone knows we are all about paperwork. 😀 (Not solely, of course. But it is inevitably part of the picture.)
• Directing the train's movement while operating in reverse Under certain exceptional circumstances, when something tricky is being done, it is not unheard-of for Quality to be given—temporarily!—some kind of operational role for the duration of the special circumstance.
• Coupling or uncoupling cars ... and ...
• Assisting with the setting out or picking up of rolling stock I ran out of inspiration for these last two. No analogy is perfect.

So there you are. It's a fine analogy to explain to five-year-olds everywhere what a Quality professional does all day. We're conductors. And every train needs a conductor.

           

Is Quality really free?

A few weeks ago I was having lunch with a friend, and we were talking about work. She works for a small company struggling with growth, and when she started there her charter included implementing a Quality Management System. But there were always daily fires to put out first, and at this point she said she has shelved that project for the time. There are a lot more immediate things that have to be done first. Finally she sighed and said, "We just can't afford Quality right now."

This took me aback, just a little. Ever since Philip Crosby, we have all told each other that "Quality is Free." But how can that be? In fact, this slogan turns on the dual meaning of the word quality. On the one hand, quality just means doing things well. On the other hand, Quality [often with a capital Q] refers to a whole body of formal practices that organizations implement—a professional body of knowledge, with its own professional organizations and certifications. As I have said many times before (including as recently as last week), these two meanings are not the same.

Quality should be free, at the most basic level, because in a perfect world (where everyone always knows what to do) it should cost no more to do a job right than to do it wrong. In a more sophisticated sense, Quality is "free" because—even if it does cost a little bit more to do it right—you make that money back by avoiding the cost of rework or of replacing failures under warranty. This second line of thought is what justifies the cost spent on a formal QMS: yes, filling out the forms and following the procedures takes time (and time is money); and yes, you are paying inspectors and auditors who are not themselves engaged in production or sales. But without these forms and procedures and inspectors and auditors, your rework and warranty costs will eat you alive; so in the long run you are money ahead by having them.

"In the long run." That's the key. Or as one of my coworkers put it many years ago, "Therein lies the rub, bub." You have to have some time and money to spare first, before you can put the systems in place that will ultimately generate any savings.

Think of a paved road, as an analogy. Paved roads are a very basic—and very useful—piece of infrastructure. They enable the movement of human beings, the transportation of goods, and the delivery of services. Modern economies would be unthinkable without paved roads. For the economy as a whole, the net return on investment—the surplus of economic activity that they enable minus the cost of building and repairing them—is incalculably huge.

But paved roads don't grow on trees. For each paved road you see anywhere, someone had to decide where it was going to go; someone had to grade the land; someone had to lay out the road; and (only at the end of a long process) someone had to pave it. All of that required human effort, all of it took time, and all of it cost money. In an economy with no way to generate a surplus, no one can afford to pave a road.

And I think this is where my friend is, right now. There are just too many things that have to be done first, before a QMS will even be a meaningful concept. Maybe sometime in the next year she can move the inventory system out of Excel. Maybe she can regularize the purchasing activity. One thing at a time. And then in a while, when the company can afford it, she can go back to implementing a QMS.

Does that mean the company is doing a bad job in the meantime? Heavens, no! The company's day-to-day work is just fine, because the people who work there have mostly been there a long time and "just know" how to do it right. The overall level of competence across the team is very high. So yes, they are doing a good job today. The only problem is that their current methods aren't scalable, precisely because they depend on such a high level of competence. So if the company wants to grow, they are going to have to put systems in place. They are going to have to rely more on procedures and less on "just knowing." They are going to need a QMS.

Maybe next year.    

          

Focus and Quality

Back in January, I wrote that "the deepest source or spring of Quality is love: love for the work or love for the product." But it's not that love is some kind of cartoonish magic power that conquers all effortlessly. Rather, the point was that when you love something—the work or the product—you look deeply at it. And that deep looking is essential for doing a good job.

We all know this in reverse. Nobody can expect to do a good job while constantly distracted. This is why some people resent mobile phones so badly, or social media. It's why some executives declare that they will only open their email during certain hours and not the rest of the time. Matthew McConaughey makes the same point in a video attached to this LinkedIn post from about a month ago.

To be sure, your focus has to be on the work at hand. What you focus on is what you get good at. If you will forgive another LinkedIn reference, this post from last year makes the point that when you do a lot of any kind of work, usually you get better at it. You figure out what to do and what not to do. This is why experienced professionals generally turn out better work than dilettantes or amateurs. We read about exceptions from time to time: everyone has heard that Mozart began composing music when he was four or five years old. But the only reason we read about them is that they are exceptions.

But where in all of this do the familiar Quality tools show up? We all know that the implementation of a Quality Management System means the imposition of uniform procedures: but how do procedures and auditing generate a deep focus on the work?

The short answer is: they don't. No gimmick can make you care about your work. No procedure can make you brilliant or successful.

But the longer answer is: they help. In particular, they can help you focus.

A product design procedure won't guarantee that you design your product well. You need good design skills for that. But it should ensure that you have all the information up front about what you are supposed to be building: is it a fighter jet, a sound system, or a birdhouse? And if you know the requirements up front, you are less likely to be distracted by someone running in from the Marketing Department saying, "Oh, just one more thing ...!" (See also the cartoon at the bottom of this post. I once worked on a large project where nearly every single engineer had a copy of this cartoon over his desk. And yes, there was a reason.)

When something goes wrong in one of your products, a problem-solving tool can't guarantee that you will find it. But each problem-solving tool in the Quality arsenal helps reduce the number of possibilities so that you don't get distracted by irrelevancies:

• A fishbone diagram spurs you to broaden your thinking, so that you consider all possible causes and not just the first one that jumps to mind. 
• An IS / IS-NOT table helps you eliminate the ones that cannot be relevant.
• A Pareto chart points you to the specific areas of investigation that are likely to be most fruitful. 
• Even the overall 8-D structure of a problem-solving effort focuses your work in a way that has been compared to the scientific method.

So no, none of these tools can make you care. None of them can force you to do a good job. But with luck, if applied correctly, they can turn down the ambient noise so you can get back to work in peace and quiet.

              

ISO haunted house

Next Tuesday is Hallowe'en. 

So in honor of the holiday, here's a quick glimpse into the ISO/ANSI office Hallowe'en party. If you dare ....

All thanks and credit go to Randall Munroe, the creator of xkcd. You can find the original of this comic online here.

           

An overlooked Quality skill

Let me continue my line of thought from last week by asking, What skills do you need in your Quality department? Of course there are a whole list of Quality methods that you have to command to be at all effective: auditing, problem-solving, and documentation are high on that list, for example. Depending on the kind of work you do, you may need experts in inspection, or metrology, or statistical process control. And certainly I have argued before in this blog that you need to understand how your system as a whole holds together.

But there's another skill that is often overlooked. Let me tell you another story.

Years ago, I was responsible for the Quality system in a couple different locations, and had to report back to the Home Office. Now the company sat in the high-tech space, and most of the Quality personnel at the Home Office had a scientific or technical or engineering education. It was a point of pride for our whole department to be able to meet the company's engineers on their own ground when tracking down an elusive product defect.

But in one office that I was responsible for, the local Quality representative was a woman I'll call Lee Ann [not her real name] whose background was non-technical. She had a perfectly good grasp of 5-Why methodology, and was a reliable and systematic auditor. But she wasn't an engineer manquée, and never pretended to be. This caused some grumbling back in the Head Office. I even heard people mutter questions like When was I going to get rid of her and replace her with somebody more technical?

In fact there was no way I would have ever traded Lee Ann for someone more technical. I didn't need someone technical in that office. Yes, there was a small engineering presence there; but they were all solid, competent engineers. When product problems surfaced (rarely) they had all the expertise they needed to figure out what was wrong. But most of the personnel in that office were in Service or—especially—Sales. In many companies, Sales acts like The Department That ISO Forgot: yes, ISO 9001 has always had a requirement for Contract Review, but other than that the attitude (all too often) is close to, "Procedures? We don't need no stinking procedures."

So what I needed in that office was someone who could connect with the people in Sales and Service, to make them understand why the Quality system applied to them and to make them feel invested in it. And Lee Ann was a master of relationship-building! One by one she sat down with these people and talked with them informally. She found out what they did, and related their work in a simple way to the Quality requirements that applied to them.  Without making a fuss, she trained them on the system and its rules, in such a way that they were invariably grateful. She made it look easy enough that I'm still to this day not entirely sure how she did it. But she was a marvel, and her special talent was just what that office needed.

My general point is just that we in Quality can't achieve anything without the willing cooperation of all the other functions in the organization. For that reason, relationship-building has to be an essential part of the Quality toolkit.

   

          

"You're having dinner with me!"

A couple of months ago, Rose Duncan posted a list of "10 Tips for Starting in the QHSE Function." It's a good list; by all means check it out. What particularly impressed me is that, besides the business-oriented topics ("Identify key issues," "Align with the organization," and so forth), Rose prioritized some fundamental, relationship-building goals. "Build relationships with everyone" "Ask questions and learn." "Get to know the stakeholders and their perceptions." These topics are easy to overlook for Young Professionals in a Hurry. But they can spell the difference between reasonable success and abject failure.

Years ago I learned this point in the most unforgettable way. Let me set the stage: I was working for an American company that had recently been acquired by a large European one. The Acquiring Company had two American offices (us and one other); we were in different states, and didn't interact much. But my boss—who had been sent out from the Home Office in Europe—was responsible for the Quality function in both. He stayed on the job until both offices got our initial ISO 9001 certifications, and then accepted a promotion into a totally new role. I was selected to take his place, managing the Quality function in both offices. So shortly after my promotion, I took a trip to visit the other office for the first time—just to meet people and let them get to know me.

When I got there, my reception was ... polite but very subdued. Nobody said much, and at first I was left alone a lot. After I asked around, people slowly began to explain that my former boss had made a lot of enemies during the 12 months that he had been driving the ISO 9001 program. Time and again he had gotten into arguments with the people responsible for one function or another, insisting that things had to be done this way and not that way. When anyone tried to push back that they'd been doing it successfully the other way for years, he was implacable: they had to do things a certain way in order to get ISO certification, and ISO certification was a corporate directive, so they could just go argue with the Company President back in the Home Office if they didn't like it!

That was the act I had to follow. No wonder nobody wanted to talk to me.

Then one afternoon a woman came striding up to me and introduced herself as the Customer Service Manager. "Are you the new Quality Manager? The one replacing ——?"

"Yes, I am."

"You're having dinner with me!" It was not a request.

Then she explained that my predecessor had left such a bad impression that she figured the only way she and I could ever work together is if we started off with something pleasant like a nice dinner. Also she was something of a wine specialist, and she knew just the place.

It was a lovely dinner. We talked about a lot of things outside of work. We even began—slowly, gingerly—to talk about work itself. I explained my approach to Quality management: that it has to be pragmatic; that no company ever earned a dime by following a documented process; that Quality just means getting what you want; and that all the formal techniques in the world are just gimmicks to help get you there. I may even have shared some of my thoughts about whether ISO 9001 compliance is really worth it. (This was a long time ago, so I don't remember if I got that far.) 

By the end of the meal we were on the same side. And in the long run I was able to work with that office very successfully for many years.

I'm not sure that many Quality departments would be willing to expense candlelit dinners with good wine in the name of stakeholder engagement.* But one way or another it is critical to meet your stakeholders where they are, and to let them see that you are all on the same side.

__________

* Actually, even though I was the one on travel at that point, she insisted on covering the meal. She argued, just as I remarked above, that the Quality department probably wouldn't cover it. I wasn't sure I understood: "You mean Customer Service will?" She smiled. "Before I was in Customer Service I worked in Sales. I've learned everything there is to know about how to get expense reports through the system." 😀

          

Problem-solving with Marcus Aurelius

There are a lot of special tools that we use in the Quality business to analyze problems and identify causes, but it can be helpful to remember that the core idea is a very old one. It is simply that we can learn from our mistakes if we approach them with calm and curiosity rather than with hatred, anger, or scorn.

In a delightful synchronicity, last week (while I was posting about 5-Why problem-solving) Ryan Holiday of the Daily Stoic posted on this exact topic under the heading, "You Should Ask Yourself This Question When You Mess Up." He wrote, in part: 

Look, we all mess up. We take certain people or clients for granted and a relationship deteriorates. We get distracted and make an unnecessary mistake. We are overwhelmed by a passion or a temper and do something bad.

We’re humans. It happens.

What follows are consequences. The client leaves us. The mistake costs money to repair. An apology turns out to be insufficient.

And what follows consequences is often regret, and sometimes shame. Or, if we are less self-aware, anger and blame.... 

This sort of self-flagellation is not what Stoicism is about. It’s backward looking–the worst, most purposeless kind of personal evaluation. Instead, when we mess up, and when we come face to face with the consequences of our actions, we must ask: What can I learn from this?

Literally, we can ask that to the client who is leaving us (What can I do better next time? What warning signs did I miss?). We can look at our habits and study where we got distracted and made that boneheaded mistake.... 

One way to look at Marcus Aurelius’s Meditations is that it is ... admonishments to himself after messing up. He was cruel to someone, and so the next morning he wrote about controlling his anger. He’d been wasting time recently, and so he wrote about the shortness of life.... 

It’s inevitable that you will do wrong. You may even mess something up five minutes after reading this email. What matters... is not the mistakes .... [but] what lessons emerge from the missteps, and how we improve because of them.

I read this and thought, Isn't this just what we've been talking about here, all along?

• "Look, we all mess up." ("'Human error' is not a real root cause [because it's not actionable]. We'll never get rid of 'human error' any more than we can live on a planet without oxygen.") 
• "What follows are consequences." ("The whole difference between success and failure came down to meeting minutes. For want of a nail, a kingdom was lost.")
• "When we mess up ... we must ask: What can I learn from this?" ("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.")
• "What matters... is not the mistakes .... [but] how we improve because of them." ("Lying to your auditor is like disabling your fire alarm: sure, the noise won't interrupt you, but wouldn't you rather know if there were a fire?")  

And so on. These examples were the first ones I found, almost at random; I'm pretty sure it wouldn't take long to find others that work just as well or better.

Knowing that the Quality point of view was anticipated by the Stoics two thousand years ago doesn't make it any easier in the moment. When we send a whole shipment of tools to Amsterdam and they all fail out of the box, we still have to put in the hard work to figure out what went wrong. But it can be reassuring to know that someone else has been down this road before. And when we learn that even Marcus Aurelius had trouble holding his temper in a crisis, oddly enough that may help us hold ours.   

             

"Difference between night and day": Adventures in root-cause analysis

Last week we talked about a specific problem-solving discipline. Here's another case of problem-solving, involving an elegant example of root-cause analysis. 

A while ago I stumbled across a video that gives a perfect example of good, pragmatic root-cause analysis. The National Parks Service found that the stone of the Jefferson Memorial in Washington, D.C., was deteriorating. The analysis of what was causing the problem turned out to be a classic example of 5-Why methodology. The video is less than two minutes long:

Note that this is a perfect example of how 5-Why is supposed to work: you keep asking "Why?" until you get to a point where you can find a pragmatic solution ... and where you can't go any farther without giving up on pragmatism altogether.

• Trying to stop the birds without stopping the spiders would have been hopeless.
• Trying to stop the spiders without stopping the midges would have been hopeless.
• On the other hand, nobody asked "Why do midges come out at dusk?" That's just a fact, and there's nothing we can do about it. (I've said before that if you start asking "Why?" about fundamental facts of nature, you've gone too far. Real root causes must be actionable.)

In that whole chain of causality, there was one sweet spot, flanked by impossibilities on both sides. That's where the solution lay.  

Not all root-cause analyses are this elegant, but this is certainly the goal to aspire to.

           

Problem-solving with the Toyota Kata

A couple evenings ago, I attended a talk by Leigh Ann Schildmeier on the Toyota Kata process. Schildmeier is an engaging speaker; her material was interesting, and her presentation was disarmingly relaxed. All the same, she covered far more territory than I can address here. But I'd like to gesture towards the basics. If you want to know more, by all means contact her or check out one of her websites: Park Avenue Solutions or Starter Kata.

In a sense, Kata is a problem-solving methodology; like a number of others, it can be characterized as "the scientific method applied to business." What is distinctive, though, is that Kata (when properly applied) is a kind of discipline that permeates a company's decision-making. It's not just one more tool that sits on the shelf until you pull it down for a crisis. This distinction becomes clear when you look at the root meaning of the word: the term kata comes from martial arts, and it means "a detailed choreographed pattern ... made to be practised alone."* In the same way, the Toyota Kata is a pattern of thought and action that lets you pick your way through unknown territory; and ideally it should be so routine that you use it reflexively—on production problems, on management problems, or on finding your way in a new city when your GPS is broken. (Schildmeier says she has used Kata to improve her golf game.)

As an aside: Before I go too far, I should clarify that Schildmeier did not invent this system, though she teaches it, coaches it, and consults on it. The system was invented by Toyota (hence the name), and it was first publicized in the United States by Mike Rother in a 2009 book called Toyota Kata. 

There are four basic steps to the Kata process, and in the abstract they sound very simple. 

1. Understand the overall challenge you face.
2. Grasp where you are right now.
3. Set a target for your next step towards the challenge.
4. Run experiments on how to get there.

To illustrate what these mean, Schildmeier asked us to think of a football** game.

1. The overall challenge is to win the game.
2. "Where you are right now" might be, let's say, the 50-yard line. But it also includes understanding the weather, the status of the game so far, your own current condition and that of the other team. There might be other relevant factors, as well.
3. Your next "target condition" is where you want to get to next, in the service of the final goal. But it has to be concrete and achievable. In a football game, that might be to advance the ball ten yards. (In business, Schildmeier says your next "target condition" should be something you can achieve in no more than two weeks.)
4. And then you run experiments on how to get there. Wait, what? Yes, says Schildmeier, that's exactly what a team does. They have already been running plays hour after hour in practice, for weeks before the game ever started. But they don't know until they actually get on the field which of those plays is going to work. They have to observe the concrete conditions on the field and the behavior of the players on the other team in order to get an idea which plays are likely to succeed and which ones are doomed to fail. And then, based on that empirical input, the quarterback calls the play and the team carries out what is—in effect—an experiment. Whether it works or fails, either result constitutes additional information which the team (especially the quarterback, of course) uses to decide which plays to call next time.  

Simple, right? 😀 Of course, conceptually it is simple. As for practice, ... well, anything can look simple if you've spent ten thousand hours perfecting it. But that's exactly why Kata is supposed to be a discipline and not just a tool. Besides, it's not like problems are so rare that they only show up once a year. Maybe the big ones are rare (though not rare enough, I might add!). But smaller problems show up all the time. If you can perfect an approach that handles problems of any size, you prepare for addressing the big ones by solving small ones routinely.

Naturally there is more. There is a whole body of practice and coaching to help your organization get from here to there—to help you get to the point where you can use Kata reflexively and routinely. Check out Rother's book, ... or give Schildmeier a call. She might be willing to talk to you about your golf game, as well.  

__________

* Wikipedia, "Kata," retrieved 2023-09-20.

** I mean American football in this context.     

              

Oops, my bad—tools CAN'T always calibrate each other!

I goofed last week. I said you can have two tools calibrate each other, and I didn't put any restrictions around that. I was wrong.

You remember the whole topic was whether two tools can calibrate each other. The question I asked was this: "Suppose you calibrate some of your own tools in-house, instead of sending them out. And suppose that when you calibrate Tool-1, you use Tool-2. Normally there's nothing wrong with that, so long as Tool-2 itself is also correctly calibrated. But back when you calibrated Tool-2, you did it using Tool-1. Is that a problem?"

I argued that you can do this, within the parameters of quality system standards like ISO 9001 and ISO 17025. And right away I got helpful feedback from commenters on LinkedIn telling me, "Not so fast!"

Christopher Paris pointed out a technical issue I had forgotten. When I described the calibration history of Tool-1 and Tool-2, I traced them both back to the day you bought them from the manufacturer. I assumed you got a certification from the manufacturer at that point. But Chris observed "that the original calibration certificate from the manufacturer is rarely traceable to national/international standards. It's typically some basic certificate that doesn't really provide much information. So tracking back to that doesn't get you full compliance to ISO 9001. If the OEM's cert doesn't list traceable standards used to calibrate the device, then the device still has to be subject to a third-party lab or some other traceable calibration."

So yes, I accept that correction. Tool-1 and Tool-2 both have to be calibrated at the beginning in a way that is traceable to the correct international standards.

But what about the part where you then use the tools to support each other? What about the way that they leapfrog one another on and on into the future forever?

Scott Kruger and John Schultz each flagged this as an improper use case, and we had some helpful discussions about pragmatic topics to clarify why. But I wanted chapter-and-verse. If this is a bad practice, it should be forbidden by the relevant standards—either that, or there's a hole in the standards and someone is going to exploit it.

I finally found it, but I had to dig. ISO 17025, clause 6.5.1, states: "The laboratory shall establish and maintain metrological traceability of its measurement results by means of a documented unbroken chain of calibrations, each contributing to the measurement uncertainty, linking them to an appropriate reference." [Emphasis mine.]

Let's apply this to my thought experiment in last week's post. Here's what I wrote then.

Remember that when you calibrate any tool, that measurement typically has a validity period. Maybe it's valid for one year. So let's say you calibrate Tool-1 every January, and that calibration is good from January to December. Then you calibrate Tool-2 every July, and that calibration is good from July to June.

Last month was July 2023. Time to calibrate Tool-2.

So you pull out Tool-1. Is it a valid tool to use? Check the sticker. It was calibrated in January 2023, and is good through December 2023. So it must be good to use.

But wait. Let's check the paperwork to make sure. According to the paperwork, when we calibrated it in January 2023 we used Tool-2. Hold on! Isn't that the same tool we're trying to check right now?

No. It's not.

The tool we are trying to check "right now" (meaning last month, when I've set this story) is "Tool-2-as-of-July-2023." The tool we used last winter back when we were calibrating Tool-1 was "Tool-2-as-of-January-2023." If you look at it right those should count as different tools,....

Stop right there.

What I should have seen is that as soon as I treat "Tool-2-as-of-July-2023" and "Tool-2-as-of-January-2023" as different tools, I've got a problem. What does Tool-2's unbroken chain of calibrations look like?

July 2023: Tool-2-as-of-July-2023 was calibrated by Tool-1-as-of-January-2023.

January 2023: Tool-1-as-of-January-2023 was calibrated by Tool-2-as-of-July-2022.

July 2022: Tool-2-as-of-July-2022 was calibrated by Tool-1-as-of-January-2022.

January 2022: Tool-1-as-of-January-2022 was calibrated by Tool-2-as-of-July-2021.

And so on.

Every single one of those measurements introduced an uncertainty. Maybe it was small, but it was there.

Just to make things simple, let's pretend the additional uncertainty is the same each time. (In real life, it might not be.) Call that uncertainty ε. [That's a Greek epsilon.] Then every year that you play this leapfrog game, the uncertainty for each tool increases by 2ε (adding one in January and one in July). If you've been using Tool-1 and Tool-2 to calibrate each other for ten years, you have added 20ε to the uncertainty of each one. 

When does that accumulated uncertainty become too much? At what point does it make the tool worthless?

It all depends what you normally use your tools for. How small an uncertainty do you need? Maybe if the tools start off a lot better than you actually need, you can get away with it for a while. But you must need some level of precision and accuracy, or you wouldn't bother calibrating your tools at all. And you probably didn't spend the extra money to get tools that were 100x more precise and accurate than you really needed. So you can't really play this game too long. Certainly not forever.

As I say, I goofed. I was wrong, and I'm grateful for the corrections. Thank you, all.