All changes, whether prospective or retrospective need to be assessed for impact.
Requirements Traced to Tests
Impact could range from the impact on any documented information you have (requirements, risk assessment, design documentation, and, of course, validation protocols) to data existing in the system to how the system is used.
Here’s why having requirements traced to tests is so helpful.
If a change impacts a requirement, you can immediately identify the impacted test(s).
Prospective Changes
Prospective changes are the easiest to deal with since you have time to do careful consideration of the change before taking actions.
The impact assessment is documented in the change request for prospective changes.
When considering impact, if you did the risk assessment as we described earlier (and why wouldn’t you!), you can determine if any new risks are identified, if the current risk scores are affected, and/or if the overall risk is affected (e.g., you could be expanding scope which elevates the overall risk).
Existing Data
A consideration that’s often overlooked is the impact on existing data.
Consider our two examples of non-configured and configured code.
A change to the label software could, in fact, impact existing label templates.
Underlying Structure
Similarly, a change to the underlying structure for our Document Control software could impact the process flow AND the existing records (e.g., a document in the middle of a review / approval cycle may be impacted).
Think broadly when considering impact.