Can't we just all get along?

Why is it that anytime a project is underway that it seems as if quality is an afterthought? Why are Regulatory and Quality (R&Q) Engineers typically considered to only support the deliverables at the end of a projects launch? How can this be when they are working our tails off throughout the process? Is it that they’re the project team ninja, operating in the shadows outside the view of the surrounding team members?

This is something that R&Q engineers face in the research and development world. They have to fight the good fight by showing research and development teams their value. They need to show that the research and development (R&D) teams will be rewarded by spending time involving R&Q engineers instead of just spending countless hours and resources making iteration after iteration of their latest and greatest widget. How is a R&Q engineer to convey to teams they should be welcomed into research and design decisions? Why aren’t they in the first place? Is it a trust issue? Are R&Q engineers inherently difficult to work with? Is it possible that R&D teams find R&Q engineers’ incompetent?!?!?

To be able to fight the good fight R&Q engineers need to understand the root of the problem. When investigating they will likely find the problem to be related to communication. Poor communication or miscommunication can flat out stop the best products from being released to the market.

R&Q engineers need to take it upon themselves to break down the “Berlin Wall” between themselves and the R&D team leaders. R&D leaders oftentimes are fearful of involving R&Q since the stigma exists that R&Q are the “no-men” of the project teams and that they squash creativity and flexibility within the living project development process. This needs to be eliminated. This feeling cannot be felt by the project teammates. R&Q teammates can squash this by simply showing the value associated by involving them early on in the process. This isn’t meant to imply that R&D project managers or leaders aren’t qualified to be making project decisions, it’s meant to show that the decisions cannot be made in a vacuum otherwise repercussions could transpire. R&Q engineers cannot make the assumption that R&D leadership is as familiar with the Quality Management System requirements or Regulatory Requirements that a project is to live by. This is what R&Q engineers do, to know the regulations and determine how they can be interpreted to fit the needs of the business and/or project teams.

After breaking down the divide between R&D leaders and R&Q teammates communication pitfalls present in a project team can be addressed at the engineering level. At the engineering level many of the R&D engineers never realize the domino effect associated with the design decisions that are made. R&D teammates need to understand that a “Code Red” event can occur if design changes occur post-510(k) submissions or post-V&V activities for instance. For the R&Q engineer the alert would be sounding and preparations for how to handle the design changes are being prepared. To avoid the “Code Red” R&Q needs to share with engineering options associated with each project decision or milestone. The responsible R&Q engineer will avoid additional testing, redesigns or even a revised 510(k) filing. By showing R&D that R&Q engineers have more to offer a team than Design V&V reports, Risk Reports or Technical files the R&D team can finally understand the true value in using R&Q as a confidant during the entire process.

All it takes for an R&Q team member to change the culture at an organization is to show one team the “light”. After assisting one design team, another design team will undoubtedly catch wind and want to reap the same rewards. Why shouldn’t they? Project teams more than ever need to reach the market faster, with innovative products that meet the safety and performance requirements demanded by the users.

- MJB