In dealing with failures, I think the first step is to list out every aspect that may be causing the failure. From there, the aspects can be prioritized based on which seem more probable to cause the failure as well as which would be easiest to test. If at all possible, it would also be beneficial if tests can be used for multiple aspects. This would end up saving time, if multiple aspects are tested at the same time, rather than waiting for one set of results before testing another. 

A good starting point might be to check whether your test conditions are just too strict, what if over-verification is performed. I think that it is always valid to ask yourself after a test failure whether that test was absolutely necessary and whether it could be modified before thinking of design modifications. Identifying why the test failed might be critical though in changing the test or design.

First, I think it is important that you plan for any possible failures that could occur with your project in the very beginning. For example, in this week's sim, calcium sulfate hardens when exposed to water so the team should have anticipated that this issue might occur and should've have come up with a plan to deal with it. When something fails, I think it would be beneficial to go through every step of your procedure/experiment and investigate if it could have contributed to the project's failure then make the necessary changes. 

Great question Mark! When it comes to failures in a project, I agree that testing out all parameters can be a waste of time and money for a company. One thing I learned from working in a medical device company, is determining a root cause for a specific failure. To determine a root cause, various methods can be used such as a fishbone diagram or a 5 why’s tree. The fish bone diagram is a method where all the possible factors that may have contributed to the failure are listed out, and then each branch asks the question “Why Did this happen” and more branches are made listing out the answers to the question. Some branches can be ruled out as to contributing to a failure while others point to the root cause of the failure. Similar to the fish bone diagram, the 5 Why’s method allows one to get down to a root cause of the failure presented. The problem statement is listed and the question “Why” is asked. All possible reasons as to why the failure occurred is written down. From there, the same process is repeated for each statement made, questioning what led to the failure. In most cases, after questioning the statements 5 times (could be more, could be less), the root cause presents itself. These are just two efficient strategies that I have seen work best in the industry in terms of tackling failures.

When any failure occurs, the first step should be to study the failure for what exactly happened. Its important to understand the details of the failure before attempting to remedy the situation. As the popular saying goes, “The devil is in the details”. More so, I think that with any failure, the team should meet to discuss potential solutions together. An active approach with everyone involved would help to brainstorm potential solutions and fix the problem as quickly and efficiently as possible. During this meeting, it would also be a great idea to list down everything that is being suggested such that there are multiple options for moving forward in resolving the issue. Depending on the problem, it may be important to look at the requirements and protocols again to see if maybe something was not done as it was supposed to. The reason for an issue could be anything from how something was done, or the materials used, to simple human error, so all potential reasons for the problem occurring should be considered. I am sure there are more direct responses people have used in industry, so if anyone does have any relevant experiences, it would be great to hear specific examples.   

I am agree with previous comments but in general I think if we face to any failure in our project we should do some steps to make it correct or if it's not possible to correct them do these steps to prevent facing these kind of failures in future, these steps could be: Move Quickly (as soon as we suspect that a project is about to fail we should start to make correct), Ask for Help (it could be helpful if you ask help to get outside perspective), Analyze the Data (once you are positive that your project has failed, and your team is prepared to handle the consequences begin analyzing all the data), Don't Give Up (project failure is always discouraging but you can't let it get to you), Conclusion (failure doesn't have to be the end, and in many cases can be the beginning of an even bigger success so it's very important to learn and remember from what we faced).

I would say listing out all the possible difficulties or problems to be faced during the project would it easier for the team to be prepared for the risks beforehand. Unexpected failures occur most of the times so be prepared for such problems with giving possible extra time for each event and proposing necessary tests at every major step which might detect the risks. Try to avoid unnecessary testing at every parameter which is a major waste of time and delays the project. Check the resources and be open to alternative solutions when experiencing a failure of the project. This helps saving the time and finding fastest route to finish the project.

When I think about failure as it relates to project services, it can be seen as believing to have had the answer to a solution, but once following through the expected outcome did not occur. The best solution at this point would be to research the problem. When conducting this research, one should ask questions to expert managers who may have experienced a similar problem and then executing the project. Seeking out advice and collaborating with individuals who have a vast knowledge base on the specific issue will save time, money, and resources. It is extremely important that research is performed to understand the problem and why it failed during the first attempt. 

I think it is important to find out the root cause of the failure first and then analyze how to make changes to that particular parameter. Therefore in my opinion, it is unnecessary to look at every single variables and parameters and rather it would be worth focusing on that particular parameter that has caused the failure. 

In my opinion, the most efficient strategy to deal with failures in such scenarios is to brainstorm potential causes. With a list of potential causes compiled, the members of the team can then assess and rule out those with the least probability of being the root cause. This assessment should also consist of research into similar scenarios or projects to determine whether such outcomes were experienced for prior studies or projects. As for running tests in parallel, I personally believe they can be an efficient use of both time and money if a team is unable to determine a potential root cause of failure. On the contrary, if the team did not take the initiative to research causes of the failure prior to running multiple tests then such a strategy could be considered inefficient. Personally, for this week’s simulation, my team and I began to directly perform research on alternative materials to use for both the carrier and the solvent rather than seek to determine which component of the mixture may be causing the failure. Therefore, our tests could have been more efficient if we took the initial initiative to root out whether the solvent or carrier was causing the failure through research into scientific studies. Overall, I believe the best strategy to root out the cause of failures may also be dependent on the time-sensitivity of the project as a team may not have the time to take a chance running fewer tests.

Testing in parallel is a great way to find failures in any test taken. Although it would come out to be more expensive, it does save a great amount of time as apposed to testing one product at a time. This will help on meeting the deadline, however, there is always a budget that has to be maintained. In the case of failures, each test's failures does yield information that can be used for the upcoming test. 

This post thread brings up some great points regarding time sensitive experimental testing. Over the course of last week's simulation, it took our group several attempts at a solution before realizing that we needed to propose an experiment that tested multiple factors, such as different carriers, different temperatures, etc. The most effective method we found in order to achieve this was to have several different experimental groups within the experiment. Before we reached this solution, we were testing one factor at a time and over longer periods of time. This type of experiment would never get approved by management, especially when time is of the essence. Moreover, as mentioned above, it is important to investigate only possible solutions to the factors that are the root cause of any issues within an experiment in order to stay on track and not stray from the task requirements at hand. For example, I know my group also proposed an experiment that required animal testing, but this was unnecessary for what was asked of us and would ultimately be a waste of time and resources. The biggest lesson I learned from this simulation is that there is a fine line between being creative and being too creative in cases where there are pressing deadlines.

I think to dead with failure in the project we should first find the exact reason for failure in the project then figure out how to solve or prevent form that so for example if the reason is the communication gaps we should clear what tool our team will use to communicate and whether it's email, text messaging, a chat service or anything else we should make sure everybody in our team understands what's expected and can use (have tools) the technology which has been selected, another example can be when for example the problem is unrealistic expectation we should make sure we need to have realistic expectations in place and understood by all the project stakeholders that can help us to have a better chance at successful project completion. 

I agree with all the posts which I am reading above, failure are the pillars of success I believe so. It is very obvious that a project might not work out the same way which it was supposed to be. Failure is a part and parcel of life and similarly in most of our simulations we can see that the analyzing the failures or the causes which make the project fail was very important. A better path can be chosen or materials can be chosen differently which will help in the betterment of the product. I am always curious about the timeline which is being set by the project managers and if the timepoints are not met with the work it becomes very difficult for the subsequent steps to follow in a streamlined manner. At that point of time, the project manager should step up and look to uplift the pace of the team such that it matches with the alloted guidelines and the goals are achieved at the end of the day.