Editor's note: Most, if not all, young scientists and engineers face a situation that requires questioning problems that develop. Ronan Nugent describes this kind of situation from his engineering career and promotes the use of simple common sense. Much of his story focuses on his employer, an electronics firm, and its project to achieve ISO 9001 certification. ISO 9001 is one of a family of international standards for quality systems management that help document quality systems and encourage continuous improvement of quality processes. For more information about these standards see the International Organization for Standardization Web site.
After qualifying as an engineer, I worked for an Irish multinational in R&D, product engineering, and quality systems development. I then led a technology start-up and freelanced as a science copy editor for major science, technology, and medicine publishers. I now work in Springer-Verlag's computer science editorial department. I've followed a nonlinear career path. Work experiences can be educational, and often it's the most illogical episodes that are the most informative. I hope young professionals find this story helpful in a work context while other readers may see the general value of "Kipling's questions".
In my first full-time job, I designed control and communications hardware and software products for a multinational electronics company. Although all the software modules and printed circuit boards that I developed worked well, none was a thing of beauty. I wasn't among the high-fliers in R&D, didn't have a flair for the job, and didn't spend lunch breaks comparing microprocessors and learning the black art of electronic noise suppression.
The tasks: ISO 9001 certification and UL listing
ISO 9001 is a quality management standard, and for marketing reasons our management decided to aim for certification of our company. Independently, we sought a UL (Underwriters Laboratories) listing, i.e., approval, for our main US product. Within the engineering department I was given responsibility for the related product engineering tasks and quality systems development. The R&D director didn't care about either project, and didn't rate the skills involved, so my promotion was something of a left-handed compliment.
I was a good product engineer--an effective communicator, accurate, dogged, and hardworking. I wasn't happy until the product component list matched the circuit board component layout diagram, and the components were of the correct specification, etc. But even after 6 months of effort, every unit shipped to the US office still required reworking. Our dismal production controls were threatening the UL approval project.
In a once-off accident, our soldering machine mishandled a batch of printed circuit boards--solder swamped the components on the top layer of each board to a depth of 1 centimeter. Amazingly, production shipped the boards to the US subsidiary anyway, and coincidentally I was there when they arrived. They were like Jeff Koons creations--shiny, kitsch, weird monsters. Although each circuit board was clearly electrically unsafe, and hadn't been powered up and tested, each had its little green "test pass" sticker. This was the reductio ad absurdum of my product engineering activities. We'd have to dramatically and systematically improve our production controls if we were to secure our product approvals.
So I was drafted onto the company's main ISO 9001 team, working on issues far beyond my original R&D brief. It was a very strange experience. I learned the theory of ISO 9001, I did the usual training courses, and I still appreciate the elegant text of the standard itself. But the surrounding "quality industry" was a shambles.
There are a number of reasonable approaches to "getting ISO". If a company assumes that its current work practices are sensible enough, it can write procedures that exactly match the actual workflows in production, and then set up improvement loops using the ISO 9001 standard as a reference. Another valid approach is to write logical, self-consistent procedures that match the requirements of the ISO standard, and then adopt these on the shop floor, etc.
By contrast, a series of consultants and managers had bluffed their way through our ISO project for 4 years and had managed to write procedures that weren't logical or self-consistent, didn't "talk" to each other, didn't match the (bizarre) real workflows on the production floor, and didn't remotely satisfy the requirements of the ISO standard. Quite simply, our procedures were useless.
So the company hired a new quality manager, a man brimming with stupidity and initiative. Among his early creations was a new document control procedure. An amazing work, its flow diagram included a three-exit decision rhombus: one "no" route out, and two "yes" ones with wildly contrasting outcomes. "My" engineering procedures had to interface with this marvel, and I discreetly raised the problem with the quality manager. When that didn't work, I followed his suggestion and used the official change mechanism, i.e., I generated a corrective action request. He rejected it. In a piece of stunning circular logic, there wasn't any bug in a procedure if he himself couldn't see it, and he'd written this infallibility clause into our new corrective action procedure. His three-exit decision rhombus survived for another 6 months.
This isn't rocket science
It was finally clear to me that no critical thought had gone into the design of any element of our quality system, and yet the CEO continued to insist that all new procedures would have to be compatible with existing ones, however ridiculous the outcomes.
To a team of computer programmers it would seem utterly daft to start coding a software module of any decent size without at first "seeing" the overall flow diagram, on paper or otherwise. ISO 9001 didn't look like rocket science to me, and I asked for a sensible review of our situation.
So the ISO 9001 team brainstormed it. The CEO asked me to explain how I approached my analysis of our procedures and workflows. Off the top of my head I told him that I used the basic "Who?", "What?", "Why?", "When?", "Where?" and "How?" questions, reapplying each question to each answer in a rapid, freeform manner, thus quickly building up a mental picture of how a procedure would operate in reality.
The CEO had a master's in industrial engineering and considerable business experience. To my amazement he asked me to repeat the list of question words, and this time he wrote them all down. He pored over his writing pad for over a minute, then beamed and declared that the ISO team had finally made a breakthrough. I didn't know how to react. I thought he was joking. He wasn't, he thought I was smart and original. I thought I was being smart, and I knew I wasn't being original--I'd bumped into Kipling's "six honest serving-men" somewhere along the line.1
The CEO told all members of the team to write down the magic questions. He asked me for simple examples, and I fired them out: " What is the engineering primary documentation?", " Who generates it?", " When does an engineering change request apply?". Simple stuff, each an entirely self-evident opener, and each a "breakthrough" for the ISO team.
The breakthrough: Use the fundamental questions
As crazy as it now sounds, my six fundamental questions actually were original in our local context. Up to that point the CEO and his ISO 9001 team simply had no idea how to critically examine workflows and their abstract representation in text form, in flow diagrams, or even in "hand-waving" explanations. They had a limited, quality-control grasp of procedures, at best. In their view, if the widget passed its final test then production had done its job. For the ISO 9001 project we needed a quality-assurance approach, one that almost guaranteed the widgets would pass their final tests because they'd been designed and built properly. On the shop floor our managers could only see procedural errors after they'd already caused "real", i.e., physical, problems.
The magic questions provided the breakthrough, and soon teams throughout the company were tenaciously probing the logic of our activities. We eventually achieved both the UL listing--i.e., approval for our main US product--and the ISO 9001 certification, and we dramatically improved our production efficiency.
These experiences have informed my thinking since. Up to that point, I'd largely deferred to established systems, and implicitly to the collective experience, knowledge, and logic they represented. Now I don't. If something doesn't make any sense to me, that may be because it simply doesn't make any sense. We live in a world where a startling number of people make absolutely no sense much of the time, and unfortunately many of these people are quite influential. I've worked with, for, around, against, or in spite of their like in many different situations.
If you're a young graduate in a scientific or technical discipline, I'd encourage you to be generous with your common sense, intelligence, and naivety--they're often as valuable to a company as your education and knowledge. Don't be afraid to ask "Kipling's questions", and with any luck you'll find an employer that appreciates your contributions.
1 Rudyard Kipling's lines followed the story "Elephant's Child" in Just So Stories: "I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When [A]nd How and Where and Who."