As the second of two blog posts on change control in a validated LMS environment, this post will focus on the five most important lessons learned and best practices to follow.
1. Start with clear requirements
Do not lose sight of the intent of the change. Make sure that the requirements behind the request are defined, especially if you were not involved with the initiation of the request. if the need is not clear, you may need to follow up with the requestor to gain clarity on the root issue they are trying to solve and the goal they are aiming to achieve. The justification for the change is one of the most important factors in moving it forward. If the requirement is not well defined or worth the level of effort, consider setting the change aside for a later date or tabling it completely.
2. Analyze impact/risk
Assess the impact and risks associated with the change, accounting for all areas it will affect in the LMS and in the business process. For example, if you create a security role, ask yourself the following questions:
- Do the privileges match the intended admin access?
- Does it grant any additional unintended access?
- How does it work in combination with other security roles a user might already have?
This assessment will help determine whether or not to proceed and what the priority of the change should be. If the issue or fix affects a critical workflow, that will have greater visibility and will likely need to be prioritized over others that have lesser impact.
3. Dig into documentation
Any time a change is implemented in validated software, all relevant documentation needs to be updated. When analyzing documentation impact, do not hesitate to reach out to administrators for the documentation they distribute to their teams. For example, any changes to the user interface are pretty much guaranteed to impact screenshots in administrator documents. Additionally, most changes will require updating the System Configuration Specification, other system/solution design documents, or validation documentation.
4. Test, test, test
Not only should the change itself be thoroughly tested, but other related functionality should also be regression tested to make sure there are no adverse impacts prior to release. I learned this the hard way when a patch to fix one issue ended up causing other errors that were not foreseen in the impact assessment. This was not caught before implementation because only the item being changed was tested, and no other regression testing occurred. The best thing you can do is test! When it comes to validation, less is not more.
5. Slow and steady wins the race
Make sure you take your time through the process, and do not rush to meet a deadline. Skipping over something seemingly insignificant may end up being a bigger pain to fix later on, and it may also put the system or employee compliance at risk. Quality should never be sacrificed for a timeline!
Overall takeaway
There are many steps in the change control process for validated software, ranging from impact analysis to testing to approvals. Most of these steps are in place to protect people from harm, so there is no room for mistakes. When in doubt, always go the extra mile! As the change manager, the LMS team will respect your efforts if you take a cautious, thoughtful approach to each change. Attention to detail and thoroughness will be your best tools to ensuring a successful, smooth implementation.
