In May 2018, I got a chance to write as a guest for SharePLM.com. I chose to develop my own ABC’s of product management, and started with the “Always Be Competitive” theme. Here is my next article about PLM Compliance!
“Your industrial machine is not in compliance with the Hygiene Standards of the Sanitary Norm in our country. We request you arrive to our processing facility, and conduct modifications to make it compliant.”
This was the odd customer complaint I found some time ago. Our industrial product had absolutely nothing to do with a sanitary process, nor was there any case requiring hygiene.
So how can this be even remotely relevant?
This sanitary norm was not even mentioned in the original customer contract and requirements.
Well, it turned out that the machine was vibrating in that particular customer application. In this country, the impact and quantity of vibration that the operating personnel are exposed to, is regulated in the Occupational Health and Hygiene Standard, included in the Sanitary Norm.
We managed to translate the said norm, and verify the machine behavior against the allowed levels of vibrations. Some modifications were done, and the design guideline was updated. For subsequent product deliveries to that country, the local sanitary norm was added to the list of “in compliance with …”.
In a way, product compliance does not even need to be mentioned as part of a product managers’ duties, because it is not optional—your product either is compliant with laws, regulations and authority requirements, or it is not sold in that marketplace. What is optional is the selection of which markets participate, and hence limit the requirements to an extent. I say “to an extent” because in today’s world and online trade, people and products travel—who knows where your product will end during its lifecycle! So bear in mind that the selection of target markets and customers will have an influence on your product costs, and the way you should modularize it.
In this article, we’ll look at four different areas of PLM compliance, and offer some hints on how those influence product managers’ work.
International standards – or lack of them
Let’s start with the easy ones. You will most likely base your product design—or at least some features of it—on one set of international standards, be it the ISO, IEC, etc., whatever is most relevant for your product. Another option is to use local standards that your design team knows best, and then seek international equivalents of them. For some features of your product, there may not be relevant global standards, only some local ones. But they are better than nothing and provide a good backbone for your product design criteria.
International standards do not only state WHAT the end product should be like to ensure it is safe, does not pollute, saves energy, etc. They also require you to document the process of HOW you got to your end product. For example the European Machinery Directive mandates that you produce a so-called “Technical File,” which must provide full traceability from initial requirements to the final product.
All general and customer specific requirements, used design codes and methods, risk and impact analyses, calculations and simulations, design documents, manufacturing methods, material certificates, workers’ qualifications, inspection and test results, installation and commissioning logs, and acceptance certificates must be provided.
My advice is: don’t be afraid of the standards! Try to design your product according to or applying some relevant standards as close as possible to your product.
If you say to your customer that “our product is so unique in design that none of the standards can be applied to it,” you will have a hard life.
It is much easier to say: “Our product is designed in compliance with ISO, relevant sections of the API standard, the Eurocode parts, etc… Additionally, we apply our decades of experience in verifying the optimal design.”
Take the documentation requirements seriously and try to adapt your design process so that the documentation is captured transparently and effortlessly. Providing full traceability from scattered documents and memos is laborious, especially when the design process is long, concurrent and multi-disciplinary, and there are customer specific requirements. Instead, see if modern methods like Configuration Management or Model-Based Systems Engineering could be applied.
The sanitary norm and other local requirements
Despite globalization, there are still plenty of local requirements, such as the 14 different types of electric plugs in the world, or the sanitary norm that regulates vibration exposure of workers.
When assessing your target markets, you will need to pay attention to local regulations and legal requirements. Governments and regulatory bodies are relatively good at publishing these, but you may speed up the work by getting some consultation.
Regulatory requirements are most pronounced and documented for products which are intended for consumer use. This is understandable, considering the large exposure and the nature of the use of products—not many of us read the instructions carefully to avoid risks.
The product should be compliant with regulatory requirements AND provide a user experience that assures safe use.
In Europe, there is a list that no company wants to end up on: the European Commission’s Rapid Alert System for dangerous non-food products—aptly abbreviated as RAPEX! This list is updated weekly and is followed by every newspaper and magazine. Being on that list is a guaranteed way of getting publicity, but it can also be used to quickly inform potential product risks. You can try it yourself by searching some known brand names, for example, your own car’s manufacturer.
Customer requirements (and all other relevant requirements)
For Engineer-to-Order products in industrial markets, customer specific requirements are the bread-and-butter of business. In a way, these are relatively easy to handle, as the majority of the clarifications and discussions are focused on these special requirements. They are also more explicitly documented and attached to the contract. Make sure they are also documented in your PRODUCT. You need to be able to trace all requirements, all of the design intent, and the end result as I mentioned above in the case of the European Machinery Directive. Documenting the customer requirements of your varying product structures will also help you next time you need to do a custom design—it may already exist in an earlier variant!
The tricky parts are actually the things NOT discussed in detail, but only listed or mentioned briefly in the contract documents. Local regulations and standards often only refer to codes like ASTM, or even more generally, “all relevant international and local standards, codes, regulations and statutory requirements.” And because of this, I gave my advice before to not be afraid of listing the standards and codes of your product design. It is a more firm ground to stand on.
The Moose Test compliance
In today’s world, news and reviews travel even quicker than products. If your product fails compliance standards in one marketplace, you can expect a quick backlash globally.
Not all compliance requirements are documented and known in advance. I call these the “Moose Test compliance.” Last year we “celebrated” the twenty-year anniversary of an event with epic consequences—the 1997 Mercedes A-Class failing the so-called Moose Test. It was a high-speed evasive maneuver, designed to test the stability of a car, conducted by the Swedish car and technology magazine “Teknikens Värld.” This test was not at all included in the requirement sheet of the car design, as it was at that time only carried out by some Nordic magazines for the benefit of local readers.
The car turned over violently in the test, and the same almost happened to the company and its top leaders! Production of the car was halted and a crisis team was set up to work out a solution. One of the corrective actions of the manufacturer was to fit the car with an Electronic Stability Program (ESP). By doing so, the unfortunate event actually sped up the utilization of this safety feature in lower price car classes. The quickly renewed A-class subsequently passed the test, and ever since the “Moose Test” has been included in Daimler’s and every other manufacturer’s requirement list. It’s a great case in getting product feedback, addressing it rapidly as product improvements, and using it to feed future R&D. That sounds like another ABC: Always Be Closing the (feedback) Loop!
With respect to the Moose Test compliance, I have two bits of advice. Firstly: ABC – Always Be Connected. Use web analytics to find out where and how your products are being reviewed and discussed. Secondly: be prepared to handle a crisis. Plan and rehearse a difficult public situation and how to discuss it. Who communicates in which channels? What are the internal measures and task forces? Silence is rarely a good option, and as we learned in the Moose Test incident, addressing and recovering from a crisis may become a positive incident that actually strengthens your image. Manufacturer recalls are fairly common nowadays.
In this article, I touched the areas of PLM compliance and how they should be taken into account by the product management.
There is also the option to try to influence standards, regulations, and requirements. It is known practice that major industry players are using substantial resources to steer and guide standard and regulatory bodies, either by directly participating in the development work, or via interest groups. One example could be the International Telecommunication Union where surely all telecom industry big names are present, but it also offers an avenue for smaller companies to participate in influential activities.
This is also part of product managers’ work. Have you found the relevant channels to influence your industry going forward?
I hope you enjoyed the article and perhaps got some hints! Now we have covered two ABC’s – Always Be Competitive and Compliant.
Until the next ABC – Always Be … Curious 
