The effectiveness of communications among departments within a typical organization has historically been a hit-or-miss proposition. Communication takes many forms, and each of these forms can cause its own type of distress. For example, call-outs on a drawing that specify 22 in. may be interpreted as 2 ft 2 in., or a verbal instruction to "dry up the sump in the No. 2 warehouse" may mean a new drainage field and pumping station to some when what was called for was a bucket and mop.

Engineers tend to think in linear paths with an end in mind and a course of action identified from their first encounter with a situation or proposal. Once set upon a project's trail, they will doggedly pursue the course of action they feel most confident in, and very little will divert typical engineers from the course. That is why we love them and why they are useful to us. However, engineers may be at a great disadvantage when operating within these patterns of thought; they are victims of their own paradigms.

Operations personnel may or may not think in these linear paths. They tend to make their needs known and then get out of the way and let the engineers design solutions to the problems they have been given. The maintenance organization often gets caught in the middle. Engineers tend to encourage this type of treatment by remaining detached from the mainstream of plant operations and by performing their assignments in semi-autonomous work units. Traditionally, engineering departments have not responded well to management; guiding an engineering staff has been compared to the "management equivalent of herding cats."

This tendency toward independence can be interpreted as arrogance or resentment of interference, leading to an even more insular environment for engineering. Add the language barrier between engineering and the rest of the world, and you have a perfect formula for non-détente. This linear thinking and reluctance of other departments to interact with the engineering staff can lead to a one-time interface with a project design group and the avoidance of followup on the part of management or operations.

Engineering efforts can result in a perfect fit for the situation at hand, or something that leads production to say, "Yes, that will work, but it isn't exactly what we had in mind. If only you had." Sometimes the result does not begin to approach what the correct action should have been.

On a recent tour of a client's facility conducted by an instrument and electrical (I&E) technician, I was shown a small structure containing a board, some gauges, and cables. The technician made it a point to inform me that the structure (more of a one-walled shack than anything else) had cost over $43,000. When I expressed some surprise, he laughed and pointed out three identical fixtures on the property, none of which had ever been brought on line. The long and short of it was that the I&E project and maintenance crews were given detailed drawings for the execution of these structures by the project engineering staff 3 months after upper management had canceled the project.

Obviously, the blame for this fiasco can be shared by several individuals: the I&E department, for not understanding the intention of the project, the installation crew for not checking the construction schedule against operation's needs, the operations group that first commissioned the project and then abandoned the installation, and certainly upper management for not having a formal review of the project development status when the decision was made to cancel the project.

This case is isolated, of course, but how many times have we seen wasted money and effort spiral along with a project whose purpose evolves or disappears over the course of development? This scenario is most true when a project has either a poorly defined statement of purpose or an extended development horizon, with lengthy lead times between inception and execution.

Too often, the developing project with its solution will run into the reality of true need at a point where the project has begun to take on a life of its own. So much time and money have been poured into development that egos will be crushed and jobs may be lost when it becomes evident that the project has no practical application. In these instances, operations and engineering will often try to salvage the effort thus far expended. The final outcome may be a jury-rigged solution that does the job but is far from optimal. Another very real cost is that of sacrifice; how much profit have we forgone in lost manufacturing timetime that could have been spent turning out product but was instead spent pursuing solutions to problems that may have changed or become moot.

To promote the better use of engineering's time and efforts and to promote better communication between departments, it is useful to pursue a course of "concurrent engineering," bringing together affected parties for a harmonious relationship that stresses the positive contributions various participants can make, rather than pointing out differences between departments.

In approaching concurrent development, a "project prospectus" may be useful. The prospectus is simply a tool for setting clear, written, concise ground rules for a project and then reinforcing periodic routine communication among the concerned participants. The interval at which the parties meet is set by the involved parties (chief project engineer, an operations representative, and a project sponsor, for example) when they decide on the rest of the terms.

Other terms of the prospectus would define the intended purpose of the project, the problem or situation the project is intended to address, the parties responsible for oversight and participation, the proposed budget, expected completion date, and delivery dates for incremental milestones. It would also formally recognize the contributions that all parties will make to the development, not just the engineering staff. In this way, the prospectus becomes something more than a request for action and less than a contract for the parties involved (see the example).

An added benefit to the approach is the introduction of time sensitivity for the engineering staff. The pursuit of productivity in development staffs is often nebulous because of the intangibility of the product. The prospectus requires that the parties make a commitment to time expectations and delivery dates and then lets progress be examined in a public forum. As the project progresses, the charged parties meet at the specified interval to review the status of the project and to ask pertinent questions regarding the intention and outcome of the project.

This approach cuts across departmental boundaries to ask common-sense, practical questions: Is this project still viable? Is the original need unchanged and is the intended result unchanged? Is progress being made at an acceptable rate and are financial ramifications the same? Are staffing requirements static? Are personnel issues changed? Are supplier commitments unchanged? Have timing needs evolved? Are delivery dates holding steady? Management may wish to set a bottom control limit on the amount of money that would make this approach practicalany project over $20,000 with a development horizon of over 90 days, for example.

The interval for review should be controlled by two factors: Let enough time pass so that consequential progress can be made, but not so much that significant time, effort, and money can be wasted, should needs change. This approach has an added benefit. The periodic review of projects tends to raise the collective consciousness of the entire organization to the impact of project work and the resources devoted to engineering and projects. The result will raise the awareness of the entire organization regarding the amount of money devoted to project and developmental work. With engineering costs typically running in excess of $50/hour, wasted resources can quickly reach significant proportions.

Some parties may view the initial introduction of the prospectus as intrusive, but the benefit becomes readily apparent to all who have a sense of real contribution to their organization. To ensure the future acceptance of this approach, the first instance of using a prospectus needs to be a success. Therefore, the initial project sponsor may wish to pick a high-profile project with good support as the inaugural project. The project team should include forward thinking members with good adaptation and cooperation skills.

After all, tigers can be trained to jump through flaming hoops; it should be easy to herd cats. MT

Charles Spillman is a project manager with HSB Reliability Technologies, Kingwood Place 3, Suite 180, 800 Rockmead Dr., Houston, TX 77339; (281) 358-1477.

• To preserve the functions of our physical assets throughout their technologically useful lives
• To the satisfaction of their owners, of their users, and of society as a whole
• By selecting and applying the most cost-effective techniques
• For managing failures and their consequences
• With the active support of all the people involved.

Wellesley experienced an upsurge in load as the result of the personal computer. "In 1994, when the plant was commissioned, only a small number of students had their own computers. But then the college wired the campus into a network and now 95 percent of the students use computers. Plus, most of the faculty has computers," explained Traci DiGiorgio, systems operation engineer for the Wellesley College physical plant.

"In addition to supplying all the electricity for the college, we furnish power to the municipal electric system of the Town of Wellesley, principally for peak demand shaving. The town buys baseline power in bulk from the local utility, Boston Edison. The requirements of the college and the town put a premium on avoiding downtime, especially during periods of high demand."

The Wellesley College cogeneration system consists of four 16-cylinder, 1500 rpm, 2340 hp Jenbacher natural gas engines, each driving a 1.4 MW AVK generator through a step-up gearbox. The normal speed of the Jenbacher engine is 1500 rpm to provide the 50 Hz power used in Europe; the step-up to 1800 rpm is necessary for the 60 Hz power used in the United States.

Wellesley subscribes to the oil analysis programs for both the engines and the gearboxes: Engine Maintenance through Progressive Analysis (EM/PA) for the gas engines and Trend Analysis for the gearboxes.

Plant maintenance workers sample lubricating and gearbox oils every 500 operating hours and send the samples to a laboratory for analysis. For the engines, the laboratory generates reports on levels of oil oxidation, nitration, viscosity, and contaminants such as coolant, dirt, and wear metals.

DiGiorgio explains, "Previously, reports were mailed to us, so it was a week to 10 days before I received the results. This was adequate for the gear oil, because the reports almost always came back completely positive.

"However, two problems can develop in the engines which could lead to major problems if not detected in time: dirt ingestion and coolant leaks. These problems can be particularly acute because the engines run constantly. Dirt ingestion can occur from a leak in the air intake system, but it probably would take longer to develop into a problem because we operate in a clean environment. Coolant leaks are another story. They can quickly escalate into major repairs if not detected."

The data analysis program, Monitor for Windows, allows users to receive sample reports electronically by downloading their data through a modem from a computer at the laboratory. The program delivers clear, concise reports and the user can manipulate, analyze, and graph data easily and effectively.

Information can be accessed as soon as it is recorded. Problems are red-flagged on the screen and corrective action is taken immediately. The red and yellow flags (yellow indicates borderline situations) include suggestions for corrective action.

A coolant leak did occur on Unit 1, resulting in damage to the camshaft and a cam follower. "However, it could have been much worse," says George Hagg, manager of physical plant operations. "We could have experienced broken valves and other problems that could have meant replacing an entire head costing more than $35,000 not including downtime. This situation would have reduced the capacity of the plant and its ability to meet the needs of both the college and the Town of Wellesley."

DiGiorgio points out that she can generate trend graphs easily with the program. "We also generate reports requested by the engine builder. In fact, I can generate any kind of report I want fairly easily." Photographs can be scanned and included in the body of the report. These are important for presentations to the college administration.

Reports generated by the software are necessary for insurance claims, Hagg points out, as well as evidence of corrective action taken.

Based on the experience with oil analysis, Hagg has the oil changed every 3000 hours. "The manufacturer recommends every 1000 hours, but we were able to demonstrate that because we use a premium product and run analyses every 500 hours, we could safely raise the change interval to 3000 hours." Engine oil filters are changed at 1500 hours, and gearbox oil is changed every 3000 hours.

Hagg also notes, "We have a waste oil permit. After 3000 hours I sample the used oil and then burn it in the plant boilers. I keep the sample reports as required by the U.S. Environmental Protection Agency."

Because the engines are fairly new there has been only one minor top-end overhaul at 10,000 hours. At 20,000 hours another minor overhaul and camshaft and cylinder liner inspection will be performed.

A major overhaul is currently scheduled for the 5 year mark. At that point major trends will have been established, particularly in wear metals, to correlate with inspection of the entire engine.

Hagg says he expects to reach the major overhaul mark without any unanticipated repairs. MT

One of the best user group meetings I've attended recently was the MCE Motor Testing Technical Conference presented by PdMA Corp., Tampa, FL. The program had an excellent balance of speakers from the company, its customers, and outsiders. Although my own presentation was listed as the keynote address, in my view the highlight of the conference came an hour or so later in the presentation, "Making a More Effective Case for Your Recommendations," presented by Robert Yontz of the Inspection and Reliability Group at an ARCO Products Co. refinery.

Yontz provided a balanced perspective covering the benefits of a comprehensive equipment condition monitoring process as a part of an overall reliability process, noting that success depends as much or more on human factors as it does on technology factors. Monitoring technology cannot meet its potential until it is accepted by the owners and operators of the equipment, as well as the maintenance crafts.

His plant invested in interdisciplinary training for craftsmen, operators, engineers, and predictive analysts, allowing all participants to appreciate the capabilities and limitations of all the technologies and job functions. The plant's investments in technology and training produced an exceptionally high return.

My take from Yontz's presentation: Investment in condition monitoring technologies pays dividends. So does investment in training. But put the two together and you get a synergistic bargain that can't be beat.

Thanks for stopping by,

Before the Mirro Co. became serious about using a computerized maintenance management system (CMMS), our maintenance department was the world's greatest fire department. We continually moved from one fire to another, never really getting a handle on anything, never able to get ahead of the game. In spite of working tremendous amounts of overtime, we never seemed to catch up.

The push to automate the maintenance function came from top management several years ago. Unfortunately, not everyone concurred with the idea, and the necessary effort and money were not devoted to the project. No one understood the implementation processthe amount of work involved, the time required, the commitment needed. When management tried to revive the maintenance computerization effort, we got half way up the hill again and determined that it was easier to fight fires than to combine fighting fires with pushing the preventive maintenance (PM) program uphill.

With my transfer from engineering into the maintenance department, one of the first things we did was to review the CMMS efforts. It was clear that the previous efforts failed for two reasons. First, the program's intent and importance really had not been explained to everyone. As a result, no one understood what it was supposed to accomplish, how it was to be accomplished, or what the benefits might be. Second, it would require far more work in the short term to institute the programs, databases, and procedures than anyone previously had anticipated.

Mirro already had invested in the Eagle Expert Maintenance Management system for Windows (WEMM). We rejected taking the "clean start" approach to computerizing maintenance management. There was neither the time to investigate the features and benefits of the many programs available, nor the confidence that management would invest in another system when we already had one. Upon examination, WEMM appeared to be user friendly, and it presented on screen all the information we would need. It had sufficient reporting capacity, and by adding the Crystal reports feature we could customize our reports.

Top management received a briefing re-emphasizing that this program, once implemented, would save the company a tremendous amount of time. That implementation, however, would entail an inflated overtime budget and perhaps other expenditures. Not only would we have to continue performing regular maintenance activities, but at the same time we'd have to gather data, build databases, learn how to use the CMMS, and begin using the system in parallel with our daily responsibilities. In other words, everyone would have to be committed to the effort and recognize the challenge ahead of us.

There was another faction, however. Although the "buy-in" moved the program ahead more easily, people on the floor still expressed discouragement. The constant pressure to fight fires, and also to implement new or revised procedures and guidelines, prompted criticism from the mechanics centering on our potential inability ever to "see the light of day."

Initial goals
After the two previous false starts, the only goal we set for ourselves was to get the system up and running and to use it consistently. Establishing the process was the only goal; management reports or justifications would follow naturally. We needed to concentrate on the foundation. We couldn't let ourselves fall behind in the gathering of history, because we had no history on any equipment except that in the heads of the mechanics. If you didn't know which person had the knowledge, you couldn't get it. Now, everythingour demand maintenance work orders, our PM work ordersis entered into the system. When we need to know something, we can search by date, equipment number, or department.

Our first priority was building a history file. Next we would begin equipment PM to get ahead of the process. We knew it could be several months to a year before we would realize significant results from the efforts; it took about a year and a half. By then, however, we had enough history to set further goals.

The first signs of real progress came many months into our third restart. The tedious start-up tasks of entering history and closing work orders began yielding sufficient accurate history for tracking events. We produced our first CMMS graphs, showing the number of monthly PM tasks. One process we had initiated and were trackinga "PM Save" programshowed impressive, immediate results. Under the PM Save process, whenever a mechanic performs a PM and finds a situation requiring more than half an hour to repair, that is considered a PM Save. It may have saved that amount of time from production the following day or in the future, if the event might have caused a breakdown during a production run. Tracking PM Saves quickly highlighted the potential results through our CMMS efforts.

The real goal
Having accurate maintenance history then permitted us to set the real goal: to reduce No. 1 priorities by 10 percent during the following year. That goal was to raise overall equipment uptime from 90 to 95 percent, and ultimately to 97 percent. Today, after reaching the 95 percent level, our sights are set on 97 percent.

Retained history
Mirro's CMMS tracks maintenance requests and issues PM work orders for about 1675 pieces of equipment throughout the complex. Other locations also use the WEMM system, but the sites are not integrated through client/server technology or any other communications capabilities.

In addition to the plant-floor manufacturing equipment, the CMMS tracks other ancillary, facility-related items like blowers, makeup-air systems, air conditioners, fans, and heaters.

Computerization gives us the tool to take the maintenance program to the next step. In the coming year, our own maintenance personnel will be available to start a vibration analysis program. This work previously was performed yearly by an outside contractor.

Our staff will also conduct steam trap surveys, using an infrared thermometer to indicate when traps are open or closed. Although yearly surveys were worthwhile, a functional steam trap might fail the day after the survey. Then it might remain nonfunctional for 364 days until the next survey. Now we have time to perform the survey routinely, regularly. The CMMS notes the time for each trap's survey and prints the work order directing personnel to check that steam trap.

A balancing process
For maintenance purposes, the complex is broken into segments consisting of various machinery classifications. Within each classificationsuch as that for the nine large automatic washers, each of which is 120 ft longwe stagger the PM tasks so they do not all come due in the same month. The plant's nearly 8 miles of conveyors are handled similarly. The CMMS issues about 300 monthly PM work orders organized to present a consistent routine. Each month we try to balance the number of PM hours on conveyors, washers, and nine enormous ovens, each also about 120 ft long.

The two-building, original facility was built in the early 1960s as a stamping department and a finishing department. To connect those buildings in 1982, a 900 x 60 ft addition was built, and it also became a manufacturing facility. Today it is home to the washers and some ovens. Another 110,000 sq ft, added in 1989, provides a complete manufacturing facility from stamping through packaging. Most recently Mirro added another 115,000 sq ft facility that has the added capability of applying an exterior coating to cookware.

Within the CMMS, each facility is identified as a department. Reporting is possible by department, equipment type, or any other delineation. For example, all washers have a common asset number, and we can search for all the washers using that number. Then we might study these histories to identify any recurrences across the asset type. This capability simplifies identifying probabilities and improving the PM cycles and procedures.

The primary CMMS report used is the Demand Maintenance Work Order Report. Using the PM history file, we also report the average hours to complete both mechanical and electrical jobs. Another report tracks the PM Saves hours. Uptime statistics are available on line from another computer system, through a company-wide network that integrates various computerized applications.

The integration is the result of efforts of the information systems department and an outside vendor, Bearing Headquarters of Chicago, which supplies our storeroom inventory management system, B.Dot. The CMMS currently is being linked to that storeroom management system. At the same time, the maintenance area is being remodeled. Tools will be kept in the stockroom. Then the storeroom can anticipate maintenance's needs for tools. When a PM work order comes up, a copy will be sent directly to the storeroom and the necessary tools will be gathered and kept ready for the mechanic.

Determining maintenance intervals
The regular issuance and closure of PM work orders builds the necessary foundation to review and revise PM routines. By periodically reviewing them, we might find, for example, that frequently nothing needs attention. When that occurs routinely, we extend the PM interval by 2 weeks. After several cycles, if we see the same results again, we might push out the cycle another 2 weeks. Eventually we should notice maintenance needs beginning to occur, and we can leave the cycle as is. If we see things continually happening, needing lots of work, we can shorten the cycle by 2 weeks. Actually, we are just getting a feel for the process and are using this iterative process to help arrive at a good procedure.

It may be a hackneyed phrase, but especially with good software, what you gain from it will be commensurate with the effort you put into it. Like a good CAD/CAM or spreadsheet program, plant and manufacturing software must be viewed as a necessary tool. It must be clear that using and understanding this tool is part of the job description, the performance appraisal process, and the ongoing training requirements.

Because CMMSs function increasingly better as their history databases expand, the uphill effort seems tedious and unforgiving. Only when the peak is reached will some employees begin to appreciate the downhill aspects. Fortunately, that also is the time when the financial, productivity, and reporting aspects of a good CMMS start revealing that the results are worth the efforts. MT

Mike Trimberger is maintenance manager at Mirro Co., Manitowoc, WI.