Does a QMS have to be static or can it be agile as well, is it worthwhile the effort going for it ?

The QA department is like a zombie island. We all know about it, but we don’t want to go there. They seem to be living on dead paperwork. They have a thing called a QMS. It comes with rules and procedures, which never truly reflects the real way of working, but it’s just too much effort to change them…

Sounds familiar? Not how it should be, but unfortunately true for quite a lot of companies.

But does it have to be that way?

Is there no way to move your QMS from being this solid, static, non-flexible thing that only a few people know how to operate in, to a flexible, adaptable tool that actually helps the company to function in a better, more harmonized way?

In short, can a QMS be Agile?

First of all, let’s set the baseline on what we understand by Agile. For all you software developers out there, you know what we mean. For those who are less familiar, here it is in super simple language.

Agile is a way of working where you break up the big task into smaller pieces. This allows you to create, evaluate, release and improve faster. You don’t deliver everything at once. You work in bits, prioritize and add value over time. And yes, you can change your plans at any time as this way of working allows you to incorporate changes fast.

So let’s do the exercise. Is it possible to work in this way and still have a QMS that is compliant with standards like ISO 13485?

If you look at a distance to what is expected of a QMS, everything needs to be done according to the Plan-Do-Check-Act principle and needs to be controlled.

Isn’t that what we just explained for Agile?

You look at the big picture and break it up into smaller, comprehensible tasks which can be tackled separately but in parallel. That requires planning and understanding.

 Instead of having monster procedures covering a lot of different processes and their corresponding forms, templates and so on, you could try to break this up into smaller pieces, for example: different processes, different work instructions, different forms, different templates.

Each of them could be reviewed and released individually, right? Yes, they could. As long as you have good traceability between all of these different items in place. A decent version control makes sure that you keep track of which version has been released and which one is still in draft.

So it’s possible to break up big procedures into smaller pieces which do allow faster review.

Another advantage of having smaller items in your QMS focusing on one specific process or one specific template is that it’s easier to trace the information one needs and to implement that information. Even training on a specific process all of a sudden becomes less complex.

Not to mention audits and CAPAs. Audits could become much leaner and faster if they focus on more specific processes. Same as for follow-up actions coming from those audits or any other input that would require a CAPA.

Another principle of the agile method is that people take accountability for their activities and tasks. Translating this to an agile QMS, the QMS belongs to the company and should be part of everyone’s daily way of working without any special effort. This is perhaps the most challenging part of converting a static QMS to a dynamic, agile QMS.

Looking at requirements from ISO 13485, it actually says everyone needs to know their responsibility and authority, but it’s not only in terms of authorizations within the organization, it’s also about responsibility and authority within the QMS and the described processes.

Who is responsible for implementing a certain process? Who is impacted by certain processes? Who can change templates? Who needs to use them?

This requires that all information, both content and also responsibilities and impact, need to be easily accessible and searchable by everyone. In this way, you avoid people having to dig through a pile of procedures, only to find that the information that they are looking for is not there. Having both the responsibility for a process clearly defined, as well as who is impacted by this process, makes it easier for people to take ownership and contribute to making sure the QMS is reflecting the real way of working in the company while keeping an eye on compliance.

How about fast approval to allow changes more easily? It’s a must if you want people to take ownership, actively make use of the system and contribute to it.

It’s not always easy to get documents approved. If you want to have an agile QMS, you have to find a way to have a smooth review and approval routing process. The most convenient way to do this will depend on your organizational structure. However, not depending on papers that have to travel from one desk to another or even worse be scanned, printed, signed, scanned and emailed, will help already a great deal.

And last, but not least, what with all the paperwork? Isn’t that contradicting the principles of agile methods? Not to mention killing forests and filling landfills with excess paper!

Documentation for the sake of documentation is indeed not the way to go. But that’s not required for an effective QMS. On the contrary, you need to document certain things to be able to plan, to check, to act and to make further plans. When you keep documentation and records as simple as possible, without losing the necessary content, it serves its purpose. Some adaptations might be needed when you want your QMS to be more dynamic. Again, it’s worthwhile investigating the best tools to help you with this.

A QMS can be agile. Our QMS is agile! Our QMS provides the proper mindset and the correct set of tools to suit your organization. Once you convert from a static system to a dynamic one, you will discover that QMS is not holding your company back, but helps push it forward.