Featured Product
This Week in Quality Digest Live
FDA Compliance Features
Michael King
Augmenting and empowering life-science professionals
Meg Sinclair
100% real, 100% anonymized, 100% scary
Alonso Diaz
Consulting the FDA’s Case for Quality program
Four data layers that matter
Kari Miller
Regulations and increased complexity are pushing the industry to adopt innovation more quickly

More Features

FDA Compliance News
Recognized among early adopters as a leading innovation for the life sciences industry
Streamlines annual regulatory review for life sciences
Facilitates quick sanitary compliance and production changeover
Creates one of the most comprehensive regulatory SaaS platforms for the industry
Company’s first funding round will be used to accelerate product development for its QMS and MES SaaS offerings
Showcasing tech, solutions, and services at Gulfood Manufacturing 2022
Easy, reliable leak testing with methylene blue
Now is not the time to skip critical factory audits and supply chain assessments
Google Docs collaboration, more efficient management of quality deviations

More News

Paul Naysmith

FDA Compliance

Who Is the Customer of Your Document?

A quality manual serves no purpose if no one reads it

Published: Wednesday, September 18, 2013 - 10:39

Arecent call with an old colleague from Europe got me wondering about a question that few are conscious of: Who is the customer of your quality document? Oh boy, did we have an interesting discussion about quality systems.

My friend was developing and reinvigorating his employer’s quality system, and working with someone who clearly didn’t fully understand quality. Actually, I should qualify that last statement: This person isn’t someone who is unfamiliar with our discipline; he’s a consultant with a global background in implementing quality systems. However, during the course of our discussion, it started to dawn on both my friend and me that the consultant simply couldn’t see what was important: the customer.

So there I was, 5,000 miles from him in a little pop-up window in the corner of my iPad, attempting to help him out. He told me he’s frustrated with the sharply dressed consultant, an apparent expert in quality. My friend’s pixilated brow furrowed as he explained that the consultant was speaking before a room full of senior executives, letting his mouth dig a big hole for himself, and making a mockery of quality professionals around the world.

“I wanted to help, I really did,” said my friend, “but his mouth continued to run away from him, and it’s only getting worse.” All this drama for something as simple as defining the purpose of a quality management system (QMS) manual. Apparently it’s a real monster, a weighty 100 pages in girth, written in very difficult-to-interpret language, and created by this quality consultant.

The irony didn’t escape me that I was acting as a consultant to my friend, attempting to provide a listening ear and perhaps some advice about how to deal with another consultant.

Before attending the meeting with executives to listen to the overpaid know-it-all, my friend was asked to review the quality manual. He did; it took him two days to digest, and he still didn’t understand it. How could this be? If my friend, a contemporary in quality and a skillful veteran of reading countless quality documents, found it difficult to get through, how on this green earth could he expect anyone else in his business to understand it, let alone have faith in it?

I have a simplistic—well, sometimes too simplistic—view of business. Yes, I know companies are complex and have huge interdependencies, but why do we have to make things more difficult than they need to be? In my experience, if something like a documented procedure is too challenging, it results in a very predictable and typical outcome: Everyone ignores it and does their own thing. In business and particularly with quality issues, achieving simplicity adds more value to an organization.

After going into great detail about each section of the QMS manual, my friend asked for my opinion. “If I fed this manual to a donkey, it would choke on it,” I said, which produced a laugh, although I had no intention of treating the matter as a joke. So I leaned back in my office chair—if I had a long wizard’s beard, I’m sure I would have been stroking it as I gathered my thoughts—and asked, “What’s the problem you’re facing? And what’s the solution you’d like to see?”

I’m not sure those questions had been asked in his room of executives. My iPad’s screen seemed to freeze, and I wondered for a moment if my Internet connection had gone down. It hadn’t; it was my friend who was frozen—deep in thought. Sometimes silence speaks louder than any answer.

Eventually the silence seemed to pull a response from the vacuum of deep space: “We’re too bureaucratic and lack standardization across the business,” he said. Alrighty, we’ve gotten to the bottom of the problem with this QMS manual, and unfortunately, brought to light a new problem in the process: increased complexity has been introduced into his company via the new manual. A new enemy to standardization across his business has been born into the world. The manual would undoubtedly be difficult to understand, and people, being people, will find a way of doing their own thing to make life easier for themselves.

Now you might be thinking as you read this that your own QMS manual is similar in size, or even bigger, and something must be wrong with it. I wouldn’t or couldn’t comment on that without knowing more about the business it applies to, or how it was written. Why focus on the page count anyway, when the content ultimately is what matters? That thought got me wondering who the customer is of a QMS manual. Who reads it, and why would they?

In the quality field, we may be asked to facilitate or even create documents. I like this task, but I love simplicity more, and I don’t like wordy procedures. I prefer a picture-book procedure, and a video procedure even more. Why give me pages of text, when a cartoon could quickly explain what to do, in a way that everyone can comprehend?

So I asked my friend who the customer of his QMS manual is, and he couldn’t come up with an answer. In most cases when I’m mentoring someone, I don’t necessarily expect an answer immediately. I don’t know the answer to this question as it applies to his business, and he may not, either. However, it’s a powerful question and worth asking every time we create a new document in our daily work. We should ask why the document needs to be created, understand the significance of who is going to read it, and consider its value to the business.

For my friend’s predicament, the customer of the QMS manual could be the different departments that connect into the management system or work from it, or it could be an accreditation body, or it could be both. It’s not for me to define who his customer is. However, it's certainly the case that if he neglects to consider the customer of this manual, it’s going to fall short, and he’ll soon be dealing with a dissatisfied customer and haphazard processes.

How can we avoid following in my friend’s footsteps? Like any well-managed project, a document should identify at the very start the objectives and key stakeholders. It’s a basic quality principle. In chapter two of Juran on Quality by Design (Free Press, 1992), Joseph Juran goes into an interesting debate on which comes first, the goals or the needs? He considers this a “chicken and egg” argument, adding that there is “an intimate relationship between the needs and the goals,” and that “the customer’s needs become the supplier’s goals.”

My advice to my friend, then, was to revisit who his customers are and determine their needs. That would define the goal of the QMS manual.

As you set out to create documents for your quality system or even review existing ones, remember to apply the same principle you do to ensure a quality service or product. Ask, “Who is the customer of this document?” You will end up achieving a quality outcome.


About The Author

Paul Naysmith’s picture

Paul Naysmith

Paul Naysmith is the author of Business Management Tips From an Improvement Ninja and Business Management Tips From a Quality Punk. He’s also a Fellow and Chartered Quality Professional with the UK’s Chartered Quality Institute (CQI), and an honorary member of the South African Quality Institute (SAQI). Connect with him at www.paulnaysmith.com, or follow him on twitter @PNaysmith.

Those who have read Paul’s columns might be wondering why they haven’t heard from him in a while. After his stint working in the United States, he moved back to his homeland of Scotland, where he quickly found a new career in the medical-device industry; became a dad to his first child, Florence; and decided to restore a classic car back to its roadworthy glory. With the help of his current employer, he’s also started the first-of-its-kind quality apprenticeship scheme, which he hopes will become a pipeline for future improvement ninjas and quality punks.


Quality Documentation

In my experience, workers seldom perform their jobs by referring to process documentation in any format. Instead, they are trained and coached by their supervisors (managers) until they essentially memorize their jobs.

A question might be, do the managers, who are in some way the process owners, thoroughly understand their processes to the point that they can successfully transfer knowledge of the process to the workers? A "litmus test" could be "if you thoroughly understand this process, then let's see you document it".

My point is, to answer the question posed by the article, "who is the customer of your document?", the answer is "you are".

Quality Manuals

Nice article Paul on Quality Manuals. May I suggest that most still do not have the organizations processes mapped or named in the manual and continue writing their Contents page with the headings of the ISO001:2008 Standard. As you say these types of Quality Manuals and others too like ISO14001, ISO18001, AS9100-C and ISO TS16949 must reflect the business processes, their interfaces and interactions to meet as your article's focus, the customer needs but also the way the business and its other interested parties / stakeholders needs are to be met. Organizations cannot harvest the value from their improvement Lean, BPR, Kaizen, TQM, Six Sigma Programs unless the Quality Manual is written around and named in the Content page as its processes. Where are the processes to be stabilised, controlled, improved, made capable and then sustained to be found - in the Quality Manual and its reference to its processes. Hopefully, if well designed compared to the 100+ page tome you referred to with the 'dig deeper hole consultant', organizations can then see value to them and its customers. The Certification Body (may I say so as its not 'accreditation boy' Paul) are starting to change out their Clausal Thinking auditors to now get more Process-approach thinkers and hence auditors who can better understand that clients' business, its processes and as you say how it both meets the ISO9001 requirements and that of their customers. We have seen refreshing new breed of Quality Manuals which are only a few pages and described, in pictures, process maps and interface matrices the Core (Value Stream for Lean folk), Management and Support business processes. Some are using the APQC Process Classification Framework as a guide. The revisions to ISO9001:2008 for the CD of ISO9001:2015 reflects more of this process-thinking which in some ways is what ISO9000.1:1994 described for Processes having the Approach, Deployment, Improvements and Results for all stakeholders. Hang around long enough, and it all returns to the basics I guess. Michael