As a validation engineer, in the event that the customer had a complaint, I would first record how we didn't meet the customer need. I would hold a meeting with the customer representative and discuss the changes that they'd like to see. I would then discuss with my team if the changes were possible. In the event that it was that we caught that it didn't meet the customer need after creating a prototype, for example, I would brainstorm with my team about what we can change to make it work. Whether that be a different material if biocompatibility tests were not acceptable or actually using the device was clunky and inconvenient. Doctors for example, need devices that are (relatively) easy and comfortable to work with. If the device we produced just complicated whatever procedure they typically do, then we failed to meet their need. 

I agree with sm2744. Communication with the customer is key when customer needs aren't meant. I would try to figure out where we went wrong in our initial design where the customer wasn't satisfied. I would then talk to my team to see where the miscommunication or confusion resulted from to see if there was anything we could have done different to prepare for this project. I would confirm our shortcomings with the project manager. Finally, I'd reconvene with the team in order to work on a new prototype that would satisfy the customer.

Similar to how @sm2744 responded I too would also notify the appropriate people as soon as I found out that there was a criteria that the device did not pass during the testing phase. It is important to assess which customer requirement was effected with the failing of the test as well as notifying the customer of the situation. Furthermore, I would revisit the test and see if there could have been an issue with how the test was administered or if the actual product/design was flawed. Although I am confident in my abilities, considering that I'd be handling potentially millions of dollars of merchandise, I would make sure to get a second opinion before making any decisions. I would also contact that design team to see if the test that failed was a potential issue that was already predicted to have been occurring. If this is the case then I would use an alternative design that was proposed and retest the prototype. However, if this is an absolutely unexpected issue then I would consider going back to the beginning of the design process and evaluating every part and criteria of the device to narrow down why the device failed the test and how to fix it in order to meet the customer need. If worse come to worst and the customer need cannot be completely met, I would try and discuss with the customer to come to a happy medium where I would be able to adjust the device and the customer would still be happy with the product.

As a validation engineer, I think the first step after a failed validation is to question why the product failed validation. Depending on what it is that caused the failure, there may need to be modifications to the product specifications or the experiments being used to test the product. Once the modifications have been made, I would test the product for reproducibility and accuracy of the expected results. I also agree with @sm2744 that meeting with the consumer would be crucial to discuss the modifications before execution. By explaining the reasons and justification behind the changes, the customer would have the opportunity to provide their input on the changes and provide further instruction.

As a validations engineer, if a product doesn't pass, I would first make a note of what aspect(s) of the product failed and report it immediately. It is important to report any failures immediately in case the root cause of the failure is due to a manufacturing error. I would then look into why these aspects failed and what could have caused their failure (lack of thorough inspection earlier on? machining problem?). I would also look at other items of the same product to see if the same aspects also failed with them. This is to see if this could possibly be a repeatable offense and also clue in that this is a manufacturing error. After gathering my own thoughts and ideas of what the problem could be, I would get in contact with the team and notify them of the problem if they hadn't already heard or known about it. Then as a team we can discuss what the problem is and go and determine if it is true or not. Once the problem is confirmed, the team will discuss what solutions can be made to alleviate the situation and how this problem can be avoided in the future if possible. 

Like most of the responses above, I also think that when a validation or verification test fails, an engineer must first record the failure in the documentation available to all team members. Following this step, a design review meeting should probably be held for all team members to figure out why the device failed a particular test. Holding a design review meeting ensures that all team members are given an opportunity to express their opinions on what caused the failure and what can be done to correct the issue. Also during this meeting, team members should ask the following questions in order to come to a conclusion on what the next steps should be: Was the original test performed correctly? Was it a fault in the design that caused the failure? Does the original test design make sense? Upon answering these questions, team members will be able to decide what they should do next (e.g. change the device design, change the test design, etc.). It’s important that when answering these questions, team members should only change things according to what the customer wants. In other words, the customer’s opinion still matters. A good project team communicates effectively throughout all stages of the project, but during times when setbacks or errors occur, effective communication is extremely important to help the project move forward from the setback smoothly.

As the prior responses have given great insight on what to do if they were a validation engineer in that situation I would like to point out the importance of communication. Each of the prior comments pointed to communication with the customer about the missed customer need or to holding a design review meeting with the team to discuss any confusion or how this mistake possibly occurred. In each scenario given, it highlights the importance of communicating before, during, and after a problem has been addressed. In this situation a problem has been noticed close to the very end of the project cycle and not one singular person can fix this issue. That is why, as a validation engineer in this situation it is best to communicate with the team, customer, and any other important people to try and gain as much feedback as possible to ensure the best way to fix this problem is determined.

During my capstone project we had to do something very similar to a verification and validation process. We did our verification tests to ensure that it met the customer needs or rather the design inputs which it passed all of them. But when it came to the validation tests and ensuring that the device was able to complete the specific task needed, it did not work on the first couple tries. Each time it failed we focused on what part specifically did not work, whether it was the design of a certain part of the connection of the parts together. If it was a design of a part we would go back to the measurements and see if we were off on our tolerances or if it needed to be changed. There were some occasions where the material of parts needed to be changed as well. If it wasn’t a specific part then it was most likely a connection that did not allow for correct movement. When this happened we ended up going to our mechanical flow chart and seeing how it should be moving and each part that allowed it to move. Once we knew how it was supposed to move we went back to the device and looked at each part and saw where it was not moving or where it was possibly restricted. And then we would work from there. One thing to keep in mind was that when we changed one thing we had to make sure that it did not mess up another because then that created a new problem. It can be hard on some occasions to fix what's wrong but it helps when a group takes the challenge and even better when each person has different skills and can see the issue from different viewpoints.

@mb776 To piggyback on this line of thinking, it is really important to figure out the cause of failure. If it was a misunderstanding of the desire of the customer, that will have a very different response versus if the engineers were not able to create a good product. If the engineers just were not able to create something that is a good product no matter who the customer is, then the problem is huge. Either you need to hire a new engineering team or the idea is not currently a feasible product that your company is able to produce at this time. If the customer's desires were misunderstood, that is a lot easier to deal with because it is not a failure in engineering. You still have to go back to the drawing board and do a lot more work, but the work is possible for your company, unlike the other situation.

When I was reading the initial forum post, the first thing that came to my mind was the part of the lectures where D. Simon emphasizes the planning phase because if tests fail during validation then the process would have to go back to the initial phase where inputs would be changed. Of course, this does depend on the severity and type of the failure and also the "level" of input that is affected (risk level of input or importance of input to overall device). However, there is always possibilities where planning doesn't always work and the process has to be reversed to edit the inputs and customer needs to ensure all tests are passing. This is where I would agree with some responses above stating that the customer needs are indeed the main focal point of validation and the company positions responsible for discussing the customer needs would be the most important in this situation. It was interesting to read an actual validation engineer's point of view on this question and see how failures are handled in the real industrial world! 

Of course when a product or device fails a validation test, it can be frustrating to get it to start working again. However, as mentioned by others above, there are ways in which this process can be made easier, such as looking over prior documentation (assuming it was done thoroughly and well), communicating with members of the team, and fully understand what the issue is. During my senior capstone, I had to go through this process on multiple occasions for the device we were developing. We looked at what was going wrong specifically and see if there was simple solution to it (was something not installed properly? was the part used faulty?). When there wasn't a simple solution, we had to look at all the possibilities as to why something would not be working and identify ways in which we could test for these problems and if they could be alleviated. We would also look at our prior documentation, such as our design ideas, meeting minutes, and design evaluations to better understand why we made certain choices in our design and to also see if there were any flaws in our past thought processes. Following these paths, we were able to locate, identify and rectify the issues we were experiencing with our device. 

If something doesn't pass in the validation process, much like the other I would have a sit down with the client/ customer and discuss the details of the issue with them. I think a key important to rectify any mistakes would be to look over previously recorded progress checks to verify exactly what the issue could be. Then we would have to convene as a team and discuss what was discussed with the client and start the process of planning to adjust the product to fit the client standards. Many times, the issue with validation stems from the verifications, so that could need to be combed over. Considering this takes place before clinical trials had started, and the product was changed according to client standards, the parameters for the trials would have to be changed accordingly. This should be recorded in a  progress check, so that team members can refer to this should a similar issue arise in the future.

I think an important initial step would be to really understand all the components that are going into the design and the project itself. Understanding it well will help gauge what the following steps should be in the process. It can help decide if the validation tests should be different, or if there was something fundamentally flawed in the project's initial design. There could be extreme cases that validation failure can lead to scrapping the entire project or forcing a complete rehaul of the design and/or purpose. It is definitely important to have the full picture in mind before any big decision is made and as the validation engineer, having that perspective is important. Each case will be different than the last so it is crucial that there is a structure on how these problems are addressed so that the least amount of uncertainty and failures are happening. 

In terms of validation, I believe that the key is to always go back to the customer. By definition, validation is the process of ensuring that the device meets all of the customer's needs. If the device fails in a certain aspect, it is essential to go back to a customer for feedback/suggestions. Based on this feedback one of two things may happen: the device will be changed to meet the customer's need or the customer's need will be adjusted in order for the device to be able to practically meet the need. In the end, validation relies on customer satisfaction, so all points of failure must be discussed with the customer itself in order to prevent larger issues as project development continues.