Although LMSs can help every business by automating the general on-boarding, skill enhancement and other kinds of trainings, the procurement and roll out process seems complex. Unlike other systems such as Document Management, Team Collaboration or CRM which can be used by the users from get go, LMSs need to be seeded with content before they become usable. There are two very clear roles in LMS – users who build the courses (and tests) and others who consume them.
When most companies start thinking about the LMS, they don’t always have a clearly defined owner person or team responsible for seeding the initial data. IT can facilitate the LMS account creation, setup and integrations but that is just the starting point. Key question that remains unanswered is who is going to build the content in LMS and manage the trainings for all departments. Bigger the organization, harder it becomes to launch the LMS initiative in this manner.
Teams that needed the LMS most, also suffer most without having it, due to long delays in procurement, setup and deployment.
Although not a LMS, but a good example is to look at success of Atlassian Confluence. One of the main reasons why it is so successful is that it allows teams to have their own Spaces for collaborative content authoring without affecting other teams or requiring one team to build content for everyone else. No centralized process is required by IT other than setting up the system initially.
Similarly, in LMS space also, we can have a fresh thinking about rolling out LMSs as agile systems targeted to individual teams, rather than organization as a whole. A team that has ready content for training their members can simply sign up for a cloud based LMS. Even in large organizations, IT involvement can be limited to only configure the basics like single sign on and user accounts and do an internal announcement and hand it off to individual teams. To support this model, LMSs must also be built differently. LMSs that are not architected to allow key permissions at team level, will fail miserably when faced with this kind of environment.
In this post we will identify five key requirements for a LMS to be considered a team LMS.
In large enterprises, IT can procure the LMS and can automate creation of users and groups by linking the corporate LDAP/Active Directory (or similar) system. Once setup, LMS should support various activities to happen within these groups (similar to Confluence spaces) and maintain the isolation in a way that activities or content are not visible to other teams, unless specifically shared. There could be sensitive information that one team may not want to keep visible to other teams. EduBrite’s Groups feature support creation of fully private spaces for keeping all content and activities within the group.
Once you have groups in LMS and group members, you should be able to assign the members a Role within that group to control who can/should do what. One or more members can have admin rights, just for that group. These group admins should be able to add or remove members from their group (if permitted). They should also be able to create local sub groups within LMS (that may not be synced from the corporate LDAP). In context of LMS there is another role that becomes important, which is Instructor role. You should be able to identify admin and instructors for each group or sub group.
The key question we asked in the beginning was – who is going to create the content and manage trainings. The answer lies in having these responsibilities delegated at the group level, so there is no need to have a centralized L&D team involved with LMS operations. Admin and Instructors for a group should have ability to create all kinds of learning content and manage their delivery to the team members. In EduBrite, you can allow Group level authoring of courses and tests. LMS should also support using existing content that the teams have already created within knowledge bases or kept in document repositories in the form of documents, presentations and videos. Group’s Instructors should be able to create self paced or instructor led classes, just for their group.
Even though we said that all teams should have their isolated area of content and activities, that doesn’t mean that it should prevent possibility of sharing. There is no harm in having ability to cross link or share learning content across teams (to avoid duplication) as it will promote learning sharing (like knowledge sharing in Confluence) among peer teams. Similarly, if there is a centralized L&D team, they can share learning content with some or all teams, if they want to. L&D should be just another team, rather than a special group that owns (or is responsible for) all other team’s learning. A good use case is when L&D or HR can procure generalized course library (from content marketplaces like Open Sesame or LinkedIn learning) and load it on LMS with permissions given to all teams to use.
Since we are talking about learning programs that are fully created and delivered within teams, therefore it is natural to assume that team leads should be able to track reports also. This will enable them to close the loop from training needs analysis to measurement of training effectiveness and possibly linking each individual with trainings that are aligned to their career goals.
If you are evaluating LMS for a large enterprise, you must evaluate the above five requirements very carefully in any new system, otherwise you cannot avoid multiple LMS procurement by different teams or ending up with an expensive centralized LMS that sits in the shelf most of the time.
EduBrite LMS is beautifully architected to allow all activities and administration to be done at group level. This enables businesses of any size to implement EduBrite LMS without requiring centralized training administration. Let these activities be done by the team leads or departments themselves. It you are using Confluence, you can easily signup for EduBrite by using our integration Gilly from Atlassian Marketplace