A robust document control management process lies at the heart of a quality management system (QMS); almost every aspect of auditing and compliance verification is determined through the scrutiny of documented evidence. As the saying goes: “If it’s not documented, it didn’t happen.”

Change management is the process responsible for controlling the lifecycle of all changes within a QMS system. It is a formal process used to ensure there is a standardized method and procedures in place to drive efficient and prompt handling of all changes while effectively communicating the changes to the impacted areas prior to implementation.

1. Request a Change

A change request is the documentation used to request the actual change to/for your process, system, etc. Whoever is requesting the change owns the actual request and needs to explain the reason for the change and ensure all impacted areas have been identified and included in the review and approval of the change. When defining the change, it’s necessary to have the request in hand with all supporting statements. This should at a minimum include the following:

Change Request Form: Clearly and concisely outline what needs to be changed, so the impacted areas can review and analyze.

Reason for the Request: Detail the overall business or customer impact, and identify the projected timeframe of the project.

Expected Completion/Implementation Date: The requester should provide an expected due date. This doesn’t mean the change will be completed by this date. But it proposes a turnaround time for the team to complete their review process allowing for alternative options (if applicable).

Expected Outcome: This should explain the need for the request. Outline the desired outcome/benefit expected from the change.

2. Submitting and Reviewing the Change Request

Once the change request is documented, it’s submitted to the change control coordinator/project manager. The review process varies dependent on your organization’s process. In most cases the request is forwarded to all areas potentially impacted to review the requested changes. This allows all members a chance to ask questions, suggest additional changes, or provide alternate options before making the final decision. The process should hold the reviewers to the expected input/feedback turnaround time.

3. Changing the Request Response Document

Once the request has been reviewed, the document response should provide recommendation(s) from the reviewers on which represents the best choice.

The response may include:

Proposed Solution: Should include options on how to respond to the change request.

Proposed Timeline: An estimated timeline of alternate options/choice presented.

Impact: Minimally explains the cost of the changes, the impact on the timeline and potential quality results and/or any resource impact.

4. Final Decision and Approval

Ideally, the reviewer provides a timely response. In the event the change control response document exceeds the outlined due date, and there is no response/feedback from the reviewer, it should be sent to designated backup reviewers and a new due date should be set. In most cases if the due date is at risk, the request should be rerouted prior to the due date to the backup person.

The final decisions/results must be officially logged and tracked. It’s important that when the change control process is defined, it includes a list of sponsors, stakeholders and key decision makers who can weigh in and approve or deny the process and/or the decision.

If approved, the change control coordinator/project manager will update the appropriate change control log and/or documentation to reflect the change(s).

If rejected, the change control coordinator/project manager will update the change control log.

Every change control request should follow a similar process. Having this type of process in place provides consistency and manages expectations.

Once request has been approved/denied, the following must be completed:

Report: Once a review is conducted, a report is written. All the findings, input, feedback and risk assessments are recorded and stored for the life of that request. This supports and provides documentation of the process for future audits, traceability or compliance related inspections.

Change approval/denial: Once the changes have been reviewed and analyzed by requestor, change control coordinator, project manager, stakeholders and project sponsor, it is either approved or denied. If it is approved, it follows the below steps, if denied it will conclude with a “change proposal denial.” No other steps are required at this point other than documenting the denial and the reason in the change log.

Stakeholder support: All stakeholders who have been involved directly with the change process have to sign the change control document in support of the change. Likewise, change control coordinator/project manager will sign the document.

The final document will then be given an effective date/new effective date. A version control number will be assigned to ensure the new version is being utilized. The document will then be made available prior to the effective date and housed in a controlled system, allowing all users to view. This is important so proper training can be completed.