What is Relationship management?

Relationship management is the last of the seven Quality Management Principles, but in a sense it brings us back to the first one—Customer focus. In the broadest sense, relationship management is about taking care in your interactions with all of the interested parties that affect your work, and your customers are clearly on that list. So you could almost say that customer focus is just a part of relationship management. 

In reality we treat customers separately because they are a very special kind of interested party, and because they have some very special needs not shared by the others. Also—speaking historically—the whole concept of Quality grew out of a concern for customer satisfaction. It is the existence of customers that gives us the concept of Quality in the first place, and so it is not unreasonable for customers to have one Principle all to themselves. 

But in the long run we do well to nurture relationships with all our interested parties (or all the relevant ones); and this principle reminds us to do just that.   

Why bother?

Remember who your interested parties are. ISO 9000:2015 explains that:

The relevant interested parties are those that provide significant risk to organizational sustainability if their needs and expectations are not met. [2.2.4, para. 2]

In other words, these are the people who can ruin things for you. It pays to stay on their good side.

More exactly, you want to encourage them to act in a way that helps you and does not thwart you. But why should they do that? What's in it for them? It is up to you to find a way to appeal to them, so that they see helping you (or at any rate not thwarting you) as in their own best interest. If you can think along these lines consistently—that's relationship management! The rest is just details. 

Who is involved?

Anyone who wants something from you. That could include your landlord, your neighbors, and the state revenue office. Mostly you exclude customers, because (as noted above) they are already handled elsewhere. And you want to focus on the ones that pose the biggest risk. For most companies, most of the time, this means your suppliers.

But it might include others as well. Even your competitors can be considered interested parties. That's what trade associations are about, after all: they are venues where competitors can meet to cooperate on common issues, like encouraging a general market for their products. (Someone once quipped, "You have to sell coffee before you can sell Folgers.") 

Informally, you probably already know which interested parties matter to your business. Formally, you'll capture a list when you document the Context of your Organization. Whether you need to document them any more extensively than that is up to you. (You may remember that last fall I described a stakeholder matrix which captures a lot of information about each interested party, but it's more than most organizations need most of the time.) 

What next?

And after that, it all depends on what you need. A common approach for some companies is to set quality objectives for their suppliers to meet, and then offer support as the suppliers strive to meet them. 

Whether this approach will be useful for you depends on many factors, but it is only fair to add that an important one is surely the question, "How much of the supplier's total business do you provide?" If you are a major customer for this supplier, they are likely to want to work with you. If you are a minor or negligible customer for that supplier, they may be less motivated.

It can also happen that your supplier might point out features of your own operations that hold you back. Maybe you ask your supplier what it would take to negotiate lower prices, and they tell you, "All your orders come in as emergency rush jobs with no lead time. Since we can't plan for them, we have to charge you premium prices." That's a sign of a Quality problem in your own operations—namely, that your planning isn't very effective. If you can solve that problem, it will benefit you in dozens of ways not limited to the prices you pay your suppliers!

If you and your suppliers can help each other in even simple ways like this, you have take the first steps towards growing your relationship into a kind of partnership.

Of course you can go farther. You can enter into collaborative relationships with other businesses, if there is value to be had by doing so. There's even a standard to help you define a system for such collaborations: ISO 44001—Collaborative business relationship management systems. But that's not for everyone. As always, it depends on what you need.

Even if you don't need any formal partnerships and aren't interested in collaboration, though, you still need basic relationship management. No company is an island. And if you treat your interested parties like they matter to you, the odds are good that you'll matter to them.

       

What is Evidence-based decision making?

Last week I quoted the Michael Toy on the unpredictability of major improvements. In the same blog post that I referenced, he also remarks, "Reality Is a Good Thing." His point, of course, is that you have to base your decisions on actual facts, however unpleasant those facts might look. If you base your decisions on wishful thinking instead, that doesn't make the facts go away! All it means is that you will be unprepared when you run smack into them.

This sounds obvious. Why do we even need to mention it?

The problem is that if we are not careful, it is easy for us to confuse ourselves about what the facts really say. It is always tempting to believe what we hear from our friends, or what we think sounds obvious, or what we read in the papers, or what we get from a well-advertised numerical model.

What we need is evidence.

Sherlock Holmes looking for evidence.

ISO 9000:2015 recommends a number of "possible actions" that an organization might choose to take, to ensure that decisions are based on objective facts—that is, on evidence. Among these actions are such measures as:

• determine, measure and monitor key indicators to demonstrate the organization’s performance;
• make all data needed available to the relevant people;
• ensure that data and information are sufficiently accurate, reliable and secure;
• ensure people are competent to analyse and evaluate data as needed. (2.3.6.4)     

These measures should look familiar, because they are all fundamental requirements of the corresponding management system standard ISO 9001:2015. It is only a small exaggeration, in fact, to argue that the whole point of the ISO 9001 schema for quality management systems is to ensure that organizations have the data they need so that they can make evidence-based decisions about how to improve. Look at that list again:

• The organization has to determine key indicators of its own performance: but these are just the quality objectives that ISO 9001 requires in clause 6.2, along with the other performance monitoring required in clause 9.1.
• The data has to be made available to all the relevant people (as I discussed in this post from 2021 about process management).
• The data has to be accurate, reliable, and secure: but this is why the organization has to control its own documentation (as provided in ISO 9001, clause 7.5).
• People have to be competent to understand and analyze the organization's data: but this is why the organization has to determine its competency requirements and then take steps to make sure they are met. (All these requirements can be found in ISO 9001, clause 7.2.)

And so on.

For that matter, what is an internal audit (ISO 9001, clause 9.2) but a tool for collecting evidence—"objective evidence" is the technical phrase—of how well the organization is fulfilling its compliance and quality obligations? Then this evidence is discussed in Management Review (Ibid., clause 9.3) to feed decisions about the strategic direction and tactical implementation of the quality system. Again, the whole structure of the standard's requirements is designed to provide factual evidence to management to serve as the basis for decisions. We discussed a couple of years ago why this information has to be factual, and why (in consequence) you should never lie to your auditor!

So yes, in a sense the principle is obvious. But it's still important to state it explicitly. Fortunately, if you work with a standard like ISO 9001, its requirements do much of the work for you.

Of course, the importance of weighing evidence and accepting reality stretches far beyond the cloistered world of quality management system standards. One of the best stories I ever heard about facing reality head-on comes from cattle ranching, which is a far cry from most applications of ISO 9000 or ISO 9001. It goes like this:

A story is told of a Tonopah preacher who was delivering a funeral sermon over the casket of an old range veteran long and widely known in Nye County. The garrulous clergyman was waxing unctuously eloquent. "Old Dan is not dead," he declared. "He has just taken the highest trail ...." The sardonic voice of another old puncher sounded from a rear pew of the church, "I got a hundred sez he's dead!"*

Reality is a Good Thing.

__________

* Owen Ulph, The Fiddleback: Lore of the Line Camp (San Francisco: Browntrout Publishers, 1995), pp. 69-70.    

What Is Risk-Based Thinking?

Despite the "What is …?" title, this post is not part of my current series on the Quality Management Principles (the one starting here). 

But late last week, Quality Digest published my article, "What Is Risk-Based Thinking?" It's their article now so I won't post the text of it here, but you can find it by following the link. I hope you find it useful!

   

What is Improvement?

We all know that improvement is about making things better. Since Quality is about making things good, it's natural that they should fit together.

Or is it? Someone might answer back, "If I make something good to start with, why do I have to improve it later? Isn't 'good' actually good enough?"

It's a fair question. Let's discuss it. While we're there, we can also ask, How do you get improvements? And what exactly counts as an improvement in the first place?

The Red Queen's race

The Quality Management Principles—of which Improvement is the fifth—are spelled out in ISO 9000:2015. When it explains the rationale behind improvement, the standard says (in part):

"Improvement is essential for an organization to maintain current levels of performance, …." (2.3.5.2)

Wait, what? Yes, in answer to the person who asked, "Isn't 'good' actually good enough?" the ISO says that you have to keep getting better just to stay in one place. 

By John Tenniel - Public Domain,
https://commons.wikimedia.org/w/index.php?curid=14629431

It sounds like the Red Queen's race. You may remember that in Lewis Carroll's Through the Looking-Glass, Alice has a discussion with the Red Queen:

"Well, in our country," said Alice, still panting a little, "you'd generally get to somewhere else—if you run very fast for a long time, as we've been doing."

"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"

But that's just a fantasy story! Can it really be true?

In a sense, yes it is. On the one hand, the more you do the same thing the easier it gets to do it. This is the benefit of practice. But over the long haul, things change around you. Prices rise. Supplies recede. New steps have to be added to your process to address new concerns. And competitors start to encroach on your activities. Pretty soon, if you are still producing exactly the same good product that you produced back in the day, you'll find yourself shut out of the market because the world has moved on around you.

So yes, you have to improve regularly just in order to stand still. The Red Queen's race is real.

Is there an improvement process?

Last week we discussed the process approach as a tool for understanding the nature of work. If improvement is mandatory, it would be nice to know how to get it; and defining a process for it would be a big help. Sure enough, ISO 9000:2015 suggests that one of the things you should do is to:

"develop and deploy processes to implement improvement projects throughout the organization." (2.3.5.4)       

I hate to disagree with the ISO, but it's not so easy. There is no uniform methodology that is guaranteed to generate improve­ments, in the same way that there is no process which can guarantee business success. 

Of course there are tools that will help! If there are problems with your existing products (just for example) then solving those will count as an improvement. And there are problem-solving tools (like 8Ds) that will help you do just that. But sometimes what you need is a new idea that will lift you clear out of your current way of doing things. And there is no systematic process on earth which can guarantee that.

Years ago, I saw a blog post from the Michael Toy, called "An Open Letter to Prospective Employers," which made this point with a clarity I cannot hope to excel:

"If you want consistent measurable progress towards a well defined goal, you would be a crazy fool to hire me. If you hire me, you will spend long months wondering why you did, and you will have exploratory conversations with HR about put­ting a performance plan in place, and then there will be this six month period when I will do three things which will trans­form your business for good in ways you could never have imagined."

The best improvements are like that.

What counts as an improvement?

An improvement makes something better. Better for whom? Is it good enough to say that I like it, so it's better for me?

Generally not. The Quality Management Principles interact; you can't apply them in isolation from each other. And remember that the very first Principle is Customer focus. So "improvement" means making things better for your customers.

Sometimes this is hard for organizations to understand. All too often, in fact, you find companies making changes that no customer wanted, purely for internal reasons. Maybe it was so that they could keep their design staff busy. Maybe it was so that they could announce something new in the industry journals, and therefore keep their names in the headlines. Maybe it was because they forgot the difference between features that are cool and features that are useful. Whatever the reason, though, there are far too many organizations who introduce changes that make their products or services more difficult and more forbidding. These organizations have forgotten that they exist in the first place only to serve customers.

Don't copy them. If you introduce an improvement, make it a real improvement. Make it something that your customers rejoice to see.

Bill Maher talks about the phenomenon of "reverse improvement" in this clip here:

   

What is the Process approach?

The fourth Quality Management Principle is the Process approach. And unlike the case with some of the other principles, I have already written a fair bit about it, here and elsewhere. In fact, by a curious synchronicity, I just finished an article for publication explaining the process approach in some detail. If it finally sees the light of day, I'll make sure to post a link in this blogroll, just as I have for other articles I have published in the wider world. 

So instead of laying out the elements of the process approach yet again, I want to take a few minutes to explain why it is so ubiquitous. After all, no sooner do you start working in Quality than you hear about processes. They seem to be everywhere. I have seen companies unironically publish a process on how to write processes.

Why is this? Has everyone just gone crazy?

No, not quite. It turns out that the process approach is a remarkably useful and powerful tool for describing work.

Work can be confusing when you look at it on a large scale, because there are so many people doing so many different things. It can look as crowded and confusing as … well, let's say a county fair.

But look at the same fair through the lens of the process approach, and it all begins to make sense. Everyone is there for a reason. And mostly, everyone's activities can be described with a process.

• The hot dog vendors are there to sell hot dogs. Their process runs something like this: Take an order; prepare the hot dog; give the hot dog to the customer; collect the money. Repeat.
• The cotton candy vendors are there to sell cotton candy. Their process is almost exactly the same.
• The cheese curd vendors are doing the same thing again.
• The team in charge of the Ferris Wheel are selling tickets on the Ferris Wheel, much like the other vendors. But their process interacts with a second process that turns the switch so the Ferris Wheel rotates.
• The 4-H Club is there to show off their animals. They have a different process, but it is still a process that they cycle through several times during the day.
• Even the vacationers, who are visiting just to see the sights, are following a kind of process of their own, though their process has room in it for a little more variation. But roughly it goes something like this: Drive to the fair; park the car; walk down the Midway; go to the first exhibit; go to the second exhibit; get some food; go to the third exhibit; get some more food; go to the fourth and fifth exhibits; walk back to the car; drive home.  

And all of a sudden, this huge, confusing swarm of people makes sense! All you have to do is to look at it as a collection of interacting processes, and the chaos becomes order. This is because the process approach gives us two kinds of information about the activities of every participant: purpose and predictability. That is to say: when you describe everyone's work as part of one process or another, you tell us what they are going to do and also why they are doing it.

If you want to understand work on the large scale—whether you are describing a county fair or a factory building airplanes—there is simply no intellectual tool more effective than the process approach. It's ubiquitous—nay, universal—because it works.

On top of all that, there's another benefit to the process approach. Let's say you've been put in charge of a huge, teeming swarm of work: maybe an aircraft factory (just for example). And let's say you've been told you have to make the operation more efficient. Where do you start?

You start by studying the processes. After all, if you want to make the work more efficient, that means making George's work more efficient, and Sam's work, and Fred's work, and Max's work. You can't do that unless you know what they do. But reading their processes tells you what they do, and it also lets you look for optimizations. 

"Hey Max, why do you walk clear across the plant twice, every single day? Wouldn't it be easier if you rearranged the steps in your job so you didn't have to do that?"

Ask that question a thousand times, and you cut in half the man-hours it takes to produce your airplanes. But you'll never know to ask the question even once until you read the processes. 

These are the benefits of the process approach.

But what are the elements of the process approach?

There are several. I've written about most of them before.

If you want further discussion of what processes can do and can't do, check out this post and this one.

If you want to implement the process approach in your own organization, consider this series of posts on:

• writing processes;
• owning processes;
• and measuring processes. (Consider also this post on how measuring can go wrong.)

When it's time to follow up on your process implementation, the tool for that is management review. I mention that several times; but my most important advice is in this post and this one.

Also (according to ISO 9001:2015, clause 0.1, paragraph 6) the process approach includes two other tools that I would probably have listed separately. But who am I to argue with the ISO? These tools are:

• the Plan-Do-Check-Act (PDCA) cycle, which I discuss at a high-level in this post, and then in excruciating detail (although without using the PDCA acronym, but this is definitely what it looks like in practice) in this post;
• Risk-based thinking, which largely refers to what used to be called "preventive actions" or "lessons learned" (see especially this post here and this post here). I've recently written another article for publication in the outside world on the subject of risk-based thinking. So if it sees the light of day any time soon, I'll link it here as well.