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.