It has come to our attention that a large number of people in the oil and natural gas industry are struggling with the topic of management of change (MOC). Although the details of implementation will be very different for different situations, great MOC programs are developed from the same basic foundation.
The first fundamental aspect of MOC is the actual change request. What change needs to be made? What are the individual specs for the materials needed? What plans and documents need to be included in the change request to fully communicate what is needed? If you can’t clearly communicate what it is that needs to be changed, then the change can’t be implemented properly.
The next aspect of MOC that needs addressed is the reward of the change. Why am I even making this change? Each change should be fully connected to satisfying a business objective. Again, specificity is important in addressing these concerns. The reward needs to clearly satisfy a business goal. If it does not, why even bother taking the risk?
Possibly the most important foundation of the MOC program is the evaluation team. The MOC evaluation team is responsible for the objective evaluation of the requests. Members should represent different areas of expertise throughout the organization, with different experiences under their belt. There shouldn’t be any aspect of a request that the team can’t properly address and evaluate. Team members should be respected among their peers, and confident enough to speak up when they have concerns. If these criteria are used, your organization will select a MOC evaluation team that can handle any challenge put in front of them.
The API Spec Q2 requirements take a risk-based approach to quality management. When making changes, risks must be identified and measured by level of acceptability. Risks that are deemed unacceptable must be paired with mitigation plans. These plans are then designated to be carried out before, during, or after the implementation process. The purpose of the mitigation plans is to help bring the risk down to an acceptable level.
The next area we will address deals with the approval aspect of MOC. Many organizations get into trouble in this area, confusing the need for approval with the need to inform. It’s important to note that every change doesn’t have to have the same approver. A great MOC program should have an approval matrix describing who needs to approve which type of decisions, as well as a list of people who “must be informed”. If your organization gets these steps right, the approval process will be quick and painless.
This leads us to the communication section nicely. As stated before, there are those who need to “approve” and those who “must be informed”. We need to track our communication efforts with respect to the MOC. In other words, any message and corresponding response must be documented. The person responsible for sending the message is also responsible for getting a confirmation from the recipient. This means after the change is communicated, a receipt confirmation should be requested. Also, it is important to make it clear to your organization that an email response should be expected from the recipient. Simply flagging it as “Request a Read Receipt” isn’t going to get the job done. Once the recipient has responded, stating that they have received the message and understand the information, then the responsibility shifts to them to carry out the appropriate action.
Implementation of the change
First, we will want to execute any per-implementation changes and corresponding mitigation efforts that were identified. Subsequent to the implementation we will want to perform any post-implementation tasks that are required. Example would include updating procedures or modifying training materials to address the change.
Next, we need to confirm the effectiveness of the change. Once the change has been implemented it is important to make sure that the change does what it was intended to do. Sometimes organizations experience undesirable results. When this happens, we must determine if the system should be restored to the old model, or develop a new MOC to address the unintended results.
Finally, we need to follow-up and confirm the success of our mitigation efforts. This ensures that the new system will not produce any unseen difficulties for the organization. Also, we need to verify that the change is going to leave the system running smoothly and safely. Once all of these steps have been completed in their entirety, then the change can be closed.
After closure, we still have one final but critical step remaining. We must perform surveillance audits to confirm the changes were carried out consistently and the system is being used as intended. Comprehensive process audits are a great way to determine implementation results. Randomly selecting a few processes related to the change and auditing them is a good way to achieve this. It is important to remember that audits should be performed at periodic intervals. The frequency of audits depends on several factors, but should be scheduled in a manner that guarantees the sustainability of the change.
Accupoint Software is a global provider of innovative compliance management systems. Our integrated platforms streamline business processes, increase customer satisfaction and help organizations navigate today’s complex regulatory requirements.