Managing Change Requests for a Validated Environment: Keys to Success

Man playing dominoes

As the primary change manager for a client’s learning management system (LMS) for over a year, I have gathered key information and considerations for anyone working in a similar role within a validated environment. This is the second of two blog posts on the topic, and while the first covered basic background information, this post will focus on the most important lessons learned and best practices to follow.

Start with clear requirements

Do not lose sight of the intent of the change. Make sure that the requirements behind the request are clear, especially if you were not involved with the initiation of the request. The justification for the change is one of the most important factors in moving it forward. If the justification is not clear or worth the level of effort, consider setting the change aside for a later date or tabling it completely.

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, 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?

Dig into documentation

Any time a system process is changed, 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.

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 as a change manager is to always test!

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, 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 change request implementation.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.