Quality Management System: Are You Doing It Right?

During one of my assignments with EPMA I facilitated a client’s efforts in planning the testing activities that led to the qualification of a prototype. This was part of their product development process in the scope of a complex project, for which I was providing my project management services. In one of these planning sessions, I witnessed a discussion that could have been potentially catastrophic for my project. That potential catastrophe is the perfect example for showcasing what, in my experience, a Quality Management System (QMS) should and should not be.

The Background:

The engineer in charge of leading product tests was under pressure to deliver on time, despite a lack of technicians to support him as those resources were tied up supporting on-going production (always a priority in any organization, as that is a source of revenue) and there was no budget to bring more on board.

Part of the client’s process to release product to market was to hold meetings with stakeholders from management, operations, engineering, quality, and subject matter expert advisers. In these sessions, manufacturing documentation (operating procedures, work instructions, photos of the actual product going through each of these) and test results were reviewed. As you can imagine, the process of compiling this information and formatting it into a report is time-consuming. The review is also lengthy since the stakeholders give feedback from their functional perspectives and discuss their concerns and potential risks before reaching an agreement on a decision. In a perfect world, this would be fine. However, as you know, we were running against the clock.

To remedy this, the engineer proposed having a preliminary review after the tests were completed – an option acknowledged in the client’s quality management system – thus perfectly within compliance. The philosophy being that since the product went through the testing successfully, an evaluation can be made without the exhaustive documentation and the product can be released to market while acknowledging and evaluating the risks implied. The documentation process can then be completed as production is on-going.

The Conflict:

When the scientist in charge of evaluating the test results reviewed the plan, she expressed concern about proceeding with the preliminary review and proposed going with the recommended procedure of performing a full review. A completely valid stance, since a full review minimizes the risk of quality claims and returns.

The Resolution:

Which position would you take? Would you go with the riskier decision of launching the product to market on time and start generating revenue? Would you take a 3-month delay and minimize all risks?

As anti-climactic as this might be, I’ll let you consider both options and write your own ending(s).

The moral of the story is that the Quality Management System allowed the flexibility to have options. Management could then weigh and base a decision off these options. In the end, the route taken should be one that looks out for the customer’s interest, while not driving the business to failure.

So now that we’ve seen what a functional QMS should be like, let’s look at what a QMS should not be. Keep in mind that as bulletproof as you might think your QMS is, it will never reach perfection. In fact, it’s healthy to find opportunities of improvement as that reflects a thriving organization.

A QMS should not be restraining – As in, not having so much red tape and required documentation that solving a simple problem becomes a considerable effort involving multiple resources. If you encounter a process that seems unnecessarily complex and you raise the question “why is this done this way” and the answer to that question is “because that’s how it’s always been done”, chances are that there is at least one simpler way of achieving the same goal. Determine what that simpler approach is, document it, and submit it as a corrective action to your QMS. Your organization will benefit from it.

A QMS should not dictate how business is done – The QMS is a portrait of the business, not the other way around. The QMS should be shaped in a way that captures the general flow of the operation which it supports while establishing guidelines and checkpoints to ensure that the end product (whether a good or a service) will be consistent when it reaches the customer (whether internal or external), so it’s not just about the bottom line but about ensuring that, from beginning to end, your process is safe, repeatable, and compliant.

A QMS should not be set in stone – While they should not leave anything up to interpretation, quality management systems must be adaptable to changes in business trends and operations. The goal of having non-conformity reports, preventive and corrective actions is to allow the QMS to mature and describe how a business operates. Via a QMS, new-comers to an organization can become familiar with established processes and procedures and seasoned contributors can refresh their own memory on them, as needed.

In short, your QMS should flow with your organization and its culture. If you feel that your operations and your QMS are at constant battle against each other, consider changes to your process (including the QMS), people (starting with training and functional shifting), or technology (updating or upgrading current tools, adopting new ones).

For everything else Project and Portfolio Management, browse our full blog at blog.epmainc.com!

For more information on how we can help you and your project management team, send us an email

If you are looking to kick start your project management journey, sign up for our Microsoft Training Classes. We hope you find this blog post helpful.  For more tips and tricks on Project Management, follow us on LinkedIn and Instagram