4 Troubleshooting Tips For The Learning Management System Administrator
Freer/Shutterstock.com

Tips For The Learning Management System Administrator

For the Learning Management System administrator, sometimes troubleshooting issues can be like looking at puzzle pieces scattered on a table. Hopefully you will find these tips helpful in putting the puzzle together.

Background

These are tips I have collected over the past 10 years of being in and around the Learning Management System world. I have used these ideas in many different environments; for example, in both government and commercial settings. I have had the good fortune of working with and for some very talented learning leaders and what you will find below is a distillation of many years of experience. I have not seen this exact type of information presented in this format.

Benefits

I hope you find, as I have, that if you apply these principles, you will save time, increase efficiency, and improve communication between the Learning Management System administrators, Learning Management System management, and stakeholders (end-users, learning leaders, business leads, project/program managers, and content owners).

What Αnd Where

I call these “tips” by design because they are not formal process recommendations. I realize each organization may have formalized steps in place to troubleshoot issues.  However, these suggestions can be applied across companies, and most importantly, across Learning Management Systems. The recommendations I make below are applicable in any Learning Management System environment.

Who

This is written for Learning Management System administrators and their managers. The assumption I make is that the Learning Management System administrator is responsible, to some degree, for identifying issues, resolving issues, and communicating about these issues to the business and management.

Here are the 4 tips. 

1. Resolving Technical Issues: Use The Best Communication Model (One-On-One Or One-On-A-few)

communication model for lms

Scenario

An end-user has reported an issue which gets escalated up through several layers of management until the Project Manager (PM) or Program-Level Lead arranges a conference call with everyone in the communication chain for you, the Learning Management System administrator, to resolve. You are not leading the call and have very little information prior to call. This is illustrated on the left of image.

I have seen this scenario played out in many different organizations. The players change, but the basics remain; that is, there are many different layers of communication between you and the person who reported the issue. Perhaps resolving issues using this model may work as the exception, but this method for resolving technical issues should never be the rule! The general rule should be that you, the Learning Management System administrator, should meet with the end-user directly to resolve the problem (one-on-one). And, when meeting, you should have the user screen share, when possible (see below for more information here). This is the more appropriate communication model, illustrated on the rights side. This may sound like I am suggesting that you not be “collaborative” or a “team player”; quite the opposite.

Here Is Why

This will help to ensure you are getting the necessary information in the most efficient way possible. By working with the end-user directly, you will receive a direct introduction to the issue, and then you will be able to observe the problem for yourself, which is invaluable for diagnosing concerns. The “all hands on deck” method tends to have individuals not familiar with the matter at hand, trying to summarize the problem, people speaking on behalf of someone two levels removed from the original report, and/or the person responsible for resolving (you, the Learning Management System administrator) having to do unnecessary level-setting on system functionality or terminology. All of these issues take more time and energy away from the two people that should be communicating. Think of it like this: Utilizing this approach will help eliminate what the Project Management Institute (see PMBOK, Fifth Edition, page 294) calls “noise” by setting up the correct communication model.

Key Takeaway

Keep it simple by dealing directly with the source. I am not saying the “all hands on deck” approach is not a good model for some situations. It can be effective at times. However, I have seen the “all hands” create more problems than it solves for this scenario. The main point is really about utilizing the most effective communication model. And, if you find that when trying to implement the one-on-one model that you are getting push back from the project manager (or lead), here are a few things that have helped me:

  • Address your need to meet one-on-one in a project management context, like I have above, using the most effective communication model.
  • Let the PM or lead know that this will save time for all parties involved.
  • Explain that you will document the exchange and will circle back with a summary email to one person, or the team.

2. Always Drill Down And Deal With The Source: Don't Spend Time Guessing 

guessing

Scenario

You are receiving emails that have been forwarded to you through several levels to resolve a specific end-user issue, but there is very little information in any of the emails (e.g. no screen shot, or no clear description of the issue).

This is a really common issue and I have seen some very smart people and organizations miss this point. This sounds so obvious, but you have to drill down to the source and gather information before you begin to troubleshoot if you cannot find the source in the email thread, which is often the case. Pick up the phone or use your IM communication to find the person who was the first person to report the issue. You cannot solve everything via email. It is OK in these situations to call or IM to get to the source.

Here Is Why

Email is obviously a critical information mechanism, but you cannot be expected to resolve a problem without all the information, including in an email. Think of it like this – would the IT department dedicate resources to resolve a concern without having all the information? Or would a doctor deliver prescription medication to a patient without doing a full history? No. So, simply follow the logic, which is, in order for you to adequately resolve the matter you need to get the necessary information from the source. What is the necessary information? Here are a few best practice items which would be considered necessary:

  • A screen shot.
    A full screen showing the browser and full view of the issue.
  • Browser. 
  • Network set-up.
    At home or using a company network.
  • A description of what the user was trying to do. 
  • Specifics like course number, titles, record names, dates, and times. 

Key Takeaway

I am not saying you cannot resolve issues via email. The point here is, do not waste your time / your company’s time guessing what an issue might be. Drill down to the source and get the necessary information. This is basic due diligence and will save everyone time and effort!

3. Meet Virtually And Screen Share: This Is An Absolute Must 

virtual

Scenario

You have tried to resolve an issue through emails, IMs, or calls, but the issue persists. This is an inevitability! If you have been a Learning Management System administrator, you have experienced this scenario. Not all issues can be resolved through emails or via IM. A Learning Management System administrator must know when to meet virtually and how. What is meeting virtually mean? It means you are using Adobe Connect or Webex (or a similar tool) to meet with the end-user (or source) to witness the error, view a result or problematic behavior. I would recommend that if you are training new administrators, or “upskilling” your current Learning Management System administrator team, you cover basic best practices for using virtual meeting software. Here is a short-list of best practices:

  • Have your own account, or have an account that is accessible.
    Meaning, it is best not to have to depend on someone to run a meeting for you.
  • Be good at using the software to schedule the meeting.
    This happens in different ways depending on the software, but the keys are:

    • Use the calendar of the end user, if possible, to find availability, then schedule. Or, be precise and clear on time and agenda when scheduling the meeting vie email (be sensitive to time zones).
    • Include all the necessary information (link and call in information) in the meeting, whether via calendar or email.
    • Make sure you ask for and get a commit or confirm for the meeting. For calendar invite methods, you will be able to get an Accept/Reject, but with emails, you will have to be directive and be prepared for the meeting. Spend a few minutes of prep time to make sure you have all the information ready, whether it be emails, course information, screen shots, etc. Nothing can frustrate an end-user more than you scheduling a meeting and then not being ready to discuss the issue.
  • At the beginning of the meeting introduce yourself, explain you are here to help, and then ask your attendee to explain the problem.
    Hearing it from the source will very often clear up the confusion.
  • Ask the attendee to demo the issue so you can witness the behavior.
    If you see an/the error, take a screen shot.
  • At the end of the meeting, be sure to confirm a next step.
    Either you have resolved the issue (in this case, ask the attendee to confirm the issue has been resolved) or send a follow up email on the results and next steps. Keep these follow up emails simple; for example, if you cannot resolve the issue, say so, but give them the next steps.
  • Understand that it is OK if you are not able to resolve 100% of the issues. 
    This is normal. However, after the meeting you should have clear direction for the attendee and you should be able to clearly document the next steps.

Putting these basic best practices or tips into your tool belt will be a huge time saving, and will help alleviate many issues around meeting virtually to resolve issues.

Here Is Why

Meeting virtually and sharing screens can be scary to some users. This is not a common skill. If you can make it easier on the end-user, you will likely be more effective at diagnosing and resolving the issuem and you will have a satisfied customer.

Key Takeaway

Think customer service! How would you like to be treated if you have a concern? You would like the process to be easy, the person to be respectful of your time, knowledgeable, and clear on the next steps. Learn how to meet virtually. In summary, learn the software, learn to schedule meetings, and be clear on next steps. If you do not have virtual meeting software and you are a Learning Management System administrator, then this is an issue to take to your project management team/office (or PMO). If you do not have a PMO, then you can look into investing in GoToMeeting or other tools.

4. Document: Create Your Own Personalized List Of Common Issues And Responses (I Use An If/Then Approach To My List)

Scenario

After solving issues, you do not have a formal way to document, store, then reuse the information. Here is an example: A user has reported an issue with an eLearning course in your Learning Management System, and after meeting with the user, you have noticed that for that specific course there is a simple browser setting that will fix the issue. During the meeting you appropriately took several screen shots and documented the steps to resolve the issue. After the meeting with the end user, you draft a summary resolution email to update the project manager, ticket/case owner, and/or user.

This is a very common scenario. Here are two things that might be helpful:

1. Create a folder in the your email account called “Learning Management System Issues” (or any name).

As you send the resolution email with the documentation, noted in my scenario above, copy yourself so you can “re-use” the documentation. Once you get the email, you can move it into your new folder. Then, if you get the same issue, you will have an easy way to find it, then you can send the email (forward with a new introduction and subject), or you can copy and paste the information into a response. Using this system, I always contextualize the resolution in an if/then way for the user. For example, if you are trying to launch Course A and you get this issue [insert screen shot from resolution], then simply [insert steps from resolution email]. Using a simple if/then approach will help simplify things for the users, managers, etc.

2. Create a “favorites” folder in your browser.

This folder will include internal sites or sites that have information that have been helpful for you in resolving issues. This sounds like an obvious thing to do, but given the number of issues and people a Learning Management System administrator deals with, this tip can be a huge time saver. Once you collect your list of helpful sites, you can integrate these sites as needed into your resolution emails.

Both of these tips are huge time savers, can be adjusted to fit your environment (email or browser), and should be a part of your troubleshooting process.

Here Is Why

You will get an economy of scale. Meaning, after a few months using these tips, you will be able to send more and better responses in less time. Also, consider that typically there are recurring issues or issue types. By having handy emails or links to build a resolution email, you will be able to dedicate more time to other issues, or work in a proactive fashion.

Key Takeaway

Build a system using your email and your common sites for resolving issues. If you do this, you will make your life easier, get a quicker response to the user, and will be able to turn your attention to other issues.

Final Thoughts 

I recognize some of these tips cut across basic skills or best practices around email, virtual meetings, or communication, but if you apply these to Learning Management System administration, you’ll have a good foundation.

I hope you found this helpful.

Close