Advice for those who are rolling out an LMS for the first time

Process mapping sounds complicated. It sounds like something you need to spend time learning before you even engage with your LMS provider. But it’s not! In fact, you probably do it all the time without even realising it.

What does your LMS vendor mean when they ask you to “map” your requirements?
What your vendor is looking for is a series of LMS Workflows, i.e. how work will flow through the LMS. For this, you will probably be required to generate a series of flowcharts (check with your vendor for specific requirements and ask for templates if possible).

When you first engaged the vendor and provided the requirements used for tender you probably used general statements such as “students must be able to register for courses” or “training team must administer attendance”. At this point the vendor will want to translate these general requirements into specific actions and flows of actions. You should look at every requirement and ask the question “what does this really involve?”

Using our example “students must be able to register for courses”, some process considerations might be:

• Can students register for any course or will available courses be restricted by some attribute, e.g. manager/employee, finance employee/customer service rep?
• Do students need to have approval to attend a course? From who?
  Are there any pre- or post- class assignments?
• What happens if there are no places on the course the student selects?
  Should students receive reminder emails? How many? When?

This can seem like a daunting task, however, you probably considered all of this when you were writing your requirements….you just didn’t put it into fancy boxes.

Step 1: Know your users

Who are your users? This seems like a simple question, however it has implications for the entire system. Every user will have more or less permissions, depending on their role. Most companies will have one or more super-users, some training administrators, trainers and employees. Depending on the complexity of your organisation you may or may not have subgroups, e.g. employees may be broken into managers & staff; trainers may be broken into external & internal. The first step is to write down all the distinct user groups you will deal with.

Step 2: User activities

The next step is to define what activities each of your user groups will engaged in. A good way to do this is to take a blank A4 sheet for each group and write in the actions each group should be able to carry out on the system. For example, under trainers you might write “mark attendance”, while under students you might write “view attendance record”.

I would suggest that this is not a once-off task. You should let it “sit” for a while. Keep the sheets beside you and jot down additional activities as they come to your mind. If you have a source of information regarding historical training queries (e.g. a mailbox) it would be worth going through this information to check for common trends.

You can also make notes regarding the things that user groups should not be able to do. For example, you may not want students to be able to cancel courses they have registered for; or maybe only super-users should see exam results, etc.

Step 3: Walk a mile in their shoes….

Once your list of activities is ready, in order to effectively map out each one, you should put yourself in that person’s shoes. Choose an activity, e.g. a trainer completing attendance records, take a blank piece of paper and starting at the point “trainer logs into LMS” write down everything that happens. This might look like:

1. Trainer logs into LMS
2. Searches for course name
3. Enters the system course record
4. Selects students who attended & marks “complete”
5. Repeat for no-shows
6. Repeat for cancellations
7. Trainer logs out

These are the essential steps from that user’s point of view. Once you have written out these points, you can then add in the system’s point of view. In our example this might be:

1. Trainer logs into LMS
2. Searches for course name
3. Enters the system course record
4. Selects students who attended & marks “complete”
5. System sends completion emails/certificate notifications to students
6. Repeat for no-shows
7. System sends no-show notifications to students and copies their manager
8. Repeat for cancellations
9. System sends cancellation notifications to students, copies their manager and accounts department
10. Trainer logs out

You don’t need to add in system steps such as “system updates user attendance record” – these basic functionalities can be assumed.

Step 4: Dress it for dinner

Once you have these steps completed for all the activities you identified, it is time to make them look more process-like.  It’s time to build your flowcharts. Mind Tools has a useful article on flowcharts  and RFF also have a good overview.
I use Excel to generate my process flow charts. You can also use PowerPoint or Word. There is no need to buy any specific software – you will only waste time trying to learn how to use that software, instead of dedicating your energies to getting your processes right. Another bonus of using one of the common MS Office programs is that everyone has an idea how to use them, so you can ask colleagues to work on the charts with you.

I have shared a tutorial on how I make flowcharts in Excel. While my method may not be technically correct, it has served me well in implementation projects to date. The most important thing is that you and the vendor understand the icons/method being used. You should also use the space on either side of the chart to make notes for the vendor, e.g. you might want to note that usernames should be in a certain format, or that a field in a survey is mandatory, etc.

Hopefully anybody attempting to get started on this process will find this post useful. I would love to hear your feedback if you do (or don’t!). Thanks.