At my job I have been working on securing the PACs server for a set of new ultrasound units, however, the department who made the request is asking to have the studies sent to a server they have never used before. After meeting with cross-functional teams including the department, IT&S, PACs team, and management it was determined that in order to build software for this project it would take several weeks. That's when risk management got involved and pointed out the fact that the studies being performed were not being backed up which means we could potential lose record of patient studies. Consequently, the project was changed to first securing the patient studies with an external hard drive or to a temporary storage server. Given this example, I would say it is necessary to change a project in order to mitigate risks which is influenced by the severity and probability of a potential problem. Therefore, I believe it is acceptable to change a project when the risks outweigh the reward. Although, the project will now take longer and in turn be more costly, it is necessary to ensure no patient studies are lost which otherwise could have major legal implications.

This is an excellent question that deals with many issues and dynamics of a project proposal and verification protocol. I believe the sole purpose of the verification protocol is to be able to catch said mistakes and anything that was not caught before being released. I believe it's a good thing for something to be caught and to reassess what needs to be done. The other thing that might happen is a total recall and that is often considered as the worst experience for a company as it poses a bad image to the investors and stakeholders as well as it is an expensive operation to recall a certain product that is failing. In terms of changing the product, I do believe that it is best done before during the planning phase as it is the least financially detrimental process. However, if the change ends up benefiting the profitability of the product, I believe that would be best for the change to be made and be delayed and minimize any change needed later down the road. In my company, I have had to deal with a few times wherein change control, a procedure done to bring any changes to a validated system, the procedure was almost ready to be changed, but the team was able to find a new alternative step to be put in which was deemed necessary. So the deadline was pushed back further, but the change was implemented. 

At my previous job, unfortunately, there were times when we were at the very end of the project when we needed to go back and change something. To test a specific condition/constraint/requirement for a medical device, my company used the software Micro Focus ALM (Application Lifecycle Management). ALM housed hundreds of different requirements and corresponding to each requirement, there was a test written in lay man's terms that a tester needed to execute to verify a requirement. It was these tests where we saw the problems arise. Sometimes the way the tests were written quite frankly made no sense, were very redundant, missing steps, or very overly specific. It was times like these that required the test to be tweaked or rewritten. Luckily, most of the time it was just the test that needed to be rewritten and re-executed, however, there were also times that a requirement needed to be changed. In that case, we would need to report the defect and it would escalate up the chain of command until there was a solution. Typically, I would be able to report it to my direct manager and she would give me the go ahead to make the small improvement, but other times, we would need to wait a couple days until it ran its course with the higher ups and then we were told what to do. In this case, this would delay the project, but since there is nothing we can do about it, they would need to accept the new deadline we give them.

As you mentioned in your example, sometimes going back making a change in the project results with an even better situation than you started in. I agree with your statement that going back and changing a project can be costly and time inefficient based on how far along the project you are, it can be worth it if it results in an overall better product or increase in production afterwards. Similar to @Terril_Vallikalam, I currently work on a manufacturing floor for medical devices and the testing protocol that we use to calibrate and verify that all the devices that we ship out are working within acceptable specifications is constantly being updated or changed to optimize the amount of time spent testing to get more instruments out the door in response to their growing demand. At the same time, the materials and components of the devices themselves are constantly being changed and and upgraded as well to provide the results we look for in a faster amount of time. Waiting for all these changes to take effect does cause delays which costs the company money, but once implemented the resulting improvement in production rate makes up for that lost time and money quickly.