Sunday, November 29, 2009

Budget and Quality - Managing the LMS Implementation effectively

Companies that approach me for the LMS solution come up with the following experience they had with the previous vendors
  • The implementation cost has overshot the budget by at least twice the budget
  • The quality of the implementation
I found the following common problems in the above implementations
  • The Vendor over charged for the LMS implementation and delivered a poor quality implementation.
  • Waterfall Approach followed in the execution of the projects. This approach conceals the problems in requirements, implementation, skills, budget till the end where there is  little room to make any corrections as the budget had already been overshot. 
  • The source code for the integration is not available to the Customers and as a result they are tied up with the costly solution provided by the Vendor.
Here is how I propose the above to be solved. Of course, this has to be discussed with the Customer and they have to be comfortable with it.
  • Get the fixed cost bids from a few vendors and compare them
  • Follow the Agile methodology. This ensures the integration is done in multiple iterations. This will help flush out the requirements, continously tests the quality of the implementation, helps in prioritizing what needs to be done, helps in controlling the budget. This is a change in the mindset for which the Customer and Vendor need to be ready to work with.
  • Ensure that the Vendor provides the source code of the Connector as this will reduce the cost in upgrading to new versions and in customizing the solution.
There are other problems that I have observed which the Companies should be aware of
  • This is a technical problem and needs strong technical folks with Plateau LMS SME knowledge to head this effort. Do not rely on the non technical managers who may be the SME in this.
  • Get the Content right. Prioritize this for the beginning and ensure that different types of Content(AICC, SCORM) can be launched and the run time communication works well.
  • Ensure that you get the setup of Domains right and automated.
  • Ensure that any data transformation is externalized.     

Deployment

The desired deployment scenario is as follows
  1. Web Server - This is the gateway to the LMS. The static files(images, styles,etc) are deployed here. All requests are from here. This could be Apache HTTP Server.
  2. Application Server - The LMS application is deployed at an Application Server(Weblogic, JBoss, Websphere).
  3. Content Server - All content (AICC, SCORM) is deployed here. This could be a Tomcat Server.

Branding Styles

The Branding Styles are usually modified by an external vendor. The changed files are usually in styles and images. The deployment of these files is as follows
  1. If the static files are deployed at the Web Server then these files just need to be copied over. This is the recommended approach.
  2. If the static files are not deployed then they need to be copied in plateau.war which exists within plateau.ear and the ear needs to be redeployed.
Multiple branding styles can be created and they can be applied at Organization or Domain.

Tuesday, November 10, 2009

Secret Weapon - Copy Entity Tool

There is a less publicised tool by the name of "Copy Entity Tool". It is only published to copy selective data from the staging to the producton environments. But, to a Consultant who knows about customizing it, this can be used to migrate data from one version to the other and to copy all the entities from one schema to the other. This can reduce a lot of migration cost to the Customers.

Merging of Users

There would be scenarios when an employee changes the status from temporary to permanent and this results in the generation of new EmployeeID(User ID) in the ERP system.

There could be scenarios where the User IDs in LMS are not in sync with the User Ids in the ERP system. And one fine day, the management wants these IDs to be in sync.

To overcome the above 2 scenarios is not difficult. There is a "merge" user feature that is available in the LMS. This takes the old user id and the new user id and merges all the relevant records to the new user id and inactivates the old user id. Movng forward, the new User ID would only have a new ID but will have all the old training information. If there are very few records that have to be merged then this could be done manually by the LMS Admins. If not, the Connector application needs to be extended to do this merging.

plateau_client.jar is out of sync

The plateau_client.jar is provided in the LMS release for the client applicatons to connect to the API. This has the interfaces, stubs and ValueObjects to invoke the APIs remotely or locally. But in SP5 this is not in sync with the code base.

The workaround for this in 5.8SP5 is to use the plateau_sp5.jar that is in the EAR file. But this went out of sync when the application was upgraded to 5.8SP5 P14. The solution for this is to upgrade the plateau_sp5.jar. This can be done by the LMS Consultant or a request has to be made to the Plateau Services.

How to create Domains in LMS

Domain is a very important entity in the Plateau LMS. The whole security(record level access) is based on the entity(user, item, curricula, question, etc) belonging to the Domain. The LMS Admins are assigned Roles that comprise of workflows which are restricted to specific Domains. So, the LMS Admins have access(read/write/search/view) to all entities that belong to the restricted domains.

In most organizations, the source data of Organzation and Users(Employees) is maintained by the ERP system. These systems have no knowledge of the Domains. So, a common question that comes up while setting up the system is the creation of domains, the security and the mapping between the Users and Domains.

There could be many solutions to this based on the way the Organizations are setup in a Company, how the LMS Admins are tasked with managing the Users, etc. I shall go through one scenario that I have come across which may be prevalent in other companies and my proposed solution for this.

The Organizations in the ERP system are setup at each JobPosition which has direct reports. So, this leads to an Organizaton tree spanning around 9 levels deep starting with the CEO. Setting up the domains in such a scenario is tough if the access to the LMS Admins should be at the Organization level. If this is done manually then maintenance of this system will become more than handful for the LMS Admins when there is change in the Organizations.

My proposed solution is to create a Domain for each Organization automatically by the Connector when it synchronizes the Org and User data. Following are the advantages of this solution
  • The access to the LMS Admins can be provided at the Organization level
  • I have seen some solutions which have an Org-Domain mapping table in the ERP system which has to be maintained. This solution does not require any mapping table and zero maintenance.
  • The users of a newly created Organization can access the system as soon as the Connector is run and need not wait for the LMS Admins to manually make the changes in the system.
The disadvanatges of this solution are
  • The Domains are created at the Organization level. If the LMS Admins can only manage users based on the location and if the Orgs span employees across locations then this solution does not work elegantly. Some work arounds like Saved Seraches and Saved Reports have to be applied to make this work.