SECTION A [40 MARKS] Read the case study below and answer ALL the questions that follow. ROBOTS FAIL TOO Within the recent month, there have been two sudden robot failures on two different tools during a build cycle. Lisa, the manufacturing engineer, has notified Nick, supplier quality engineer, about the failures, assuming that the two robots have some bad parts. She has requested that the two robots be sent back to the supplier for rework, even though no root cause has been identified. But, it seems that such a move has caused some to question where the blame should be placed. OUR BUSINESS The IEM Company is a high - tech company producing customized Ion and Electron Microscopes. The applications of their products can be used in a variety of fields, from academia to high - tech industries. Their customers are given the options of customizing the product to meet specific process needs. The companys financial profile shows that their sales revenue last year exceeds $400 million. The company is currently upgrading their tools for the improvement in the imaging and wafer transfer system. This is required to help expand the market size and to meet customers satisfaction. This upgrading project was executed and is now in its operational stage. WE HAVE A PROBLEM AND IT IS NOT OUR FAULT Nick: How do you know it was the suppliers fault? Is there a chance that we damaged them during handling or installation? Lisa: According to the Reject report, the technician said that the two robots were working fine for two weeks after installation. But then there were a few error lines such that the wafer transfer was stopped. Nick: We dont really know if its the suppliers fault or not. If it is their fault, those robots wouldnt have worked for two weeks, would they? Lisa: True. However, anything is possible. I think we should send these machines back for them to check it out. Nick: We cant just send them back without a well - documented potential causes report. Lisa: We dont have time to do any tests or troubleshooting. They have the experts in their company who can test the robots to find out whats wrong with the machines. I suggest we send them back and save ourselves some time. Nick agreed with Lisas suggestion. The two robots were sent back to the supplier for investigation. One week later, similar problems occurred on several other machines. The problem became so big that the issue was elevated to Donnie, a manufacturing engineering manager. Donnie asked Lisa to form a team to identify the root cause of the problem. Lisa agreed to put together the team to brainstorm the root cause and the next course of action. She promised to follow the following steps: goal definition, root cause analysis, counter measures identification, and standardization. Lisa called a meeting with Nick and the other two manufacturing technicians, Joseph and Ryan. The team was working to get a list of possible causes for the problem. As a normal procedure in the teams analysis, the first thing to do was to create a fishbone diagram Joseph: As a starting point, can we capture what actually happened before the error message showed up on the screen? Ryan: I dont really know what happened. I was just starting to teach the robot, following our procedure, but then the error message showed up. Joseph: That doesnt make any sense. If nothing changed on the system itself, we shouldnt have gotten the error. Theres got to be something changed on the system. Lisa: Lets create a fishbone diagram for potential root causes of this problem. The team brainstormed using the affinity diagram method. The purpose of this exercise was to ensure everyones input was captured during the process. They determined the amount of time to be spent on brainstorming, and then went through each idea that each member came up with. When going through each idea, they also decided whether those ideas were candidates for root causes. If any of the ideas didnt make sense, they put them aside and noted them as possible but not likely causes. Once the ideas of potential root causes were laid out, they started their fishbone diagram by grouping the potential causes into larger categories such as Software, Mechanical, etc. The fishbone diagram would be used as a tool to communicate with upper management as well as field personnel showing all possible items that needed to be checked if and when the errors occurred again. Case derived from: Case studies in Project, Program, and Organizational Project Management. https://saidnazulfiqar.files.wordpress.com/2008/04/case-studies-in-project-program-and-organizational-projectmanagement.pdf

QUESTION 1 [40 MARKS] 1.1 Considering the case study provided, are there any noticeable problems relating to the quality management approach implemented at IEM? (10 marks)