Hello,

Generally, changes made during the early phases of a project, such as the design control phase, are easier to implement than changes made later on during the production phase. This is because changes made during the early phases are less likely to impact the overall system and can be addressed before significant resources have been invested. Standard Operating Procedures (SOPs) are often easier to modify than other documentation because they provide clear instructions on how to perform a specific task or process. On the other hand, the Bill of Materials (BOM) and design control documents may require more effort to modify due to the need for change controls and the potential impact on the product. The Master Record, which is a collection of all the work and changes made to the system, can be difficult to modify if significant changes have been made. However, if a proper retention system is in place, it can be easier to make additions to the current record. Overall, the difficulty level of making changes may vary depending on the specific project and the scope of the changes. It is important for project managers to carefully consider the potential impact of changes and to follow proper change control procedures to ensure the changes are implemented effectively and efficiently.

I agree with @sah67 in that in general, changes made at the beginning of a project are the easiest to implement. As time goes on, documents start to build up and information is based off of previous documents. More and more information gets referenced during the later stages of the project, so if a change needs to be made late into a project, it is often very difficult to trace back all the changes made. A system that keeps track of all information references may facilitate any changes that need to be made, but that can be difficult to maintain especially with a greater project scope and a large number of people working on it.

A company I interned at was big and had a lot of experience with change control in projects. The way they would handle large changes made during later stages of a project is by dividing the assessment of the impact of the change amongst representatives of each department within the project team. They also had a dedicated change control department to facilitate these changes. The change assessment would begin with the initiator filling out a form with the nature of the change being stated. This form would then be processed through change control and determine the need for the change and which departments are affected. They would then ask each person on the project team that are a part of the affected departments to look over any and all documents related to their department. For example, the quality person on the team would look over all the risk tables and risk analysis documents. After the impact assessments of all the affected departments have been completed, the executing of the change can begin. Although this is a fairly effective system since it divides the work of the change among the entire project team, it is still subject to flaws. Maybe someone forgot about a certain document that would be heavily affected by the change and did not report it. This document would be outdated for a long time before someone noticed it, which is a terrible situation to be in for the case of an audit.

Is there such thing as 100% effective change control? Is it possible to mitigate human error at any stage of the project?

Working in QA, I understand the complex, almost difficult degree of flow of change between the BOM, SOP, and the master data, but it is difficult to gauge another validated process to initiate, verify, and complete changes to an already established process without having some type of effectiveness check in place to suggest another route that has greater benefits. With practicality in mind, offering to change or suggest another process flow would result in more trainings and understanding of how to enact change from the already established method