More Ways To Avoid Errors
For one study I was involved in at an engineering firm we created a streamlined quality assurance (QA) procedure that worked well. The project was under budget and ahead of schedule. This wasn't to last, though. A few changes by the client prompted management to enforce stringent QA rules. Thereafter, the study ran over budget and behind schedule until it finally was terminated. What caused this disaster? QA seems deceptively easy. You write a few instructions and you're done, right? Wrong! Adding people unfamiliar with your project and following a hodgepodge of guidelines and checklists won't save it. Managing quality can make the difference between a successful project and a failure. So, let's consider sources of error, QA tools, and the time involved in implementing QA. First, understand that QA in engineering differs from that in production: the stakes are higher in engineering. It requires more than 100% inspection because of its labor intensiveness. Human inspectors find 80% of the defects and miss 20%, according to "Juran's Quality Control Handbook" (p. 18.86). You can't afford to look at something only once!Mistakes in engineering design stem from a variety of factors, e.g., incorrect technique, scope changes, bad data, lack of knowledge, human error and poor management. Incorrect technique appears self-explanatory but isn't. Perhaps an engineer uses the wrong material properties package in a simulation program. Who will catch this mistake? You may need an expert on your staff. Scope changes may impact your project in unforeseeable ways. Human error can arise from fatigue, boredom or a desire not to cause trouble — going along to get along. Poor management can result from distractions, conflicts with schedule or budget, or apathy. Now, let's look at proven tools and tactics for minimizing design error. These include: checklists, procedures, schedules, standards and outside review. Checklists are great reminders of what should be done. However, they aren't very helpful in describing how it should be done. That's where procedures come in. A long-winded procedure unsupported by graphics isn't useful, though. It's more effective to summarize procedures via flowcharts and lists. Write text to support the charts and lists, explaining important details. Include schedules — because instructions without deadlines are useless. Employ standards to avoid confusion and error. For instance, establish symbol standards for equipment and instruments, for doing and presenting pump calculations, and for control logic. Confusion can be costly. (One of the reasons the French have been so successful in deploying nuclear power is that every plant conforms to rigid standards; in America, all nuclear plants are unique.) These suggestions apply to the team doing the work. How does it look to an outsider or the client? Groupthink is a dangerous psychological phenomenon. Friendship often inhibits people from being candid. They won't tell a peer when he or she is wrong. Solve that problem by getting an outside perspective. Robert Townsend, author of "Up the Organization," calls this the "man from Mars" point of view. Here's another thought: why not change the design process completely? When I worked at a Japanese company I found it interesting that no one engineer is responsible for a design. Equipment and other details are divvied up among the team. Each engineer is tasked to create a summary table of options showing their advantages and disadvantages. Other QA techniques used include change analysis and force field analysis. A change analysis table compares the now and the then. For example, what has changed by replacing a vertical condenser with a horizontal unit? Force field analysis looks at driving and restraining forces. An engineer may have to go before the group several times until it's satisfied that all design problems have been addressed. The advantage of this approach is that it uses all the talent available instead of burdening a single individual. As promised, let's look at a real world example. I estimated the hours required to develop a process flow diagram (PFD) and piping and instrumentation diagram (P&ID) for a process involving a pressurized reactor with basic controls, an agitator, heat exchanger and a pump. I included the specifications and all the necessary reviews. I assumed that the process was well-known to the client and that this information was communicated to the engineers. Based on this exercise, I reckoned a total development cost of about $56,000 per P&ID, assuming hazard reviews and management-of-change reviews along with client reviews of the PFD, P&ID and specifications. It took 100 hours for the drafter, 484 hours for engineering, and 262 hours for project management. QA accounted for eight drafting hours, 132 engineering hours, and 84 project management hours. Looking at this another way, drafting spent only 8% of its time on QA and engineering spent 27%, while management devoted 32% of its hours for QA activities such as design reviews and client reviews. As this underscores, QA is very much a management function. Dirk Willard is a Contributing Editor to Chemical Processing. You can e-mail him at[email protected].
