Learning Management System Governance Policies
Governance provides guidance, structure, and boundaries for a team to operate, communicate and make decisions. It is an evolving living process that should be reviewed at regular intervals to ensure continued alignment with business needs. With the right governance established, we will have the following benefits:
- Empowers and ensures that the right people at the right level are making the right decisions
- Improved decision making: known decision points, escalation points, and remediation paths
- Faster resolution of issues
- Manages risks to LMS
- Creates better quality assurance for the LMS
- Assures LMS alignment with learning strategies and vision
- Establishes standards and collaboration amongst different learning teams
- Creates a history of why things have been done
The below section talks about the key governance policies for administration within an LMS under 3 key areas: security roles and permission, support structure, and communication.
1. Security Roles And Permission
Different levels of administration access and support are required to deliver the required training for end-users. The process of creating security roles and permissions associated with different roles must be audited and maintained.
Setting Up Or Deleting Security Roles Including Necessary Approvals
Only identified individuals from the admin support group should have access to create security roles in the system. The team should validate and document the requirements for new security role creation and submit the request for approval. The security role should have a proper naming convention with detailed description and correct parent associated with nesting the security roles. The security role must have all required permissions selected and required constraints applied. The team should create the security role with required permissions and constraints based on LC approvals.
Overall, the team must update the master list of security role permissions/constraints document with the new role details and should provide the required communication to affected stakeholders with details on the new security role.
Update A Security Role With New Permissions
Only identified individuals from an admin support group should have access to update security roles in the system. The team should validate and document the requirements for modifying the security role and submit the request for approval. They should update the security role with required changes for permissions and constraints based on the approvals.
Overall, the team must update the master list of security role permissions/constraints document with changes done to the role and provide the required communication to affected stakeholders with details on the modified security role.
Audit Process: Security Roles And Administrator Access
On a quarterly basis, the team should run a custom report on the Administrators Group to identify the last accessed date and time for the admins. The team should identify the list of administrators that didn’t access the system for the last two months along with their business unit.
In summary, the team should work with the business stakeholders on the inactive list to identify the administrator that needs to be removed from admin access and update the administrator document with the removed users along with the reason.
2. Support Structure
Support Structure should be well defined and handle all user and admin issues. It should have clear definitions of roles and responsibilities for different levels of support teams. All tickets should be routed to the correct level of support and addressed in a timely manner for the end-user. Support management must have clear levels of support and role responsibilities.
Level 1 Support
Level 1 Support should handle basic user issues related to access or content launch issues. Level 1 Support should act on a request received from a phone call or a ticket. They should validate and resolve tickets based on standard operating procedures. The team should reassign the ticket to Level 2 Support if the issue can’t be resolved based on standard operating procedures. Level 1 Support should be trained properly on the standard operating procedures of an LMS based on troubleshooting requirements.
Level 2 Support
Level 2 Support should provide support on the tickets that are escalated from level 1. Level 2 Support should own the tickets assigned by the Level 1 team to validate and resolve the ticket. The ticket should be reassigned to the Level 3 team if the ticket falls under the Level 3 category or needs additional support. The ticket should be assigned to Business Level Support if the ticket is specifically for business support.
Some of the Level 2 Support tasks are listed below:
- Training loading issue
- Training registration issue
- Training completion issue
Level 3 Support
Level 3 Support should provide support on a higher level of technical issues, certifications, release management, and system-wide issues. Level 3 Support should support Level 2. If any request requires a deeper understanding of the business or system landscape, they should support the complete LMS. They should have a good working experience of LMS functionalities along with the understanding of business processes and policies.
Some of the Level 3 Support tasks are listed below:
- Content upload and testing
- Certification creation
- Group creation
- Assignments
- Custom report
- System audit
- New system releases
- Technical issue troubleshooting
3. Communication And Notifications
A clear definition of the roles and responsibilities for setting up notifications and communications for the system is required. This will ensure that proper communication is sent to the required audience at the right time, with the right message, and with the appropriate action items.
System Email Administration
The Standard System Default Email Administration and Email Digest must be configured by the system administrator.
All system-wide email trigger templates must be documented with the details in a standard template and updated when required. The administrator must configure the standard email trigger templates for different email actions applicable in the system. The Activation of Global Standard email triggers should be set by an administrator based on the Governance Committee decision.
Administrators must understand the Language and Availability settings in the email area, which impact the delivery of the email triggers. They must have strong knowledge of catalog function and learning assignments in the system. They need to design the email message as per the approved format.
As a best practice, administrators should utilize the available email tags in the email message and validate/test the email messages for accuracy.
Conclusion
The failure or success of an LMS depends on how we handle governance. At post-implementation, if there are no processes in place, the system can get distorted very quickly. It is important to not just write the policies but to implement them. A Learning Management System requires training for its members with regards to the governance policies within the system for seamless business continuity.
