This is a great question, and something I’ve been thinking about as well. No matter how minute the changes are, it doesn’t seem like a good idea to introduce multiple changes into a product at once. Whether that be a change to the product itself, or to a testing method. When there are so many specifications and components to a product, it becomes difficult to envision how those changes will work together. Plus there may be circumstances where one of your suggestions solves the problem but another one introduces a new problem. Even beyond cost, time, and documentation, implementing too many chances and having to deal with the consequences of that seems to complicate the project and its timeline. For the sake of simplicity and record keeping, it’s probably best to introduce one change at a time. A manager accepting these changes is also dependent on the manager and the project itself. A manager should consider the scope of the project and what it covers, and then decide if multiple changes are necessary. There might be cases where they are necessary and it ends up making the product better performing, more safe, and efficient, or it could end up making the product unusable.

This is a very similar issue that my simulation group is currently experiencing after our first simulation as well. Although we solved the issue after just one attempt, we have made three alterations and can not pinpoint what may have exactly solved the issue. This is obviously not good in the sense that we are not fully aware what exactly solved out issue. If my group and I were to come across a similar issue later down the line for another company this experience would not be able to be referenced and help us come to a solution more easily this time. However, I do believe that solving the issue by way of multiple alterations did save time, money, and resources. Instead of running the test possibly three different times the solution was able to be tackled in one go. In the grand scheme of things, for more complicated situations this may not be the case. Multiple solutions at once may cause new problems to arise and then these problems can not be tracked back to the specific modification. There are pros and cons for both arguments to be made here and is a question I currently experience for the first time following this weeks simulation. From a manager standpoint, I believe since the issue was resolved no harm is done to the product, but for a future standpoint I would like to know what exactly solved this issue.

@ej851996 this is a great question to ask, personally in our own group we addressed this issue in our Lessons Learned section. After the simulation we learned that implementing multiple changes in one design change proposal could cause other problems to arise that may have not existed before. As @hk425 even the most minute changes could turn into a spiraling downward effect of unexpected problems. By only including one change at a time if the product fails after testing the team can easily identify what change caused the problem and be able to easily address it during the next submission. If multiple changes are implemented in one submission and the product fails testing then it would be more difficult for the team to be able identify the change that caused the product to fail. Furthermore, multiple changes at a time could bring about problems that may not have occurred if only one change was implemented at a time.

This will be the major key point which we need to work on that. As our first stimulation was solved the main point which we learned is that if we are modifying our verification process first we need to decide which will be the major component that cause the failure in first place than we need to decide the criteria on which we can pass the stimulation criteria. This was actually a good example to properly understand the problem solving execution process for stimulations.