The most effective method of resolution when it comes to experiment failures is to troubleshoot what went wrong in the situation and come up with a plan of action to remedy the problem. With the bottle label simulation, we recognized right away that the water temperature was definitely something that would affect the label adhesion on the bottle. Then we thought of any other factors that would affect the adhesion, but we all agreed that the water temperature is the main culprit, and figured out that lowering the temperature would make the labels pass the submersion test.
The simulation helped with realizing how to figure out how to troubleshoot in a team in a real life project. I think when it comes to troubleshooting in a team based setting, communication and planning a route of action is key to coming up with a resolution.
In my opinion, I believe the most effective method for resolution is to initially brainstorm as many possibilities as to what caused the experiment to fail. Followed by some research on each suggestion, I believe each potential cause of failure should be ranked in terms of which has the highest probability of causing the failure. Then an experiment should be created and tested that makes the modifications to resolve the potential cause with the highest probability first and then proceed down the list as needed. The reason I believe this would be an effective method for resolution is to better determine the primary cause of failure. For example, in the simulation this week, my team believed that the temperature of the water was the primary cause as to why the labels were peeling off. Nonetheless, in the modified experiment that we proposed, we included additional changes such as letting the labels dry for an additional 30 minutes after being printed on. In this case, if the change in temperature alone resulted in a passed verification test then there is no need to decrease efficiency by increasing the time taken to apply labels to the bottles.
Like others have stated, a key step in troubleshooting failures is to take a step back and reflect on everything that led to the failure. In the case of the simulation, our group had individually reviewed and researched the issue, and then brought our potential solutions together to find the best method forward. In this case, we focused on ensuring the protocol and the actual testing procedure corresponded. Something that we had noticed was that in the verification procedure, the temperature of the water bath was set to a high temperature, while the temperature of the water bath was not defined in the original testing protocol. Small factors such as this could cause major issues, like it potentially had in the case of the labels. Other than paying attention to details, my group had also focused on the possibilities for human error within the testing process. To combat this potential method of error, we reinforced the procedure with more details. For example, we had included the use of gloves when applying the label and using a flat-edged tool to ensure that the label was placed flush on the glass with no air bubbles. We also specified to reinforce the edges of the label, as this is where we figured failure would begin. Minor details like this promote a more robust testing procedure which could prevent failures. Most cases will be unique, but in general, I believe most issues should be assessed and handled after taking a step back and considering the potential reasons for why failure occurred in the first place.
The first step to resolve a failure experiment would be finding the fault in the experiment and reevaluating the scope of the project. After you find the fault, alternative tests has to be discussed and performed until you find the correct solution to the failure. Testing is the most important and effective method of resolving a project failure.
I think one highly important area of learning that this simulation was able to bring about was to take a step back and look at the design inputs and specifications. If you scrutinize the inputs and review the protocol, you see there are added specifications in the protocol that may help or hinder the test. When I write verification protocols for my work in industry, I always make sure that if someone is able to read the inputs and then my protocol, they understand that the test is able to verify the performance of the product while covering any areas that may have operators run the test different with the same protocol.
The most effective method is to first make sure you understand your inputs and what you need as your output. Then look at what areas of the protocol are testing said input and areas of improvement that can help clarify any section. Then, look at any possible red flags for parts of the protocol that may have been added initially, but may have been unnecessary. Brain storming areas of failure is important to get the project moving, but I think that is only effective after some preemptive steps are taken.
Troubleshooting broken instruments and verifying the malfunction or problem is one of the key duties of a biomedical equipment technician. While faced with a product that isn't working well, it's a good idea to detach all of the product's components and inspect each one individually before the fault is verified. When it comes to research, there's usually a fairly structured protocol to follow, so modifying too many parameters isn't usually a choice. Furthermore, dramatically altering the experiment isn't a smart option because you won't be able to figure out what prompted the test to fail, even if the test succeeds the next time, you won't know which parameter you modified was the true answer.
In the simulation this week, we were tasked with correcting bottle label failure. When dealing with experiment failure in general, what do you feel is the most effective method for resolution?
The most effective method to resolve experiment failure is to troubleshoot. Treating the experiment as a piece of code that we need to deal with each line of it individually to make it work is the way to make the whole system work. We resolve the issue by testing each component individually. I work at a company that is going through the BLA situation, when the first experience of passing the product to the manufacturing failed, we had to test each part of the process individually to find the issue.
Trial and error! In order to precisely locate the focal point of a problem, it is important to begin from the start of the foundation and critically analyze each step of the process. In doing so, the malfunction can be fixed and the test trial can be repeated. Continued success, in this case proper bottle labeling, is achieved after the program have been debugged and the machinery is working properly.
First step: Determine and understand why the experiment failed.
Second step: Come up with a solution and test it. Repeat as necessary.
Method for resolution is all about trial and error using accurate and sophisticated possible solutions. It’s okay to keep failing, you will learn more each step of the way and eventually will reach a limit where the experiment passes. Sometimes looking at individual components will resolve the problem. Think of it as coding. When you debug your code, the best way to problem solve is to determine where it failed and go line by line leading up to that point.
I think the best way to go about solving problems is through a team approach. When trying to brainstorm ideas on the label failure it was helpful to gain insight from other team members and build upon each others ideas to create something that may not have been thought of on your own. I also think fostering creativity and not knocking down any idea as a "bad" idea leaves you option to greater problem solving success. It is also beneficial to start off with a clear idea of what the goal is as it can be difficult to stay on track sometimes and end up going a route that does not align with the original inputs.
I feel like the most effective method for resolution after an experimental failure is to take a step back and try and determine what caused the failure. Rather than going full steam ahead with more experiments and testing, it might make sense to look back on what has already been achieved and try to make improvements from there. It may have been a small misstep that had caused the failure or something minute was overlooked. By taking the time to think about why a certain component or aspect failed, you'll have a better understanding of the experiment as a whole and be more successful the next time around.
I agree to most of the posts here that first approach to a failed test is to take a step back and reevaluate the method from beginning. All protocols need to be proof read and every possible area of mistake needs to be restudied. Further technical research needs to be conducted to find possible failure causes and alternative test methods.
Finding the root cause is key but unfortunately not always possible. Another approach is retesting. But this has its own limitations since retesting is not always easy due to the long duration of tests and sometimes high material cost. For tests with relatively lower testing time and cost, it can go through trial and error as long as the project goal is met and falls within timeline. If not, the timeline extension pros and cons need to be evaluated.
When working on a project, it is inevitable that there will be some failures and deviations along the way. It is very unlikely that a project will occur with no mistakes or any complications, especially if the project is big in size. When an experimental failure, or any other kind of failure, occurs during a project, it is crucial that steps are taken to overcome and fix whatever went wrong in the initial testing. Examples of how to deal with this would be additional testing to new variables, testing the same variable in a different way, doing multiple of the same tests to make sure the result obtained was not an outlier, or even taking a step back and doing further research on the matter to create a new testing strategy. The most effective solution to this would greatly depend on the situation at hand but additional testing would serve to be a great way to overcome many kinds of experiment failures. Relating to the simulation project, the first test that a group can propose may not work at all or may not lead to the results that were expected. To deal with this problem, additional tests and changing some factors of the original test can lead to more desirable results.
In general, when trying to correct anything, I believe that google searching about the topic will give you a better understanding of what can be done to fix it. The first idea one should have before fixing anything is to understand what exactly they are trying to fix and search to see if other people have had the same issue as you beforehand. From my experience, I noticed that almost everything I had trouble with someone else had a problem with before me. So I believe the most effective method for resolving a failure is a google search.
I think as engineers, we should also be creative in resolving problems. Not all issues will have a google search answer. Even if there is, as engineers, it's our responsibility to make existing solutions better- cost wise and design wise.
Having an open mind in resolving issues is key. You may be solving a medical device issue. But you shouldn't limit your search withing the history of medical device developments and experiences related to it. Looking at other industries, such as automotive, can give you ideas which you can cultivate and modify further and apply in your field of interest.
