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.