Case Study-Manufacturing: Plant Start-up
Background
- A company with engineering design faculties located in Michigan created a new and complex product-line manufactured and assembled at their plant in Tennessee. Many suppliers also provided parts and assemblies from various locations around the world, primarily Asia, Mexico, and the United States.
Approach
- In anticipation of the usual manufacturing start-up difficulties, the company determined that problems surfacing during production would fit into one or more of three categories:
- Engineering design problems (fit, form, function issues)
- Supplier quality problems (manufacturing, handling, delivery issues)
- Assembly problems (installation procedure issues)
The company, having made similar products for many years and having done numerous plant start-ups, assumed that the skills and know-how for a successful plant start-up automatically resided within its people and suppliers.
Dedicated team members were selected to represent each of the above 3 “problem” categories and were located full-time on-site in Tennessee. When a problem surfaced, the production-line was immediately stopped, alarms were sounded, and a representative from each of the categories was alerted. They immediately raced to that area in the plant to investigate. Crowds of idled workers from the line would gather to watch. Excited plant supervisors would arrive to apply additional pressure and demand to know why the line had stopped and what was being done to fix the problem. After some discussion (often heated) of the likely cause, an action plan was put in place to resolve the issue. For problems that could not be immediately resolved, a short-term “fix” was devised and implemented to get the production-line running again. The “fix” usually involved making modifications and corrections to various parts or fasteners, by hand, while a long-term solution could be found.
Additionally, there was a constant swarm of engineers and managers, from Michigan as well as from the supplier community, at the plant, to help resolve issues. Many of these team members made frequent, often “emergency,” trips to Tennessee, via commercial airline.
Several pieces of expensive and sophisticated equipment were purchased to help gather data and resolve problems. Individuals who operated this equipment, such as the Coordinate Measuring Machine (CMM), were arguably some of the best trained, most experienced people in the world.
Observations
- Lots of finger pointing. Problems were often complex, involving multiple parts and processes. Because of the nature of the job functions and the high work loads, people would focus on demonstrating that their own parts were made correctly and “in spec.” They wanted to alleviate the stress and uncertainty in finding a root cause and solution, while trying to keep up with the ever growing number of new problems. Instead of rigorous, thorough, collaborative problem solving, individual efforts were aimed more at showing that the problem was not of their doing, not within the realm of their responsibility or authority, and that the problem, therefore, belonged to someone else. This resulted in lots of finger pointing and time wasted at finding solutions.
- Everyone had an opinion. There was no standard, agreed upon process, tools & techniques, or approach to problem solving (e.g., Six Sigma, Theory of Constraints, Total Quality Management, etc.). If you’d asked management about using those standard problem solving, problem avoidance techniques, they would have said, “yeah, we do all that stuff.” But without a coordinated, deliberate, managed, and consistently applied methodology for resolving problems, everyone had an opinion about what was wrong and what needed to be done to fix things. Often the opinions proved to be wrong and wasted a lot of time and expense as people went down their own misguided paths in a desperate attempt to find a solution, or to point the blame to someone else. More often than not, an engineer would look at a part that was having trouble fitting on the assembly; see if it was made to specification; maybe call a design engineer in Michigan or at the supplier to get their opinion, and then report that all was fine with his “parts;” that it must be someone else causing the problem.
- Pre-production Vs. production. To mitigate production risk, the company had successfully demonstrated the ability to build the final product on a “laboratory,” prototype production-line in Michigan. When the real production-line in Tennessee was started, things that had been massaged and finessed by hand, in Michigan, at low volume, were now expected to be automated and run at high speeds. This required an incremental leap in learning and development that was not fully anticipated. The Tennessee production-line had significant trouble meeting its designed output requirements. Expectations for output, labor time, and investment in capital equipment had to be dramatically reset. The business model, including financial returns-on-investment was compromised.
- New & unproven technology. The company attempted to incorporate new and unproven technologies into the product in an effort to appear innovative and create excitement in the marketplace. New and unproven technology always has its “unknowns” and “surprises” that don’t manifest themselves until production starts and a reliable, salable product has to be created for a customer. Some of the technology was so advanced and unproven that it either had to be scrapped or fixes had to be invented and implemented that dramatically increased cost and decreased production output.
- “Are my methods unsound?”…”I don’t see any method, at all, Sir.” Many people charged with problem solving had lots of knowledge and experience with their own individual parts and processes, but few had any experience problem solving the systems issues that surfaced during production. A system is made up of many parts made by many processes, all put together to create a final product. What begins as a flat sheet of steel gets stamped, bent, machined, welded, drilled, painted, and then many component parts get attached to it until a final product is created. Hundreds, perhaps thousands, of steps might be involved in the process, any of which could be causing a problem that does not get detected until some parts much later in the process don’t fit together correctly. Few people had any training or experience uncovering the root cause of a systems problem. It was “every man for himself.” Management just expected an engineer to “figure it out.”
- Not the right training. The organization culture was deeply rooted in Japanese manufacturing philosophies. Many of the people in the company had read books or taken classes in the latest “just-in-time” methods. Strategically helpful no doubt, but it provided a false sense of capability when it came to solving complex system problems. The most competent people were completely overwhelmed in a quagmire of problems and debate about how to solve them. Not knowing what else to do, people would often turn to the data from the Coordinate Measuring Machine. The CMM measured numerous points on a part or assembly and compared the actual measurement with an engineering design specification. The CMM generated lots and lots of data, pages and pages of paper completely filled with statistical measurements in 8-point font on individual parts and assemblies. However, the people who were given the data and responsible for problem solving had little, if any, understanding of how to interpret and use it effectively. Like trying to read a book in a foreign language, it had no meaning or value. It became a distraction. It made people feel good that parts were being measured on sophisticated, expensive machines, but who really knew what all that data meant and if the size and shape of the parts had anything to do with a particular production problem.
- Weak teams. There were a lot of individuals, of varying skill sets, working frantically to solve problems. But there were few formal problem solving teams to brainstorm and collectively solve problems. The “team” was often just a list of phone numbers of engineers and managers to call to inform them of a problem. Lots of people were collecting information to give status reports. Lots of befuddled and fatigued individuals were working on their own to solve problems. Very few problem solving teams with the right experience, methods, and leadership were assembled to collaborate and work together to find solutions to problems.
- “Public Executions.” In an effort to promote good labor relations, a high profile, senior executive had an “open door” policy. Anyone in the company could send him an email or drop by for a meeting. Occasionally, a person on the production-line would send the executive an email saying that a particular problem was not being solved. The executive would go to the plant, meet with that person, and ask him for the name of the engineer that was assigned the problem. The guy on the line, who may or may not have known who was responsible, would give the name of the engineer assigned to his production-line. The executive would have that engineer called to that location. When the engineer arrived, much to his surprise, there stood the high profile executive along with many production-line operators, all waiting for him. Without attempting to understand the engineer’s position, the executive would berate the engineer in front of the operators on the assembly line and tell him to fix the problem NOW! “Until morale improves, the floggings will continue.” Public humiliations and screaming orders to “fix the problem now!” was discovered to be a limited and disappointing substitute for proven problem solving techniques.
- Lots of trips to Tennessee. When a problem surfaced that could not be resolved immediately, a call was placed to the engineers in Michigan or to the supplier. Engineers were expected to immediately jump on an airplane and get to Tennessee to help solve the problem. Reporting that, “engineers were on their way to Tennessee” made everyone feel good. Having several people standing around looking at a problem and scratching their heads was very comforting. But sadly and painfully it was no substitute for applying proven problem solving techniques. Many expensive, last minute, airplane tickets were purchased as people stopped what they were doing and headed to Tennessee. Meanwhile, engineering development work on exciting future products was interrupted.
- Short tempers, health, & safety. When problems occurred, production would stop, creating a product shortage. The company did not have enough products to sell to make the money it needed to stay in business. The pressure to keep the line running and get problems resolved quickly was tremendous. Tempers ran high. Some people suffered injuries because of hasty mistakes. Others had emotional breakdowns. At times a physical altercation would erupt. There was an almost constant barrage of yelling, screaming, cussing, and accusations of blame and fault finding. In an effort to save their own careers, some people would “throw others under the bus” in an often public and dramatic attempt to show that they were not to blame for the product’s problems. There were stories of divorce, alcohol & drug abuse, fights, over-eating, and more. One guy went on vacation and never returned; another came home from work to find his wife and kids had left.
- Career altering experience. Unable to produce the product in sufficient volumes and at the target cost, the company was quickly loosing money and “people changes” began occurring. Some people quit, others were demoted or passed over for promotion, and some were let go. Many people, now seasoned veterans, who had gone down a tremendous learning curve as a result this start-up were gone and soon forgotten. Perhaps most damaging was the number of highly talented, extremely capable people, the “rising stars,” the “best & brightest” that left the company for other opportunities, taking all their knowledge and experience with them.
One could summarize the company’s approach to problem solving as follows: Throw lots of people and expensive equipment at the problems and hope that they will be able to fix them. There was an “entitlement” sense of capability and confidence. People believed that because the company had done plant start-ups in past, they would be able to do it again. The company had many outstanding people and if those people got involved, the company was confident that the problems would get fixed.
Lessons Learned
- Common approach to problem solving. The company needed to define and implement a standard method for solving problems so that each problem could be approached in a similar way. For example, the Six Sigma process uses a DMAIC methodology to Define, Measure, Analyze, Improve, and Control. Getting the entire team to conform to a standard method for problem solving and decision making would have eliminated a lot of finger pointing, opinion, and debate about what to do.
- Sharing knowledge of tools & techniques. The team should have knowledge of the tools and techniques available to aid in problem solving, when and how to use them, their pros & cons, and lots of examples and case studies showing how they work. Team members should demonstrate and share their experiences, using video or PDF files to capture and document their knowledge. This information should be readily available and securely stored online so team members can access it when ever and where ever needed.
- Focused & relevant online training. Much of the training that was available in the marketplace was not utilized, and for good reasons:
- – Sending people to standard training courses was time consuming and very expensive.
- – The training was often so general as to lack relevance for the unique problems faced by the company.
- – The training was usually exhausting with classroom instruction for 8 hours a day and several days in a row.
- – The training was so overwhelming with information that most people mentally “checked-out” very quickly.
- – Unless the team member was actively using the training information, it was quickly forgotten.
- – Many team members were not sure what to do with the knowledge or how to apply it in meaningful ways.
- – And some team members were rumored to party all night, rendering them useless in class the next day!
Needless to say, managers did not have the budget or time to send a lot of people to those kinds of training classes. But some people, whose jobs were directly related to the training content, benefited greatly from it. What was needed was a “bridge” between what the experts needed to know and what a problem solving engineer needed to know to make use of the tool or technique. For example, the CMM data was requested by everyone, but only a handful of people knew what to do with it or how to interpret it. A few quick training videos made by the CMM guru showing how an engineer could use the data would have been helpful. As problems are solved and lessons learned, quick online videos and documentation could be easily created to help others learn from their experiences.
- Strong problem solving teams. For problems that could not be immediately resolved, a meeting of the affected parties should be assembled to collectively agree on a plan, using proven methodologies, for solving the problem. This would have ended the endless finger pointing, debate, and confusion about what to do and what was being done. Dumping a problem on a lone, often inexperienced, engineer and expecting that person to magically solve the problem is a bad approach. There was no shortage of people, just a shortage of good team work and method.
- Give me some of that old time religion! There were several guys around the plant that were long term veterans of the “start-up.” They had decades of invaluable experience. Many were retired engineers who had spent their careers resolving manufacturing problems. They had been brought back as contractors to help get the plant started. These guys had tons of wisdom to share, if only a process existed for them to do so. Younger folks would have been wise to spend some time with them, learning their many techniques for problem solving. Sadly, the experienced veterans were often ignored as being too “old school” for the slick new digital age kids with fancy computers. As a result, much of their hard earned knowledge was lost or wasted. They serve as an inspiration for the benefits of TeamReadiness. They would have gladly shared their knowledge through a facilitated TeamReadiness approach to knowledge capture.
- Technology development. Using new and unproven technology may be necessary, but for sure it is risky. Having a method for demonstrating the technology’s development time, performance, and cost prior to production is essential if risks are to be mitigated. Doing significant R&D during production can quickly compromise the program. The more technology that is still being “developed” during production, the more necessary to have online tools and visual documentation to collaborate on development activities.
- Online documentation & collaboration. Online and immediate access to videos and photos showing problems, or showing solutions to problems can quickly engage experts from all over the world in the problem solving process. Engineers in Michigan and from the supply base can quickly see the problems and work to formulate a solution, without having to jump on an airplane and fly to Tennessee. Additionally, as problems are solved, documenting what happened and how the problem was solved can help ensure that it does not happen again and inspire others to use similar problem solving techniques to address their issues. It can save a lot of time and costly airplane tickets traveling to the manufacturing plant.
- Build morale and esprit de corps. As people seek and find solutions, enable them to post findings and solutions online so all can see, learn, and help problem solve. Let people post comments with ideas or suggestions to help the cause. This will speed the problem solving process, and reduce stress and anxiety. It will encourage and unite team members towards a common objective and provide recognition for a job well done.
Quickly create and implement highly visual, easy-to-use and understand documentation, online training courses, and collaboration tools for problem solving and continuous improvement.
DMW
Copyright © 2007-2011 TeamReadiness, Inc.