Your LMS implementation is FINALLY nearing the end!
You’ve done the work to design and configure your new platform, identified the strategies you will use to boost engagement and adoption, and put in place a ‘what now’ plan for your system administrators to manage the system. Now it’s time to turn your attention towards go-live.
During launch, with any new system deployment, there will be challenges that arise. However, with preparation, you can be prepared to triage issues and find a resolution quickly. In this post, we will discuss some of these common go-live gotchas.
User-Related Gotchas
Whether launching a new system, migrating from a legacy system, or merging two systems, user-related issues are often the most common that arise during launch. Below are three that we see with some regularity, and what you can do to quickly identify the root cause.
A user cannot access the platform via SSO or an external user login process.
- Is the user new to the platform? If so, the systems may not have synced yet.
- Was the user moved within the HR Hierarchy? If so, review the new HR structure and how this is mapped as they may have been moved into an external access structure.
- Has the user updated their email address or any other data field that may impact their ability to log on? If the SSO is configured based on the user’s email address, and users can change their personal information (including email address), this will impact their ability to log into the system. Review any related configurations and their impact on SSO.
- Is the user accessing the system through the correct link? Check that your user is not trying to access the system via a bookmark to a legacy system.
- Is it possible that the user is a duplicate? This is common when you have several systems coming together and have users who, for whatever reason, have had access to more than one system in the past. If there are duplications, review both records to identify which is the most current and merge the accounts. Some platforms have specific tools that allow you to merge user accounts while retaining transcript and other histories in the resulting record.
A user’s security role is preventing or increasing access to system tools.
Despite all the testing and preparations for who should receive which security role, there can be instances where a user does not receive enough permission, or may receive too much, and be able to see some element of admin functionality or reporting levels higher than intended. In such cases, it is always recommended that the user’s permissions are reviewed and updated either to add them to, or remove them from, security settings. In some cases, a new security role may be needed to provide the correct access for a specific user, or small group of users, who have specific requirements.
A user’s transcript is not fully up to date.
This is an issue that typically arises when migrating between old and new systems in regulated industries. Often learning activity continues during migration and launch. As such, there is transcript data that needs to be migrated to your new system following Go-Live. In these situations, there will be users that have not yet received their latest training completions due to the migration catch-up. While your pre-launch messaging should have included these details, there will be users who did not read, have forgotten, or just missed it. A gentle reminder and update (if possible) on when they will be able to see the data is typically the best course of action.
Administrative Gotchas
While user issues are a large part of the go-live gotchas you may encounter, other stakeholders, such as new system admins or Managers, may experience different challenges as they get up to speed with the new system. Below are a few administrative gotchas to keep an eye on.
Reporting outputs do not reflect complete data.
- As discussed above regarding user transcripts lacking complete data, the same is true for manager and administrator reporting. Not all training data will be available for reporting until the data from the cutover period is migrated. As such, communicate to managers and new admins how to access reporting (whether that is through the legacy system for the time being or via Admin request) until the migration has been completed.
- Another potential reporting issue is related to possible duplicate users. If there are any, reports may show discrepancies like training against the first user record and more against a second, or duplicated training completions.
Learning is sent to more people than intended or doesn’t include all relevant learners.
New and/or inexperienced system admins will make mistakes as they get comfortable with the new system. Two of the most common mistakes we see are creating a new learning assignment and assigning training to more people than intended or the opposite, learning assignments that do not assign to all expected users (typically caused by not selecting all relevant users, or by using a dynamic group that has not been created properly). Use these situations as an opportunity to revisit training resources now that you’ve started using the system and consider whether refresher training may be needed.
Audience settings for learning have not been set correctly.
When we see audience settings improperly set, it typically surfaces when a customer notices:
- More or fewer users can see the training than intended.
- Admins have created new learning and do not understand the availability criteria settings.
- Training has been loaded in bulk and then the availability updated in bulk, and more training is captured in error, or you are missing some.
As discussed above, if these issues are beginning to arise, it may be time to provide supplemental training to your admin team.
Engagement/Adoption Gotchas
These common gotchas are those that affect how the system is used and perceived, and ultimately impact the engagement and adoption of your new system.
Emails not triggering correctly.
This could happen for any reason such as reminder periods being incorrectly configured, emails created against the wrong action trigger, and so on. A good method of tracking any email configuration issue is to use an Email tracker code or reference number within the body text of the configured email. Then, if an email is received in error by a user, it can easily be traced in the system. This is especially useful if you have multiple email templates against the same triggers.
Complaints about too many notifications.
Email communication is a balancing act, especially when bringing together 2 legacy systems and sets of users. If you are getting complaints about too many notifications, you should review what emails are firing and why they were activated that way.
Limited training certificate visibility in curriculum child learning objects.
If users have historically been able to access certificates for training completed, they may expect to see or download a certificate for each learning item they complete within a curriculum. However, depending on configurations of the child learning and backend settings, they may not see the certificates and raise queries. If this is a change in process, be sure to communicate this change leading up to and following your go-live period. If certificates should be available, a review of configurations to ensure certificates have been associated with training, either directly or as a default, is often all that is needed.
Summary
All customers have different processes and user expectations, so while this is far from a complete list of all gotchas that may arise, it’s a start. As other questions and issues arise, ensure you have a way to record everything that is reported, organized into actual issues vs enhancement requests/new requirements. Gathering and acting quickly on this feedback is the best way you can support the engagement and adoption of your new platform within your organization.
