ASQ Direction

I am disturbed by the focus I have been seeing recently from the ASQ.

For the past year now, Paul Borawski has been showcasing executive leader attitudes and perspectives on quality. He's done this quite nicely in his blog called View from the Q.

I appreciate the perspectives, but I have trouble seeing how our typical ASQ members can contribute to these attitudes and philosophies. Many of them are overloaded with twice the work they had before the Great Recession and fearful that they will join the ranks of the unemployed. Many are struggling with difficult suppliers here and abroad. They are trying to keep the regulators and registrars happy. When I hear Paul and other ASQ leaders say, "focus on the customer experience," I wonder how that resonates with the average ASQ member. It is almost like suggesting they help Greece figure out how to remove the burden of sovereign debt.

It seems to me that ASQ is trying to become a Society for Organization Leadership or an Association for Design Excellence.

I do not question the requirement for great leadership and excellent design. Steve Jobs applied these skills very successfully after he came back to Apple. I marvel at the sheer delight my friends express when they use the latest iThing. I enjoy the benefit I receive when Garmin Girl helps me find my hotel.

But how does that translate to value I can receive by spending my personal or company funds on ASQ membership? And why the focus on cars and airplanes?

“I’m part of the ASQ Influential Voices program. While I receive a variety of quality resources as honorarium from ASQ in exchange for my commitment, the thoughts and opinions expressed on my blog are my own.”

Symposium on Transformation

I recently attended a Symposium on Society Transformation held in Bend, Oregon. It was a challenge for my engineering brain to interact with mostly health care and social service people. I think I came away with useful information and I know I made some new friends.

It takes nearly a day to fly from my home in SE Washington State to Bend, but only five hours to drive. I chose to drive. It was a beautiful summer day and I took the rural roads through the central part of Oregon before turning west to Bend. Just outside of Arlington, I encountered a forest of wind generators along the Columbia River. The wind blows pretty constantly up the gorge from Portland.

I continued south through the John Day hills and painted desert. It was a sunny and clear day and I pretty much had the roads to myself. A couple of times I had to dodge some Chuckers along the highway.

After arriving in Bend, Oregon, I checked into my room at the Seventh Mountain Resort. My wife and I last stayed here in 1982, when Marriott managed it. Nice layout of condominiums and activity areas, along with meeting rooms, all in the trees along the Deschutes River. Our Symposium group met in mid-afternoon and decided to enjoy the outdoors at a lake park nearby. After a few wrong turns and lots of road dust, our car-pool caravan arrived. We enjoyed the walk, the lake, the beer, and each other's company.

The first day of the Symposium was mostly spent in getting to know one another and understand the expectations of the 32 participants. We did a lot of talking and sharing. I began to be troubled, however. Everyone was talking about transformation this and transformation that. But I didn't know what transformation was! I figured it was different than just change. But how different? When I expressed my frustration, several others said the same thing. We had our work cut out for us.

One the second day, we got into the topic deeper. I was absorbing a lot of pieces, but it still wasn't coming together. In the afternoon, we formed small groups of 2-4 to just walk and talk. Four of us chose to walk along the Deschutes River. [river 116] Marvin from Canada and I started talking about this transformation thing and bouncing ideas of one another. Later on, the three in the front started walking faster. Rather than eat their dust (it was quite warm and dry along the trail), I fell back and processed all the pieces in my brain. Then it came!

Transformation is one system becoming a different system in a relatively short period of time.

This captures all the key principles of system, change, and time. I was pleased to share my ah-ha moment with the rest later that afternoon. I plan to post a couple more articles here later on about some other key takeaways I got while I was in Bend.


My drive home was a bit more direct. Straight up US highway 97 to the Columbia River, then right up the river to Kennewick. This was two days after a big weather pattern brought thunder and lightning. Lightning in the dry west usually means range fires and there were a number of them along the way. Nevertheless, the drive was very pleasant.

As I approached the Columbia River at Goldendale, I came upon several hundred wind turbines along both sides of the river. This place is ideal for wind energy, as the wind is pretty constant, it is close to the BPA transmission lines, and it is east of the protected scenic area.

Are Audit Checklists Evil?

There have been several Linked-In postings lately about the use of checklists during a management system audit. Most have focused on quality management systems, but the principles are universal. Some are stating that the registrars (aerospace, automotive, etc.) do not even allow the use of checklists. While I find this hard to believe, I think I understand why those statements are being made.

I think that many folks think of the standard 57-page list of international standard requirements when they hear the word "checklist." I was guilty of publishing one of these as an appendix in the back of the second edition of my book on auditing. It wasn't 57 pages long but it was written to address all the clauses of the ISO 9001:1987 standard. Big mistake and it was removed in the third (and current) edition.

These extensive lists of requirements for a particular international standard can be harmful for several reasons. They shut down the mind. They allow an auditor to proceed without exploring the processes and methods. They result in boring reports. They are indeed evil!

We know that the most laudable concepts - Thou shalt not steal; thou shalt not lust after another's property - are no good without local methods and boundaries. Often these local strategies and tactics are expressed in site-specific manuals and procedures. Work product specifications are contained in drawings and assembly sheets and test plans. The whole idea behind the "process approach" to auditing is to see if these local documents support the standards and regulations and they actually work. We must drill down deeper than just the AS9100 layer.

A standard set of checklist questions, based upon the external standard or regulation, is a good starting point. But it must be customized to include the auditee manuals, procedures, and specifications. Then it becomes a very useful tool for gathering data. These data are used to form conclusions – the fourth of four rules for auditing. No data, no conclusions.

We can apply a number of different techniques to customize our checklists. Flowcharts are perhaps the most used (and useful). Turtle diagrams help to open our minds and explore the many facets of process control. Sure, this extra work takes time and concentration. But to do an audit without such customization is a disservice to all stakeholders: auditee, audit boss, and the internal or supplier organization.

Some of my pals who work for registration firms tell me that they wish they could customize their checklists for each assigned audit. But the market will not support this. So perhaps the work-around is to have no checklist at all. I do not believe that is a viable solution.

I will continue to teach and advise my friends that checklists are your friends. But they must be customized down to the process level in order to get all of their inherent benefit. No system audit checklists should ever be the same. Sure, questions can and should be recycled. But we need to engage the little grey cells of the mind before proceeding with the fieldwork.

Auditing Internal Company Procedures

A colleague in the U.K. recently wrote to me. He asked how often he had to audit his internal procedures. My response:

First, you need to recall the document pyramid, where the external docs (like ISO standards and government regs) are at the very top. Then come the site-specific manuals, which describe how the local operations will conduct their business in accordance with the external docs. These are system documents and should be skinny. Then come the many process-focused procedures. These are job performance aids for an already trained and qualified employee, be they manager or operator. At the bottom of the pyramid are the job, task, or patient-specific specifications. They specify the form, fit, and function often used for QC inspections and are product-focused. Manuals (system) to procedures (process) to specs (product). Your question concerned the process procedures.

Now, we need to recall the concept of Document Control, especially for those process-focused procedures. The best procedures are 5-6 pages and written by the process owners and doers. They are the experts. Once a procedure is drafted by a person or a team, it must undergo peer review. This is to make sure it really works. The draft procedure may need to undergo several reviews and revisions before it is "perfect." Only then is is approved, usually by a manager and generally signified by a signature or database entry. This approval signifies that the procedure is perfect. Now the perfect procedure is ready for controlled distribution. This is called version control, where the old version is replaced by the new. Today, with most procedures no longer printed on dead trees, rather uploaded to a content management system, version control is a simple as replacing the old file with the new one. If you still use printed procedures, then individual copies must be swapped out. The procedure is ready for use. Through use, we may discover that the procedures is not "perfect," so it must be revised and we go back to the beginning of the document control cycle. Your mention of the annual examination (probably required by your manual, because ISO 9001:2008 does not require it) is a way to continually make sure the procedures are perfect.

There never was an ISO (or any other) requirement to audit each procedure annually! That's kind of dumb. The ISO 9001 standard says you must periodically audit the presence and implementation of all your controls, in a planned and systematic fashion. The most important activities - as measured by their effects on cost, production, and risk - are audited more often. Generally-accepted and good auditing practice says you should cover everything within a three year period. This also corresponds with the term of the registration certificate.

So, your managers are reviewing and revising their procedures and intend to keep doing this annually. That's a good thing! But it does not substitute for the internal audit, as the managers have ownership and a vested interest in the outcome. Auditors can look at the presence and implementation of needed controls more objectively.