The 3 Questions for Change Management
Considerations in Risk Management
When Evaluating change, you may want to ask the following:
What is the system level of the aspect being changed?
Top Level (or Critical)
Mid Level (or Moderate)
Low Level (or Minor)
But how do we define the level of the aspect being changed?
The consideration of the aspect level determines the risk associated with the change and in turn, drives the work required to affect the change. Therefore, we recommend that this should be determined by asking the following Level Determination questions while assuming you have a validated status:
1. Is the change to an aspect of the system that impacts the system’s ability to meet its validated function? (This would be a top level or critical system change).
Top level or critical system changes require documented verification testing to demonstrate restoration of the system to its validated state following the change and before the system is returned to operation.
Testing needs to meet original validation requirements but does not supersede having to meet newer requirements.
Full revalidation may be required, due to the impact the change may have in subsequent operations.
2. Is the change to a secondary aspect of the system that feeds a top-level aspect where the control of the system’s ability to meet its validated function resides at the top level? (This would be a mid-level or moderate system change).
Mid-level or moderate system changes require documented testing to demonstrate that the change does not impact the top-level system’s ability to meet its validated function following the change and before the system is returned to operation.
Testing can be from basic function to verification to full revalidation depending on the risk.
Testing level employed needs to be supported by a risk rationale.
3. Is the change to a tertiary aspect of the system that neither feeds a top-level aspect nor controls the system’s ability to meet its validated function? (This would be a low level or minor system change).
Testing for tertiary level or minor system changes can be basic function or may not require testing if supported by a risk rationale.
Change Management Recommendation:
Define system levels and change requirements in the original validation. Here we also tie back again to the value of a robust and comprehensive Validation Plan (VP). The scope of the overall system and the boundaries of its individual elements should be well-defined within the VP and complimented by the individual validation documentation based on overall risk (Risk approach.) You may not be able to capture all cases but all reasonable ones to expect should be listed with requirements for verification testing or revalidation following changes to the system or its components.
This allows for risk review of the system at the time of its validation and provides guidance for system users in the future.
It also provides for original validation review whenever system changes are proposed and for validation plan review to evaluate if system changes are within the predefined system scope and component boundaries.
Don't forget to share this post!