The Abominable Quality Manual, Part Two

How to write an ISO- or API-compliant quality manual

Published: Thursday, April 10, 2014 - 12:54

In part one of this series I described how many auditors want your quality manual to repeat what is in ISO 9001, API Spec Q1, or API Spec Q2. Since auditors don’t always make the connection between how you wrote the quality manual (in a way that’s useful for you) and the standards in question, your choice is either to go to battle with them or learn how to build the perfect quality manual that will appease them. By that, I mean a quality manual that meets the requirements of the relevant standards and the auditors who interpret them, yet still provides value to your company and its employees.

The bad news is this won’t be a one-page quality manual. That is just not an “accepted” practice, so unless you’re ready to put up a fight with Mr. Auditor, don’t bother going down that road. The good news is that the quality manual I present here will get you closer to being perfect during an audit, rather than just being efficient. At our firm, we coach our clients to aim for zero nonconformities during their stage 2 audits, so this manual is as good as it gets in the quality manual world.

The steps I follow to build a useful, thorough quality manual that meets the requirements of ISO 9001, API Spec Q1 9th Edition, and API Spec Q2 from the American Petroleum Institute are as follows:
1. Talk about your organization
2. Define your scope
3. Create your process map
4. Develop your procedures
5. Fill in the content of the quality manual
6. Review and approve

I will present a summary of each step below.

Talk about your organization

The first section of your quality manual should tell me a bit about your organization. Whether I’m a new employee, a customer, or Mr. Auditor, I want to know about your company: When it was founded or established, what the products and services are, and details about the locations. The best way to begin a quality manual is to introduce your own organization, so reserve the first section for highlighting your company.

Define your scope

Section two of the quality manual should consist of the scope and exclusions for your quality management system (QMS), both of which are requirements of ISO 9001 as well as API Spec Q1 and API Spec Q2:

Of course, I recommend that before you even embark on getting your organization certified, you must define your scope so you know exactly which areas of your organization will be part of your QMS. A good scope describes what products or services the company provides and may include limitations, such as the locations where the organization operates or the industries it serves.

Examples of good scopes, both without exclusions, are below:
• The design and execution of drilling and workover applications, using air, mist, foam, aerated fluid, and other underbalanced drilling techniques, for the petroleum, gas, and geothermal industries.
• The provision of engineering solutions and adaptive fluid power systems for the industrial, marine, and offshore Industries.

Here’s an excerpt from our own quality manual, to show you a nice way to display it:

Click here for larger image.

Although the scope is one of the first things you do, it will more than likely be revised, refined, and polished a few times before certification. By the time you get ready to create a quality manual, you should have a well-thought-out and well-written scope.

One last thing on scope: The scopes I present here have been accepted by either ISO or API auditors. Here’s an example of a bad scope that, unfortunately, I have seen:

“The scope of this manual is to specify the requirements for this quality management system where our organization will demonstrate its ability to provide product that meets customers and applicable statutory and regulatory requirements; and to enhance customer satisfaction through the effective application of the system.”

When it comes to scope, you don’t want to regurgitate the ISO or API standard.

Create your process map

Section three of your quality manual should include a description of your processes and their interactions. If you read my article, “Do You Feel Like Your Company Is Acting Like a Chicken Without a Head?” you may know my strong belief that adopting the process approach is key to a good management system. In fact, I often compare a company’s main process map to the blueprint for a building’s foundation: Without a good plan, no matter how fancy the house, it will eventually crumble.

A good process map should exhibit the following traits:
• It’s readable. If your process map has arrows going in every direction, or looks like a hieroglyphic, then you still have some work to do.
• Users easily recognize inputs and desired outputs. This will help to show what the right direction of the activities are.
• It distinguishes core vs. support processes. This is critical because we know that core processes are what make the company money.

Other pointers I recommend are:

• Separate product realization (what I call core processes) from support processes. For example, document control is a process that’s embedded everywhere in your organization; you should put it on the support processes area rather than trying to add it in multiple places in your product realization or core processes. If you try to embed your support processes within your core processes, you start making your process map muddy.

• Add the procedure numbers to your processes if there is a one-to-one correlation. This makes for a crystal-clear representation of your QMS documentation, which all your employees will surely appreciate and want to use.

Here’s an excerpt from our quality manual to show you a good way to display your process map:

Click here for larger image

One last thing on process maps: The process map I present here has gone through various audits and has been deemed acceptable. Here’s an example of a bad process map that I still see:

This is just ISO’s representation of the plan-do-check-act (PDCA) cycle and shouldn’t be used as your own process map. As with other elements of a quality manual, you don’t want to regurgitate the ISO or API standards when creating your process map.

Develop all your procedures

You have to develop all your procedures before you even think of drafting your quality manual. I often go to clients who want to get certified, and they tell me they already have a quality manual, yet they don’t have procedures or know what their processes are. You can’t build your manual unless you have created all your procedures. That is a fact, and anyone who tells you differently is helping you make a bogus quality manual.

It’s important to understand that some auditors will interpret the requirements of API or ISO as “all your procedures must be referenced in the quality manual,” while others are content to know that you have referenced the “applicable” procedures. Again, because we aim for zero nonconformities during the stage 2 audit, we highly recommend that you reference all of them. Therefore, if you have a gazillion procedures, this is a good time to bring out the good old “document pyramid scheme” and separate your procedures from your work instructions, and perhaps even manuals or policies. You want to have a manageable number of procedures that truly answers the requirements of the ISO or API standards and that fits into your quality manual.

Fill in the content of the quality manual

Now comes the best part: filling in the meat of your quality manual. Think of the standard as if it were a list of questions, and you must answer them by stating what procedure you use to accomplish each of the requirements.

Here are a few excerpts from various sections of ISO 9001, API Spec Q1 9th Edition, and API Spec Q2, along with examples of how a company’s procedures are shown to support those sections.

(ISO 9001:2008) 4.2.3 Control of Documents
Example: Documents associated with the QMS are controlled and approved prior to issue according to the Control of Documents procedure MXP-ADM-001.

(API Spec Q2) 4.4.2 Control of Documents
Example: ACME Offshore Services has established a Control of Documents procedure SOP-001, for the identification, distribution, and control of documents required by the quality management system and by API Specification Q2, including required documents of an origin external to ACME.

(ISO 9001:2008) 7.4.1 Purchasing Process
Example: In order to ensure that its purchased products and services meet specified requirements, Mireaux Management Solutions selects and monitors its suppliers based on criteria described in the Supply Chain Procedure MXP-ADM-007.

(API Spec Q2) 5.6.1 Purchasing Control
Example: ACME Offshore Services ensures that purchased or outsourced services and service-related products conform to specified requirements. This is done through the Supply Chain Procedure SOP-006.

(API Spec Q1 9th Edition) 5.6.1.1 Purchasing Control Procedure
Example: ACME Manufacturing maintains a documented procedure to ensure that purchased products or outsourced activities conform to specified requirements. This is done through the New Critical and Noncritical Vendor Evaluation Procedure SOP-007 and the Critical and Noncritical Vendor Reevaluation Procedure SOP-008.

(API Spec Q1 9th Edition) 5.3 Risk Assessment and Management
Example: ACME Manufacturing maintains a Risk Assessment Procedure, SOP-015, to control risks associated with impact on delivery and quality of product. The risk assessment procedure provides a technique for conducting risk assessment regarding product delivery and product quality.

Although these are just a few excerpts and examples, you want to apply the same approach to every one of the clauses throughout the standard or specifications. And, by the way, follow the sections of the standard or specifications in your own quality manual. That is, create as many sections as the standard or spec has. So if you started with section 4, you should continue with section 5, 6, and so on, until you have covered all the sections of the standard or spec.

A word of advice about ISO 9001 and API Spec Q1 or Spec Q2: You have more leeway in ISO 9001 to deviate from the actual words of the standard. For API Spec Q1 9th Edition and API Spec Q2, however, I recommend you stick to the requirements, because you will later have to complete the specification’s conformity matrix. If you deviate too much from the requirements, you will find yourself a rebel with a lost cause when filling out the conformity matrix, and you’ll realize that you should have stuck to the script in the first place.

Think of Jeopardy, where you see the question as a statement, and you have to state the answer as a question. The only difference is that in a quality manual, you put the two together as a final statement.

A final word on the quality manual: If you simply repeat the standard or spec without inserting a reference to your own procedures, you have pretty much missed the point. You must make references to your procedures, or you will end up with a useless quality manual.

Review and approve

Once you have completed the quality manual, including all the sections shown in this article, the next step is to gather your top management and review it. If you are the QMS coordinator, management representative, consultant, or quality manager, make sure the other members of management, such as the quality director, VP of operations or quality, or whoever is part of the top management, is available to review the manual.

During the review, go over the entire quality manual, line by line, point by point, ensuring that your audience understands what is required and how the requirement is being met. This will help everyone link the quality manual with the actual procedures and acknowledge their importance. If you do this, and if you have involved your team during the development of procedures and managed them through a system approach, you will not only succeed, but I guarantee that you will empower your team to make a difference with your QMS.

Are we there yet?

If you follow these steps, I know your quality manual will comply with the requirements of ISO 9001, API Specification Q1 9th Edition, and API Specification Q2, and will look pretty enough that everyone, including Mr. Auditor, will want to read it.

About The Author

Miriam Boudreaux

Miriam Boudreaux is the CEO and founder of Mireaux Management Solutions, a technology and consulting firm headquartered in Houston, Texas. Mireaux’s products and services encompass international standards ISO and API consulting, training, auditing, document control and implementation of Web QMS software platform. Mireaux’s 6,500 square foot headquarters, located in the northwest area of Houston, houses their main offices as well as their state-of-the art training center. Mireaux itself is certified to ISO 9001:2015 and ISO 27001:2013. To get in touch with Miriam Boudreaux, please contact her at info@mireauxms.com.