Understanding Section 4.4

The Quality Management System and its Processes

This is an education article on Section 4.4 of ISO 9001, entitled “The QMS and its processes”.

The purpose of this article is to give you an understanding what Section 4.4 requires.

The article is directed towards:

• Those responsible for establishing section 4.4 compliance.
• Those responsible for process or project management.
• Other parties interested in understanding the process management requirements of section 4.4.

Section 4.4 is entitled “Quality management system and its processes” and it starts out be requiring you to:

• Establish,
• Implement,
• Maintain, and
• Continually improve

your QMS, including its processes and interactions.

That you need to establish, implement, maintain, and continually improve your QMS almost goes without saying, but what makes up a QMS if not its processes and interactions. The remainder of section 4.4 focuses on those last words “its processes and interactions” and so will we in this training.

This training is divided into two sections corresponding to the two main requirements of section 4.4:

• Determining what processes need to be documented.
• Determining how best to define and document these processes and their interactions.

Let’s start with the first section of our training — determining the processes needed to support the QMS.

Some processes are required by the standard, some are elective based on your needs in light of the circumstances.

Here is a broad look at the processes that will make up your QMS.

Each process or activity here reflects some requirement of ISO 9001. Additional processes may be necessary for your company. Of these processes listed here, only some of these processes are required to actually be documented, some are not. As for those that are required to be documented, you of course may exceed the documentation required by the standard, depending on your internal needs and requirements. As for the ones that are not required to be documented, you have a choice to document or not based on your company’s internal needs and requirements.

You may already have written procedures that would cover many, if not all, of these processes, or you may not have any procedures at all.

Before comparing yourself to the standard though, I recommend that you first make an independent determination of what you think should be documented, from a top management or high-level perspective, based on internal and external issues, risks, and stakeholder requirements, etc.

Why do I recommend this? First, the QMS will be more organic if it is designed from the mindset of quality and improvement for your organization’s sake, and not for ISO’s sake. Start here. When organizations start with ISO in mind, they may default to some of the common ISO solutions, which may not have been what the organization had done if they had been thinking more of their own needs and style. You may be surprised to learn that your custom solutions, designed without ISO in mind, will meet the ISO standard better than solutions designed with ISO in mind — but that is my experience. Why is this the case? Because the solutions are designed with more of a value-added results mindset, than a meet the requirements mindset, and with the creativity of a mind unimpeded by ISO tradition and convention.

Another reason to determine internal requirements first, is because the standard encourages it. The standard requires you to document whatever is implicitly necessary to 1) “support the operation of its processes, and 2) have confidence that the processes are being carried out as planned.” In other words, what do you think is necessary? If you think it is necessary, then document it, regardless of whether ISO requires it.

So, how do you determine what processes should be documented, outside of the requirements of ISO 9001?

When determining what processes to document, you should consider:

• Your strategic priorities and quality objectives.
• Your stakeholder requirements, including employee requirements and customer requirements.
• Your risk areas and opportunity areas.
• The competence level of your employees.
• Your performance history, including any product or service issues or process issues that need to be resolved.
• Areas of stability and change in your company.
• Customer complaints.
• Internal suggestions for improvement.
• And more.

Organizations tend to stress about choosing what to document, so let me give you some tips.

Certain processes present a high risk to quality if they are not documented. This is because the desired outcome is less likely to occur if the process is not well-defined and documented. Such processes usually require a moderate to high degree of clarity, mutual understanding between relevant parties, precise communication between relevant parties, predictable behavior, enforcement mechanisms, performance control mechanisms, or other things that are difficult to achieve without specific definitions in written documentation.

Also ask yourself “What is the likelihood of process failure and what impact would that have on quality?” Would it be significant? What could be done to minimize that significant risk? If documenting it would reduce a significant risk, document it.

And, if you are still struggling with questions of what to document, you can ask an unbiased third party, such as your consultant, for their opinion.

For some processes you may question the benefit of documentation. If documentation is not required, by ISO or top management, and there is a split in opinion, or lack of buy-in on the value of documenting the process, then consider this: Do not document the process for now, but monitor process performance, and if any problems arise, and the cause appears to be lack of documentation, then take corrective action and document it. That is why ISO 9001 requires monitoring, measurement and evaluation, and a corrective action system, so that initially unperceived value can be identified and acted upon when the need becomes apparent.

Some processes by their nature will differ greatly in their activities from case to case, such as processes used to manage projects. Every project may have its own unique set of requirements, operations, quality controls, and records, making it difficult to standardize many aspects of the work. Such processes usually require highly competent personnel to manage them and ensure a quality outcome despite the unexpected nuances of every case. Such a situation may change the way quality processes are established, implemented, maintained, and improved upon, but the need for, and purpose of, the processes stays the same. ISO 9001 will require the same processes and controls for a project as its does for a standard operation.

For your information, ISO has published a guidance standard, ISO 10006, entitled “Guidelines for quality management in projects.” It provides many insights into how ISO views quality in project management, and I highly recommend reviewing this standard if you engage in any project management.

Also, I address project management, ISO 9001, and ISO 10006 in another article. If you engage in project management, you should read this article.

So, with respect to your documentation, may I recommend this sequence. First, identify your internal requirements for documentation. Once you know what processes you want to document from the internal perspective, in light of your overall context, only then concern yourself with what documentation ISO 9001 requires. I think you will be surprised at the results, and you will more easily see the reasonableness of the standard.

Now on to the second section of this training. You are required to determine not only what processes to document, but how best to define your processes and their interactions.

So how do you define and document your processes in a way that meets the requirements of Section 4.4?

Section 4.4 provides a list of requirements for how to define your processes.

• Determine the inputs and outputs of the processes. (Sections 8.3, 9.3; these are often defined in a procedure document)
• Determine the sequence and interaction of these processes. (these are often defined in a systems-level diagram)
• Determine the criteria and methods needed to control these processes. (Sections 8.1, 8.3.5, 8.4.1, 8.5.1, 8.6, 9.1; these are often defined in a procedure document, or sometimes documented in a separate document such as a metrics and evaluation table of some kind.)
• Determine the resources needed for these processes. (Section 7.1; these are often defined in a procedure document)
• Assign the responsibilities and authorities for these processes. (Section 5.3; these are also often defined in a procedure document)
• Address the risks and opportunities associated with these processes. (Section 6.1; these are less often defined in a procedure document, but often reflected in the controls for the procedure, and often defined in a separate document such as a risk register, or as part of a risk assessment)
• Evaluate these processes and implement any changes needed to ensure that these processes achieve their intended results. (Sections 6.1, 6.2, 7.2, 7.5, 8.3.4, 9.1, 9.2, 9.3, 10.2; this is often defined as part of a process control procedure specifying how processes will be managed and evaluation and/or a document control procedure, requiring regular reviews and updates to processes and their documents)
• Improve the processes and the quality management system. (Sections 5.1, 5.2, 5.3, 6.1, 7.1.1, 9.1, 9.3, 10; this is often integrated into the corrective action system, or improvement system, or a regular management review system)

Ultimately, you will decide when, how and where you will be defining the above information. As already discussed, you may do so through a procedure, through established policies, through charts, diagrams, registers, tables, or any combination of these. You get to decide your processes and their interactions.

Here is an implementation tip. Section 7.5, document control, overlaps a bit with this section, section 4.4. Section 7.5 requirements will probably impact how you choose to define your processes, including, for example, what your procedure templates will look like and what information they should contain. So consider watching the training and implementation videos on section 7.5 in conjunction with section 4.4.

For more information on when, how and where to define processes and their interactions, watch our implementation videos for section 4.4, and review our many document templates for some examples.