Part 2 – A Quality System is Not Enough

About twenty years ago the FDA re-wrote 21 CFR Part 820, the “Quality System Regulation” (QSR), to require that manufacturers institute and maintain quality systems.  This re-write included the critical element of design controls.  Even before that re-write of Part 820, the practices around design controls were embodied in ISO standards.  Nevertheless, it is still common for design and manufacturing organizations to re-tool their quality systems because of product quality issues – and those organizations pay a significant amount for help to create or completely re-write their quality system, often on an urgent or emergent basis.  These revisions frequently focus on design control practices.  An extensive market exists around this need – and several of the authors have been part of this market for quite some time.

Yet, issues with product quality persist: companies continue to pay the prices associated with poor quality, or they succumb to market and regulatory pressures and do not survive.  Clearly there is room for improvement in practices that actually lead to high-quality product.

The authors believe that, to understand how this situation can be changed, it is important that we first understand what quality systems are and where they came from.

It is common and tempting to view a quality system on a point-by-point basis.  We pull out one of the little books that list the regulations (21 CFR 210/211, 21 CFR 820, 21 CFR 11, etc.), and shuffle the pages to Section XXX.YYY.  We read one sentence and ask “are we satisfying that requirement?”  Worse, we go Section XXX.YYY, read it, and say “this does not say I have to do ‘activity Z’ (i.e. some other activity) … so I won’t do it.”  Come on, admit it … many of you have been part of those or similar discussions.  This is a misleading “forest for the trees” approach to creation, management, and use of quality systems.  When we focus on the minutiae of specific phrases, and debate fine points in the statements’ meaning, we lose sight of the objective of those statements.  Worse, we don’t clearly envision from the beginning what the quality system is trying to accomplish.  In addition, we lose sight of the fact that the QSR regulations are minimum requirements – and in so doing we don’t achieve the desired goal of the quality systems.

So, what are “quality systems?”  Where did they come from?  Information about this exists in many practices that surround us: Project Management, Six Sigma, Design for Six Sigma, and Systems Engineering.  All of these disciplines embody world-wide, accepted best practices. Yet, they are often regarded as disparate systems and, unfortunately, are often thought to conflict with each other in execution.  In reality, these practices share many common elements.

At the beginning of any product design effort, Project Management, Six Sigma, Systems Engineering, and 21 CFR Part 820 all call on you to do the same things: figure out what the customers need; define the disease the product is intended to treat or cure; identify what the customers will buy; and then carefully and clearly define the specific set of needs you choose to address in your product.  And – importantly – do so before you actually design the product so you are not justifying your design after the fact.

Specifically, Project Management calls for: identification of stakeholders, collection of project requirements, and definition of project scope (PMBOK[1] , 5th ed.).  Six Sigma calls for: identification of the customer, seeking input from the customer, documentation of Customer Needs, and setting of Specifications.   Systems Engineering calls for: identification of Stakeholders and definition of Stakeholder Requirements.  Here is what the CFR says about this: “Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient” (21 CFR 820.30(c)).

All of these disciplines are saying the same thing.

The next step in the product development process is to determine how the pieces of the project (or device) fit together and to identify which “pieces” are most important.  In this development step, all the disciplines identified above are once again calling for the same actions – namely, to define the product with traceability of the functions of its subsystems to the higher-level needs of the stakeholders (to make sure the design covers the intended functions of the product).  We also are called to assure all requirements have been met.

Specifically, Project Management says: create Work Breakdown Structure (i.e. the work that represents the pieces of the project or product) that achieves the requirements, and Sequence the Activities.  Design for Six Sigma says: develop a high level design, identify the Critical to Quality output, drive to a detailed design (i.e. components and subsystems).  Six Sigma also calls for: identification of Critical to Quality output.  Systems Engineering says: Architect the system, its sub-systems, the interfaces between them and trace the design outputs to the inputs.  The CFR says: “Each manufacturer shall establish and maintain procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements” (21 CFR 820.30(d)).

Our next example is the design verification/validation step of the product development process.  Here, we once again see that the disciplines we have identified above are calling for the same activity.  Specifically, Project Management calls for: documentation and traceability of requirements, followed by validation of deliverables against those requirements.  Design for Six Sigma explicitly calls to: Analyze and Verify the design (in the DMADV[2] process).  Systems Engineering calls for: Verification and Validation of a system based on established and traced requirements.  The CFR says: “Each manufacturer shall establish and maintain procedures for verifying the device design.  Design verification shall confirm that the design output meets the design input requirements.” (21 CFR 820.30(f)).  Similar language is used in Part 820 around the need for Validation.   Project Management does not draw quite as clear a distinction between verification and validation … but it does try.  It puts the onus for validation on the customer, and for verification on the project team).

Without going in to detail, the parallels continue in: the practice of identifying, supporting (i.e. funding), and training a team (21 CFR 820.25 Personnel); the practice of identifying, selecting, and managing vendors (21 CFR 820.50 Purchasing Controls); the practice of monitoring and controlling designs and processes (21 CFR 820.70); and the practice of controlling changes to product or processes (21 CFR 820.30(i).  All of these regulatory “requirements”, and more, have parallels in world-wide accepted best practices.  In most cases the regulatory agencies likely did not create these “requirements” out of thin air: The requirements were most likely drawn directly from these accepted best practices.

There are four points to take away from this.  The first point is that these seemingly disparate practices … are not so disparate after all.  They are trying to accomplish the same objective.  The second point is that the conflict or suspicion that often exists between people performing these practices in the workplace is senseless, because these practices are trying to accomplish the same goals.  The third point is that we cannot “cherry pick” the facets of each of these best practices to suit our preferences – doing so ignores the balances inherent in each of the practices, and gives rise to the conflicts that people practicing them frequently experience.  The fourth point is that to succeed in producing high-quality product we need a holistic understanding of what these practices are trying to accomplish.  We need to see the “forest” and not focus on the individual “trees.”

So what is the objective of these practices … what is the “forest?”  The answer is quite simple, actually.  The goal of these practices is to:

  • concisely define and design products that clearly meet the needs of customers/stakeholders at an acceptable level
  • to manufacture and distribute those products in a state that continues to meet the needs of the stakeholders at an acceptable level
  • to do both of the above in a predictable and reproducible manner

The regulatory expectations only add one thing:

  • provide reasonable evidence that you are doing the first three things.

In other words, demonstrate that you built the product you said you were going to.

The Good Manufacturing Practices (cGMP’s), which are often considered separately, are focused on achieving the “predictably and repeatably” goal.

We get into trouble executing to a “quality system” because we tend to focus so much on meeting the letter of each statement in the regulations that we lose track of the regulations’ context and intent.  In the vignette in the first article in this series, we relate in lines 9 – 12 that the quality system has been developed to meet the contents of the regulations, and the development team is trained to adhere strictly to its procedures.  The problem with this approach, which is commonly taken, is that our “quality system” in practice becomes a “compliance system.”  We do what the system “says,” and often nothing more – despite the fact that the regulatory agencies clearly state that the regulations represent a minimum amount of rigor.  We ignore (or, as in lines 11-12 of the vignette, are not allowed to act on) what makes scientific sense or is otherwise defensible based on the specific needs of the current activities; but this is exactly counter to the intent of the regulations.  In the end we lose track of and do not execute the very activities and evaluations that produce high-quality product.  Instead, we create waste and frustration.

We need to recognize and embrace the understanding that a few regulatory statements cannot capture all the meaning and fine points of the rich collection of practices contained in the engineering and project management bodies of knowledge.  It is therefore not wise to assign responsibility for high product quality to the relatively few statements in regulations, or to a single function within an organization.  If instead, as much as possible throughout the organization, we really understand and execute what these best practices recommend, improved product quality will naturally follow, as will regulatory compliance.

It is likewise critical that each one of the individuals practicing in the areas mentioned above do not “cherry pick” their focus.  One of the most useful concepts coming out of Project Management is the “Triple Constraint” or “Project Management Triangle.”  This states that any project is constrained by time, cost, and scope – and that quality results from an appropriate balance between these constraints.  This is a truism.  Wishful thinking or demands on the development team can not change this interdependence.  Therefore, to achieve high product quality, Project Management cannot ignore the need to clearly define and manage Scope in favor of cost and schedule.  Likewise, Systems Engineering and Design for Six Sigma cannot ignore the demands of budget and schedule in favor of their work on scope (i.e. requirements definition and system design).  To be selective in executing within each discipline is to neglect the very internal teachings of each of those disciplines.

So, the solution to our problem lies at least partially in the following: the question of how to achieve high-product quality needs to be changed from “how can we change our quality system” to: “how can we effectively and flexibly execute within and around the framework of our quality system.”  These are two very, very, different statements.  The former requires that we open a small book and start discussing fine points of meaning of individual phrases.  The latter requires that we learn and institutionalize, within our organizations, the rich bodies of knowledge contained in the practices of Project Management, Systems Engineering, and Design for Six Sigma.

© 2016 DPMInsight, LLC all right reserved.

About the Authors:

Cushing Hamlen

Over 27 years of experience in industry, including 20 years with Medtronic, where he worked and consulted with many organizational functions, including research, systems engineering, product design, process design, manufacturing, and vendor management.  He has also worked with development, regulatory submission, and clinical trials of combination products using the pharma (IND) regulatory pathway.  He has been extensively involved with quality system (FDA and ISO) use and design, and is particularly concerned about effective understanding and use of product requirements and design controls.  He has formally taught elements of systems engineering, design for six sigma, Lean, and six sigma.  Cushing has degrees in chemistry and chemical engineering, is certified as a Project Management Professional, is certified as a Master Black Belt in Lean Sigma, and is the owner/member of DPMInsight, LLC (www.dpmillc.com).

Bob Parsons

Over 26 years of experience in leading Quality Assurance, Validation and remediation efforts in FDA regulated Medical Device and Pharmaceutical industry. Experience includes product development life cycle management from initial VOC through New Product Introductions (NPI), sustainable manufacturing, and end of life product management.  Technical expertise in quality system gap assessment, system enhancement, alignment and implementation of all quality elements including design controls, risk management, purchasing controls, change control and post-market surveillance.  Regulatory experience includes; ISO 13485, 9001 and 14971 certification, providing guidance for FDA PMA/510K and CE clearance, designated Management Representative, company representative and lead during FDA and ISO audits, 483 and warning letter resolution with experience working within consent-decree environments.  Bob currently supports various organizations in remediation and compliance projects through Raland Compliance Partners (RCP) www.raland.com .

 

Michael B. Falkow

Michael Falkow is a Quality Specialist with Raland Compliance Partners. He has served as a regulatory compliance and quality assurance executive with multi-facility/international companies and was an FDA Compliance Officer and Senior Investigator/Drug Specialist.  Michael has subject matter expertise for quality and regulatory compliance, quality auditing, quality assurance, quality control, supplier evaluation and certification, and compliance remediation.  He has been approved by FDA as a GMP certifying authority and is qualified to provide Expert Witness testimony for GMPs.

Currently – Adjunct Professor at Mercer County Community College – teaching courses on Clinical Development for Certificate Program in Clinical Research as part of Drexel University’s Masters Degree in Clinical Development.

 

[1] A Guide to the Project Management Body of Knowledge (PMBOK Guide), fifth edition, Project Management Institute, 2013.

[2] DMADV: “Define, Measure, Analyze, Design, Verify”

One thought on “Part 2 – A Quality System is Not Enough”

  1. All very good points. The ISO 9001:2015 standard states as part of its scope of the standard that it is for organizations that “aims to enhance customer satisfaction through the effective application of the system, including process for improvement of the system and the assurance of conformity to customer and applicable statutory and regulatory requirements.” As you have noted, people hide behind just fulfilling these minimal requirements and forget about the enhancing customer satisfaction, improving the processes and conforming to requirements. A quality system is not a once and done. It should be a living entity that is improving beyond the minimum. Those that are implementing a quality system just for the certificate or plaque is not getting a good ROI on their investment.

Leave a Reply

Your email address will not be published. Required fields are marked *