Website update in progress! You might be logged out of your account. If this occurs, please log back in.

Website update in progress! You might be logged out of your account. If this occurs, please log back in.

Sign Up

Please use your business email address if applicable

A Good Blamestorming Session

A Good Blamestorming Session

Customer complaints had reached a boiling point. They were considering taking their business elsewhere. Nearly every shipment had a packaging issue that left the product exposed. The quality department traced the defect back to a single packaging system.

Unfortunately, this isn’t the first time this system has caused headaches. The operations and maintenance departments had become adept at pointing the finger at each other, but if customer service and quality could work it out with the customer, the area manager didn’t mind. The area manager was known to have a short memory and would focus on the business of the day. No failure investigations had ever been conducted in the past. When customer complaints came in, the operations and maintenance department would do their usual dance and at the end, the manufacturer would be called in to inspect the equipment. No review or follow-up was ever done. When the suggestion of a root cause analysis (RCA) was brought up, the area manager would make assurances that the issue was well in hand.

An emergency meeting was called personally by the plant manager. People from operations, maintenance, quality, and engineering/reliability were in attendance.

The area manager, feeling the pressure, kicked off the meeting by saying, “I want to spend this much time on the problem and this much time on the solution,” while gesturing with his hands to spend little to no time on the problem and a lot of time on the solution.

The reliability engineer replied with, “Sir, we don’t know what the problem is to come up with a solution.”

“Yes, we do!” interjected the operations supervisor.

“The machine’s catch is messed up and keeps ripping up the package.”

“Is that correct?” the plant manager asked, directed toward the maintenance supervisor.

“No, we’ve called in the manufacturer four times in the last year to go over the system and each time was able to run the system without producing any defect product,” replied the maintenance supervisor, who continued with, “We have the reports from each visit.” It appears the usual finger-pointing was about to begin.

The reliability engineer cut in with, “Do you know the definition of insanity? We’ve taken the same approach to this over and over again with the same result.”

“I agree,” said the plant manager, who continued directing his attention toward the reliability engineer. “I want a full review and analysis of this. Spend more than this much time on it,” making the same gesture with his hands to indicate a short amount of time. “When you’re done, recall this meeting.”

The reliability team quickly went to work reviewing the manufacturer’s reports and manuals, operator logs and procedures, and maintenance records, observing the system in operation, and interviewing numerous parties. When the investigation was complete, the reliability team recalled the meeting.

“So, what did you find out?” asked the plant manager.

“The issue does center around the catch as operations stated, but it isn’t broken. The packaging is meant to slide into the catch and not just pushed or pulled into position. The different operators don’t all have a clear understanding of this. Some slide the package into the catch, while others just push it into position. The operator’s procedures reference the manual text and says to ensure the packaging is in position, but doesn’t explicitly state to slide the package in. The operators that understand this are the ones that were on duty while the manufacturer’s representative was on-site evaluating the system. With that stated, there isn’t anything stopping us from incorrectly feeding the machine. With a proximity switch and programming interlocks, we would be able to notice this before we start a run. In short, if we better define the operator’s procedures and retrain and install a safety interlock, we should be good,” replied the reliability engineer.

Everyone in attendance agreed with the recommendations and the meeting concluded. The recommendations were implemented and tracked for months. Customer complaints regarding this issue dropped to zero and the project was considered a success. After the customer service department announced the improved customer complaint numbers, the reliability team received an email from the area manager with the subject: “I have a couple of things for you to look at.”

Brendon Russ

As the Lead in the Americas for Reliability and Asset Management, Brendon’s responsibilities include oversight of Reliability Engineers and work with leadership to demonstrate the value of Reliability and Asset Management. Over nearly 20 years, Brendon has developed and overseen programs such as preventive maintenance, root cause analysis, condition-based maintenance, reliability focus design, capital projects, CMMS implementations, SAMP development, cross industry baseline/gap assessments, and OT/IT convergence projects. Brendon has received a Bachelor of Science in Mechanical Engineering, a Master of Business Administration, a CRL-BB, and various certifications in various condition-based maintenance and non-destructive technologies.

ChatGPT with
Find Your Answers Fast