Add desired process changes
If you decide to make a few reasonable process improvements, make sure you add them to your process data maps. Make a note of the existing (or any new) system components or staffing that will be required to support the new or modified processes. List additional data needs and data flow. Also, don’t forget to make changes that reflect deletions or reorganization of data or tasks among various positions.
Proposed changes tend to require even greater levels of detail in documents than existing processes because:
- They are unfamiliar, and therefore need to be clarified.
- They need to be thought through completely, and all data needs identified.
You don’t want to finish decorating the Christmas tree only to discover that there’s no place to plug in the lights and no extension cord.
When you update your process data maps, you may want to use different colors or shading to represent system “must have” data and functionality versus “nice to have” data and functionality. You may even wind up with three or four gradations for levels of priority. As you continue through the elaborative refining cycles, you will be able to associate time and cost criteria with the proposed features or improvements. Having priorities clearly and consistently identified facilitates inevitable “compromise,” “streamlines” discussions, and keeps team members focused on core needs.
There’s another interesting thing that often emerges as you “code” priorities into the process data maps. You begin to see patterns or lines of demarcation where the system can be logically chunked into phases of evolving scope or complexity. This is very helpful in designing incremental development or deployment strategies.
Evaluate the vendors against your maps
Now it’s time to close the LMS selection process by using your process data maps as a focal point for evaluating final vendor options. Far too many software product demos are feature driven as opposed to being needs driven. Software vendors tend to control the demos by showing you a series of “really cool” features of their software, and extrapolating a myriad of unsubstantiated benefits derived from these features that should justify your purchase.
Your process data maps allow you to control the demo by focusing on your processes and specific needs. It’s often helpful to send the process data maps along with your list of desired features to a software vendor ahead of time so that their demo can be tailored to show how their software will support your specific processes and data needs.
The conversation then changes from a presentational sales pitch format to a much more meaningful interactive dialogue. It goes from them saying, “Let me show you how our system registers students” to you saying “The first thing we need to do is import new hires from our XYZ HR system and delete terminated employees, so show me how your system would interface with our existing HR system to do that.”
We have been very pleased with LMS product demos conducted over the Internet. It’s a win for us because it usually takes less time and effort than a live demo, and questions can be passed directly by the salespeople to system experts and developers right there with them in the home office so they can be answered immediately. It’s also a win for the vendors because Web demos are also less time consuming for them, and less expensive. Today, virtually all LMS vendors have this option available.
Plan enough time in the demo to go through each of the jobs and major tasks in your process data flow with each system that you are evaluating. Look for how each vendor’s system manages each task and each piece of data you’ve identified. Remember to focus most of your time on your core functionality needs. While keeping an open mind, don’t let the “nice to have” distract you from problems with a system that doesn’t meet your core needs.
Keep track of the number of things the “off the shelf” system can or cannot do, and any areas where the system would need to be modified, customized, or supplemented to do the critical tasks. Keep a running list of required changes. Make notes on the level of skill required to do any customization, how long changes would take, when changes would have to be made (before anything would work, or as a later enhancement), and whether changes could be done in-house or would need to be contracted out to the vendor or to a specialized consultant.
Make a special mark (I like to use $$$) every time the vendor says, “Yes, our system could be modified to do that.” When there are more “can do with modification” marks than there are “standard system feature” marks, it’s probably time to look at another system.
Also note features of the system you do not require for your current process support but may find beneficial in the future. Add these elements to your process data maps if you find they are things you have overlooked in your analysis and discover you can’t live without.
Don’t be surprised if no one system meets the majority of your needs. While many vendors claim to have the ultimate LMS or LCMS that will meet all of your organization’s needs, we were not able to find one that actually did. There was no one system that met all of our needs and the vast majority had many features that we did not need. If a best-of-breed or hybrid system is what you need, don’t be afraid to move in this direction. Just make sure that your discussions with vendors include integration needs and compatibility issues. It’s becoming more and more common for best-of-breed vendors to form strategic alliances with other vendors in the LMS space.
At the end of these product demos and follow-up conversations, you should have the information necessary to help you select the best option from your list of alternatives. You will probably find that no matter what you choose it won’t be a “perfect” fit. Some level of customization, middleware, integration, extension, or, at least, implementation will be required. Comparing your process data map analysis with the software options should let you know what is possible and preferable.
Conclusion
As you look at what it’s really going to take to make this all happen, it can be overwhelming. It’s OK to feel that way, but don’t let it stop you.
- Breathe
- Look for help and support
- Be realistic about time
Remember, you can still break the project up into phases that can be implemented incrementally. Just make sure that each phase has a clear, definable outcome that shows a benefit to the organization regardless of whether or not subsequent phases are implemented.
We’ve found it beneficial to call user references at this point and get REAL customization, integration, and implementation time estimates from them. Once you have credible voices from two or three similar organizations who have just been through the process with the specific software saying “six months to a year, but we’re glad we did it,” it’s easier to get your management to buy into your timeline.
So, you’ve been through the process and you’ve selected a core LMS and determined what will need to be integrated, customized or custom built. You’re at the end of the really tough part, right? Right. We just won’t mention which end. Hang onto your process data maps and your sanity because over the next few months you’ll need both in full measure!
Your next steps on the road to LMS implementation will involve:
- The creation of documents to communicate the scope of custom components or customization needs, including interface designs and more detailed flow charts.
- The design of specific reports.
- The creation of mock data sets to plug into the use cases for testing purposes.
- Testing, revising, testing, revising and testing some more.
- Creating documentation and training for product roll out.
Yes, it is as much work as it sounds like, but do not fear. We will be here to walk you through the maze in “Part II: Selecting, Integrating and Implementing a LMS” in the August 1 of Learning Solutions Magazine.
