Updated: Sep 9
Let me start this by providing some context. I am a professional engineer who studied electrical / computer engineering back in the 80’s. You could say that I found compliance the long way around. As it turns out, compliance is not so different from engineering at least the way it is now.
For most of my career I designed, built, and deployed systems to support compliance. In my early days, I developed systems for testing integrated circuits at both the wafer and packaged goods stages. You could say that this was dealing with a type of compliance: conformance to technical requirements and specifications.
I then went on to implement quality management systems, document management, records management, data management, product life cycle management (PLM), DHF and DMR systems, ISO, and so on across multiple industries across North America. These had more to do with supporting compliance commitments instead of meeting compliance directly, but important, nonetheless.
What I found, which brings us to the topic of this article, was that compliance was considered as an extra layer, an extra process, and extra program for many and most organizations and still is for the most part.
Compliance you could say was all about meeting all the requirements over and above what was needed to get something to work such as quality, safety, security, sustainability, and so on.
These are still requirements. But for some reason we didn’t, and we don’t treat them that way. We see these requirements instead as obstacles and in the way of getting something to market, a business launched, or a service delivered. And here's the thing – we still do.
Compliance as Imagined
Compliance as it was imagined, prescribed, and enforced was not welcomed and at most tolerated. And yet at a fundamental level was no different from designing systems to meet product, business or services requirements. So what is going on?
If that wasn't enough of a question to answer, organizations decided that if these “other requirements” were going to be addressed it was going to happen at the end of the production process. Not earlier on as part of design. We don’t want to hinder innovation they would say.
Now if you were in manufacturing, you were not happy with that approach as these extra steps would delay getting product out the door. This was a source of much of the push back and tension similar to what product engineers and designers are experiencing today when asked to consider "non-product" requirements int their design.
After years of doing compliance this way no wonder people don’t like compliance. Not only that – they don’t want it. In fact, for those familiar with LEAN, you will know that it has a blind spot when it comes to compliance. LEAN views inspections, for example, as non-value add, a waste and something to eliminate. And guess what, lots of people view compliance this way.
I knew there had to be a better way to do compliance where it was a value-add and not a waste which was the genesis for founding Lean Compliance – you could say – to correct this blind-spot. But this change could only happen if and only if there was a change in perspective.
Back to the question: Compliance: Obstacle or Opportunity?
If we are keeping score, I think compliance as an obstacle is winning. But let’s unpack this some more and see if we can discover the root cause of why this is the case.
To help with that it is worthwhile looking at the tension between business and compliance which is not new thing and something we understand quite well. There have always been priority differences between what the business wants and what compliance wants.
In fact, the way I stated these earlier telegraphs the cause of some and perhaps most of this tension. Business and compliance objectives for many are seen as mutually exclusive and not aligned to the same goals. At least, that’s how it looks to most.
Back in the 90’s when ISO 9001 (the quality management standard) was introduced it was all about inspections and quality control. Compliance was measured by conformance with product specifications, which in turn would help identify defects, that would be corrected or at least measures put in place to prevent them from occurring again.
We were contending with quality at the event horizon — the place where risk becomes a reality – and that is what a defect is.
Defects are the effects of uncertainty in the production process or in the design itself that have been realized.
Now, if you were a production manager how could you not see all the inspections and audits as getting in the way. The delays were not the real problem. It was what was discovered that was. Quality control was exposing what was hidden and made it visible.
The Root Cause and Antidote
The real problem you could say was that there was a misalignment of priorities that was made visible by the introduction in this case of a quality standard.
For production the goal is to meet schedules and to ship product on time. All these other steps: inspection, quality control, corrective actions, etc. tacked on at the end of the process would and did cause delays and cancelled orders. So no wonder compliance was seen as a tax on production, an obstacle to getting on with the business. If we don’t ship on time we will lose customers which was a real concern.
I don’t think this perspective and tension between production and compliance has changed over the years. In fact, I was recently had a conversation with a high-tech company in Europe, and this was exactly the problem. Competing priorities. Competing goals. Nothing has changed.
But compliance has.
Let me explain.
Since the 90’s, and for all those that effectively manage quality, some would experience less defects, fewer delays and in fact shorter cycle times, and something else – they would experience customers who were more satisfied with their products.
Imagine that! Instead of losing customers, they were gaining them.
Even at the edge, at the event horizon, the last line of defence; compliance had an impact. But, how did this work? How was compliance able to do that?
And now we get to the heart of the matter – the power of compliance.
Compliance presents a process by which a standard could be used to evaluate the current level of conformance, in this case, with quality requirements not technical requirements. We already were doing technical requirements and accounted for it in our product designs. Compliance added a new benchmark – a new design objective for engineering.
That’s what compliance does. It set’s an ideal for us to achieve: better quality, better safety, better security, better sustainability, you can call this drive – operational excellence – if you like.
These standards, not the management standards, but the ideal of what we want, act as a measuring stick. They make what is invisible visible. However, that is only half of its power.
Exposing gaps creates new problems to solve, new objectives to improve, and even new opportunities to innovate.
Taiicho Ohno the father of Lean was known for saying, “without objectives there are no improvements”. Without a standard there are no gaps. When there are no gaps we have no problems to solve – no need to innovate.
As it turns out:
Compliance creates the opportunity for innovation.
This is the real power of compliance.
Compliance is not a set of check-boxes to tick off or to feel ticked off about. Instead, the purpose of compliance is to drive the organization towards better outcomes. Something we can and should all be aligned with. For that is what compliance is all about – alignment – staying on course, on-side, on target, and on mission.
Moving Back from the Event Horizon
This notion of alignment has been applied throughout the entire value chain. The body of knowledge has expanded to safety, security, sustainability, and many other fields. We now have a better understanding of the nature of obligations, how to contend with uncertainty, and how to regulate not only outputs but outcomes - the field of cybernetics of which control systems engineering is part of.
Compliance has progressed and has moved away from the event horizon where – risk becomes a reality – and has moved towards the source of risk itself. The place where – uncertainty creates the opportunity for risk. It is about being proactive and preventing non-conformance in all its shapes and sizes.
Compliance is also still about regulating – something that is often forgotten. Compliance is now regulating how and what we do to increase the probability of the outcomes we want and decrease the probability of outcomes we don’t want. In fact, compliance helps us avoid obstacles and threats, and helps us now to enable and exploit opportunities to achieve mission success.
This is why requirements are no longer just technical. They have expanded to include all the other requirements associated with risk. That is why compliance needed to change and so should the way we do engineering.
Engineering needs to learn to innovate across all requirements not just the technical ones if we want to stay ahead of risk. This requires thinking in engineering terms such as: Design Thinking, Systems Engineering, Model Based Engineering, Digital Twins and Threads, Risk-based Thinking, and so on.
What do you think now?
Is Compliance an Obstacle or an Opportunity?