Did you ever wonder how a football player, movie star, or top fashion model could sign a multimillion dollar contract one year, and five years down the road wind up broke? While poor spending and investment decisions certainly play a role in these riches to rags scenarios, it’s equally common to find that the superstar, caught up in the demands of work, abdicated responsibility for financial details to other people. This disconnect led the celebrity to believe there was more money in the bank than was actually there. Or the star was unaware of the mounting consequences of poor investments or other negative financial management habits.
- Selecting, Integrating, and Extending Learning Management Systems
- Selecting, Integrating, and Extending Learning Management Systems Part 2
Just as our hapless celebrity was unable to make good financial decisions in an information vacuum, so the LMS project manager will be unable to properly and successfully guide the integration and implementation process if she disconnects herself from the detail of that process.
In Part 1 of this article, published July 11, 2005, we introduced our nine-step road map for LMS implementation. (See Figure 1.) We also detailed the first five steps of the road map. In this article, we’ll discuss the last four steps. They includes ways to keep training management directly and appropriately involved in the detail throughout the integration and implementation process.
Figure 1 The LMS selection, integration, and extension process.
Implementation/planning phase
In order to do a thorough job of implementation planning, you really have to know the details of what’s going to be required to move your chosen LMS software from the box into everyday use. This will require, first of all, a trial installation. In addition, you will need to demonstrate “proof-of-concept.” Let’s take these one at a time.
Trial installation
A trial installation is, in essence, a dry run. This is your chance to see if the software is actually going to install, and to learn whether it will do what you need it to do. You need this information in order to properly plan for your full integration and implementation.
You should always ask the vendor about a free trial installation period. Ask the vendor to allow a trial of 30 or 60 days after which, if you can’t make the software work, you can return it. If the vendor won’t agree to a free trial period, then order a very limited number of user licenses at first and add more licenses later. This may also keep your maintenance fee down as it usually is based on a percentage of the total license purchase. Until you’ve had a chance to look under the hood and really make sure that this software is going to work as anticipated it’s always best if you can leave a back door open where you can get out of the contract if you find something ugly.
To set up the trial installation, your technical people will spend some time with the vendor’s technical people. During this time your technical staff will go over all the hardware specifications, confirm the required versions of database software, line up who’s going to be doing what, and determine whether any additional installation consulting is needed to facilitate the install.
Another important thing to do at this point is to plan for and set proper expectations for the proof-of-concept step. Senior management needs to know that this is not a pilot rollout of the software. They need to understand that this is where you’re looking at each element and identifying in detail all of the additional time, money, and resources required for the full blown implementation.
Proof-of-concept
The proof-of-concept stage is critical to the success of your implementation. This is where you make sure that you get the outcomes you want, and that you actually meet the needs that you have identified. The goal of this proof-of-concept is to verify that the software will work effectively in the existing environment, as expected. In addition, the proof-of-concept will help to identify the customization needs, integration path, and any functionality deficiencies, and help to develop solutions that will overcome those deficiencies.
Arrange to have your core implementation/evaluation team receive training on the software that you have just purchased. This core team of two to five people must understand enough about the software to allow them to get around in it effectively and to clearly establish how it will support each job. Following the training, acquire and install the LMS software on a server for testing. Either install it on a separate testing server or install it in a testing area on a server that will eventually deploy the software. This choice depends on the configuration requirements of the individual product itself. But the most important thing to remember is that this is for testing purposes, so don’t put it out on a server where an LMS-induced crash might put your company or your department out of business.
Only perform the basic installation of the core software. This isn’t the time to go to the effort or expense of integrating the software with existing applications. The objective is to test the software as an independent entity. Does it work as advertised without integration, modification, or customization?
Once you have installed the LMS software, you’ll need some test records to load into the system and manage. (See Figure 2.) Create a group of 20 to 30 mock employees. They should represent different kinds of employees at different stages in their career, or at different locations throughout the company, so you have a nice representative sample. This will make it possible to test all of the features in the system. Don’t hesitate to have a little fun with this mock group of individuals. You’re likely to wind up working with them for a long time, and it’s not unusual for these mock cases to become part of your systems training once you’ve implemented the LMS. Just be careful not to use the names of currently living famous people or anything that one could construe as being in poor taste.
Figure 2 Create mock employee records to use in testing the proof-of-concept.
Use this mock employee data pool, along with your process data maps and the use case scenarios you developed, to walk through how the software will support each job function. Make sure you don’t skip steps or tasks. Make sure that you go all the way through the process so you know for sure exactly how this software supports each task and subtask in the process. Clearly document which features accomplish what tasks. Identify any place in the process where the LMS software is not able to support a particular task or subtask. Make sure all team members understand this need, and use a clear, consistent method for documenting concerns.
To assist in this process, we have found flow charts of the LMS very useful. We even go so far as to annotate those flow charts with screen captures of key screens in the system. (See Figure 3.) If the screens don’t already have clear names, or some kind of identifying numbers, create some. These will help in your documentation process and verify that you are testing out the scope of the entire system. Remember, these annotated system flow charts are specific to a particular application (like the LMS, or a particular component of the LMS). They are not the same thing as the process data maps that you have been developing. The PDMs diagram your workflow processes, but do not represent the flow of the software applications that support those processes.
Figure 3 Create flow charts of the system.
As you go through your proof-of-concept, identify any screen where the system requires manual entry of data that already exists in another system in the organization. These will be your preferred integration points. In other words, these are the places where the new LMS you are implementing will pull data from an existing Human Resources (HR) system, or other system within the organization. You also need to identify any screens where there is data you want to send to other systems in the organization. And if you’ve used a hybrid approach, and have multiple off-the-shelf products, then clearly identify the screens and points at which you want data from one of those applications to interface with data from any of the other systems.
Keep track of specific screens to customize with your company logo or with additional information that is currently not on them. You will also be identifying gaps where the system does not have the necessary functionality to meet the identified support needs that you’ve established. Note screens where this new functionality is accessed, and then where the results of the function would integrate back into the system. (See Figure 4.)
Figure 4 Identify screens that require customization.
And don’t forget reports. In fact, some people prefer to start with the reports and work backwards, especially if you’re creating a new report. It’s like identifying your instructional objectives before you start developing the training. Sometimes we make the assumption that once we get the data in the system we can get it out of the system in just about any format that we want. But that’s not always the case. The way the database tables are set up can affect reports, or vice versa. You must know your desired system outputs in order to assure you have the correct inputs and calculations in place to derive them.
So, make sure you take your sample use cases clear through to the reporting function to verify you’re getting the reports that you want. If the reports are not what you want, make sure you do screen captures of what they look like now, and note how you want them to be different. Identify what else needs to be on the report or to be changed or removed.
As you go through this detailed process, be prepared for surprises, both unpleasant and pleasant. You can never be sure WHICH surprises will be there, but we can tell you with confidence that there will be some. Make sure your management understands that unearthing unknowns is an expected part of the process and not a lack of ability or due diligence on your part. Some of the things you could unearth in the process may include, but are certainly not limited to:
- Unanticipated incompatibility issues
- A need for middleware, or an extension application, to provide the full functionality you need
- Compromises in functionality you’ll need to make because of time or cost issues, or limits of interfacing systems
By now you should have a very good idea of exactly what the system will and will not do. If the “will not do” column is significantly bigger than you thought it would be, you may want to exercise your contract escape clause and try another system. Or you may want to wait until you complete your analysis on what would be required to bring the system up to specification before making that call.
You may also want to consider the option of changing a small part of your process to conform to the current functionality of the system. In the big picture, of course, you don’t want the tail wagging the dog. In some cases changing the way data moves through the process is actually an easier or more effective change than modifying the software to accommodate a particular existing process.
