What's so bad about Management Review?

Last week I argued that Management Review is the key element of a Quality Management System, because feedback is what turns any phenomenon into a system, and Management Review is the highest and most comprehensive feedback mechanism in the organization.

But Management Review has, to put it gently, a mixed reputation in most businesses. For every Quality practitioner who (like me) insists that it is the heart of things, you can find several who concede grudgingly that yes, it is required; but who also know that most managers in their organizations will do anything to get out of attending.

How can this be? The problem is that there are many ways management reviews can go wrong. If you avoid them, the meetings are engaging and productive, but it's a high-wire act. Slip just a bit, and you miss the target in a big way. As I wrote once in another context, there are many ways to make management reviews boring and over the years (before I finally learned better) I've used most of them.

A couple of years ago, Bill Hackett of QBD Strategies posted a discussion on myASQ that nicely summarized the weaknesses he has most often seen in management reviews. It's a good list, so I'd like to abbreviate it here.

Senior management not present

The whole point of the meeting is to assess whether your QMS is working, and then—in case it's not—to take decisions that will put it back on course. If senior management is missing, you can't take fundamental decisions and the meeting becomes pointless. (The absence of senior management is also a formal failure, because [for example] ISO 9001:2015, clause 9.3.1, defines the whole activity by saying that, "Top management shall review the organization's quality management system, at planned intervals, ...." But next to the pragmatic problem, that's almost beside the point.)

Reviews occurring infrequently

Yup. If the reviews are few and far between, you spend the meeting time rehashing ancient history. The issues were resolved months ago, but here are more slides about the same subjects, just because. Pretty soon people are checking their phones and the meeting is dead.

No established agenda

I don't know how you can hold a meeting without an agenda, but Hackett says he's seen it plenty of times in audits. No agenda increases the chance of missing something important, and it means you can't ask participants to be prepared ahead of time. So how can you get anything done?

Lack of process ownership when reporting

Without a clear owner for each process, you can't tell whose job it is to fix something when it goes off the rails. I talk about process ownership at some length here, and it all applies.

Insufficient or irrelevant information presented

Heavens, yes. When you are close to a problem, you see all the details and you know intimately why they are important. But when you generate your PowerPoint slides to explain the problem to management, it's easy to leave out the parts that you think are "so obvious" you don't have to mention them. Bad news—these points aren't obvious to top management, and you do have to mention them. When you are urgently explaining that "The glitzenhammer has to be refrangulated right away!" and they stare back at you in bafflement, it's a sign you might have left out something important.

Lack of support for management review facilitator

I might phrase this as "lack of support for the management review process," but we mean the same thing. You can't possibly put on the whole meeting yourself. You need the input and cooperation of the functional areas. Also, as Hackett points out, it helps to use templates (so the information is all presented the same way); it helps to collect it all beforehand (so that the presentation is smoother, and so you can check if some of the results look wrong); and so on. Every step of the way you need the support of others.

The good part is that if you can make the meeting run smoothly and productively, then the process owners and functional specialists that you have to rely on will be happy to cooperate. At least that has been my experience. It's almost as if addressing the first five on this list buys you the sixth one for free. Of course, nothing is really free. But addressing these gaps is the first step to creating a dynamic culture for management reviews. It's possible. And it's worth it.

   

The key to your management system

A few weeks ago, Etienne Nichols of Greenlight Guru posted a question on LinkedIn:

"What is the most important part of a Quality Management System?"  

He listed several candidates:

• Purchasing?
• Quality Policy?
• Customer Focus?
• Design & Development?
• Management Responsibility?
• Documentation and Traceability?
• Corrective Action / Preventive Action (CAPA)?

It will surprise none of you that I disagreed with all of these choices. Here's what I told him.

Management Review. No question.

Of course the reality is that they are all important, like [your other respondents] have already said. But the other reality is that you'll never get it right the first time around, no matter what. So it's critical that you have a mechanism for evaluating what went wrong, and then assigning actions to make it better.

Most management systems have several of these mechanisms, at different levels and with different frequencies of recurrence. But Management Review is (so to speak) the master evaluative mechanism, that incorporates all the others. Therefore Management Review is ultimately what makes the difference between just having a heap of rules and having a true management system.

That prompted a bit of a discussion. Among other things, he asked me how often a startup should schedule Management Review for maximum effectiveness. I answered:

Goodness, there's probably no one-size-fits-all answer. And it depends what you have in mind.

There will be some things you try to implement, and on the first day it becomes obvious you missed something important. If that happens, and you can see how to patch it so it's functional again, don't wait. At the same time you don't want to second-guess yourself every single week.

I'd probably settle on suggesting that you schedule a regular Management Review once a quarter: that gives you long enough to make progress on (for example) the risks and opportunities you've identified as part of the Context of your organization, but it's not so long that you waste time reviewing ancient history. (Holding these reviews once a year is WAY too infrequent.) 

Of course, if you hold them that often you also have to optimize the meeting so that it takes not one minute longer than you really need. There are ways to do this, but they all take a lot of focus. 

If you're looking for more opinions, I could talk for hours. 😀 

That last sentence, too, should surprise none of you.

      

Does your management system have a life of its own?

Last month I was writing about systems theory, and about how far it can help us understand management systems. Along the way I discussed a primer by Donella Meadows, the research of Ludmila Praslova, and the latest book by John Seddon. Of course it's a big topic—Seddon's book alone is scarcely over 150 pages, and he covers far more than I'll ever be able to summarize here—but there is one important point that I want to emphasize. It is something that Seddon more or less takes for granted, but it also ties back neatly into Meadows's work as well, and it deserves to be stated explicitly.

The point is simply this: You cannot know how your management system really works without studying it in operation. Over and over, Seddon says that the key to getting executive management engaged in improving their business systems is for the executives to study how things really work in practice. While his book contains a lot of good general advice, his most important point is that you already have all the information you need to improve your business, sitting right in front of you. All you have to do is study it until you see it.

Why do I emphasize this? Well, when we look at an organization's management system (QMS, EMS, or any other) the presumption is always that the system is fully defined on paper. There is, let's say, a Quality Manual; there is a process map; there are policies and procedures; there is an organizational chart, and there are assignments of roles and responsibilities. All of that written documentation, taken together, is the management system. So it is natural to wonder, why do we need to go out on the floor and watch it in practice? Since the whole thing is (presumably by definition) fully defined in the documentation, what more do we need?

Remember that Meadows says one of the key features of systems is self-organization. This means that systems are likely to surprise us by behaving in ways we would never have guessed from their definition. In a sense, systems behave as if they are alive. Yes, we start by defining them on paper. But as the work progresses, there will invariably be factors we did not take into account in the beginning. The people doing the work will adapt to these factors, as they do so subtly changing how they work. The changes may never be so great that they become non-compliance. But it is amazing how unexpected a behavior can get while still complying to the letter of the written procedures. (See, e.g., this post about process metrics.)

And in fact, in all the case studies that Seddon describes, the executives thought they knew how their systems worked precisely because they understood how the systems were documented on paper. They had exactly the same knowledge of (say) their operational systems that we in the Quality business think we have of management systems. And every time, they were wrong.

How do we get better knowledge, then? By watching, with attention. It is tempting to say that this is what audits are for, and of course partly it is. But mostly audits are carried out to ensure compliance, not simply to learn. This focus has the potential to skew the results, because the workers being audited won't want to "do it wrong." Also, in practice, there are always a number of audits done by rote, just to fulfill a requirement on the calendar. The auditor shows up in a work area, asks a few questions, checks that the required artifacts are available and current, and then moves on. I'm not saying this to criticize auditors: sometimes because of circumstances that's the best you can do. I know it, and so does every other auditor. But we should stay open to the possibility of carrying out open-ended audits once in a while, not to check for compliance but to learn how things really run. It's a thought, at least.

Meanwhile, in the same way that there is no perfect process, we should remember that there is no complete system description. And there will always be the chance for things to surprise us.

       

How could ISO 9001 stop climate change?

I was going to write more about systems thinking, but something has come up and I want to address it while it is still timely. Two weeks ago the leadership of TC176 SC2 (that's the subcommittee that writes the ISO 9001 standard) held an ad hoc meeting to discuss what impact the topic of climate change should have on ISO 9001.*

Image by Kanenori from Pixabay

You remember I wrote about this topic last fall in this post here. At the time, I argued that climate change is out of scope for ISO 9001, and that any attempt to shoehorn the topic into the standard would be bad for the ISO brand. Specifically, I think there is a meaningful risk that updating ISO 9001 to address climate change will either push companies to abandon ISO 9001 or else make them more cynical about the process of certification. Or both, of course. I have not changed my opinion in the intervening months. 

But my opinion is, to put it gently, not the only one on the table. So there was a meeting to talk it over.

What was proposed?

Under discussion were two proposals. Both were to add specific wording to the Harmonized Structure for ISO Management System Standards. That means that this wording would appear in management system standards across the board: not only ISO 9001 and ISO 14001, but ISO 20000, ISO 21001, ISO 22000, ISO 28000, ISO 29001, and obviously many others.** 

The first proposed change would add a requirement to subclause 4.1 as follows:

Today the clause reads:

4.1 Understanding the organization and its context

The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended result(s) of its XXX management system.

The proposal would add:

The organization shall determine whether climate change is a relevant issue.

The second proposed change would add a note to subclause 4.2 as follows:

Today the clause reads (with minor variation among standards):

4.2 Understanding the needs and expectations of interested parties 

The organization shall determine: 

— the interested parties that are relevant to the XXX management system; 

— the relevant requirements of these interested parties; 

— which of these requirements will be addressed through the XXX management system.

The proposal would add:

NOTE: Relevant interested parties can have requirements related to climate change.

What does the first one mean?

Image by Darwin Laganzon from Pixabay

The first proposal adds a "shall" statement. This is an explicit requirement. It is auditable. Every certified organization would have to comply.

Even so, this "shall" statement would not require that an organization actually do anything about climate change. In fact if the organization were (for example) a hamburger stand—and ISO 9001 is supposed to be applicable to hamburger stands, in case one wants to be certified—there might not be much meaningful that they could do. But they would have to "determine" whether climate change is a relevant issue for them. Since this requirement is auditable, they would have to keep meeting minutes showing the decision. 

Not everyone agrees with me that some organizations might find it hard to take meaningful action against climate change. During the discussion, some people argued that, "There is not one organization in the world that can determine climate change is not a relevant issue. This would de facto mean you have to address your influence on climate change, even without requirements from relevant parties (see 4.2)."

I disagree, and I think the people who argued this have confused two different questions. The problem is that the word relevant is ambiguous. So I think these people have conflated: 

• Will the organization be affected by climate change? ... and ... 
• Can the organization do anything about it?

I am prepared to agree that the answer to the first question is "Yes" for most people (and therefore most organizations). But for small organizations the answer to the second question is often going to be "No". And those organizations should be allowed to say so when they establish their Context.

What does the second one mean?

Chemical Engineer, Public
domain, via Wikimedia Commons

The second proposal simply adds a note. Notes are not auditable, so this would not impose any requirements on the certified organization. In fact, the note doesn't address the certified organization at all: what it tries to do is to read the minds of interested parties by describing what can be included in their requirements. But it is still up to the interested parties to explain their requirements to the organization. It is never the organization's job to tell their interested parties what they should want.

To be sure, as an objective statement of fact the note is completely true. Relevant interested parties can have requirements related to climate change! There is no question about that. Of course, they can also have requirements related to macramé antimacassars, so by itself that's not saying much. Still, it's a true statement that requires nothing from the organization which they aren't going to hear about anyway. In that sense the proposal is completely harmless, and it gets the words "climate change" into every standard that follows the Harmonized Structure without disrupting anything else. From a certain perspective that might look like a win for everyone. 

What was decided?

In a final sense, nothing was decided. What I mean is that there were no formal decisions to make any changes to ISO 9001 or any of the other standards based on this meeting. Lots more votes will be required, at multiple levels, before any changes are formally authorized. But the options were reviewed, and doubtless some suggestions based on this meeting will be forwarded on to the next one.

If you are involved in this decision process, please think about which position you most agree with. If you are on the receiving end of the output, you may find it helpful to know what is being discussed. I hope this helps.

__________

* Since this post, like my earlier one, reports on the deliberations of an ISO Technical Committee, and since I am a member of the American TAG 176 which forms a component of that committee, allow me to repeat the formal regulations that apply to this discussion.

1. I'm not allowed to reveal the personal data of any other committee member. But that's fine, because I have no interest in talking about individuals. My topic is always the ideas and principles.
2. I'm not allowed to reveal how any particular individual or National Standards Body voted. But that's fine too. See above.
3. I'm not allowed to share any presentations or working documents. But I never planned to. If you find such materials anywhere on the Internet, they didn't come from me.
4. I am allowed to share my personal opinions, so long as I clearly identify them as such (and to be clear everything in the body of this post is hereby identified as a personal opinion), and so long as I don't criticize the committee. But that's fine too, because you should absolutely not take anything I say here as a criticism of the committee. I am confident that the committee will do the best it possibly can, given the parameters that it has to work within.

** I didn't even get past the 2xxxx's.