EduLMS / Running it

You did not pick this platform and it is yours now

Most people who administer a learning management system were handed it. Understanding how that happens explains almost everything about why these systems are the way they are.

There is a particular kind of job that nobody applies for. Somebody leaves, or a role is restructured, or a manager notices that you are the person in the room who can be trusted with a spreadsheet, and by the end of the week you have the administrator password for a learning platform holding four thousand enrolments and eleven years of accumulated decisions. You did not choose the platform. You did not choose the version, the theme, the twenty-six plugins, the naming convention for course categories, or the arrangement by which the finance team receives a report every Tuesday in a format that exists nowhere in the software's documentation. All of it is now yours.

This is not a complaint about anybody. It is the ordinary way that these systems are staffed, and it is worth naming because so much of the writing about learning platforms assumes a reader who is choosing one. That reader is rare. The far more common reader is the person who has inherited a working system and needs to keep it working while gradually understanding why it was built this way. Those are different problems, and advice written for the first is often actively harmful to the second, because it treats every inherited arrangement as a mistake to be corrected rather than a decision somebody made for reasons that may still hold.

The first thing to understand about an inherited platform is that almost none of its oddities are random. The strange course category that sits at the top level with one course in it exists because a manager wanted their programme visible without scrolling. The plugin that nobody can explain is there because a compliance requirement in a particular year needed a particular report. The convention of putting the year at the front of every course name rather than the end exists because somebody, once, sorted a list alphabetically and did not like what happened. Each of these is a fossil of a real constraint, and you cannot tell which constraints have expired until you know what they were.

So the useful first move is not to tidy. It is to ask. Find the person who was here before you, or the person who signs off the reports, or the trainer who has been running the same course through six versions of the software, and ask why. You will get three kinds of answer. Some things will turn out to matter enormously to somebody whose name never appears in any documentation. Some things will turn out to be nobody's requirement at all, a habit that outlived its reason, and those you can quietly retire. And some things nobody will be able to explain, which is a signal to leave them alone for a year and see whether anybody notices.

The second thing to understand is that a learning platform is not really software. It is a record. What sits inside it is the evidence that people did what they said they would do: that a learner was enrolled on a particular date, submitted work, was assessed against something, and received a result. In a training context, that record has consequences well beyond the classroom, and it is often the only surviving proof of an interaction that happened years ago. This is why administrators develop a reputation for being obstructive about things that seem trivial. Deleting an empty course is trivial. Deleting a course that turns out to hold the only remaining evidence of an assessment is not.

The third thing is that you will be asked to make it simpler, and simpler is not one thing. Simpler for the learner usually means fewer clicks between logging in and the thing they came to do. Simpler for the trainer usually means fewer places where the same information has to be entered. Simpler for the administrator usually means fewer exceptions to the standard pattern. These three pull against each other. A front page that puts every current course in front of the learner is simple for the learner and a maintenance burden for you. A rigid naming rule is simple for you and infuriating for a trainer with a course that does not fit the pattern. Naming whose simplicity you are optimising for turns an argument into a decision.

None of this is an argument for leaving things as they are. Inherited systems accumulate genuine problems: enrolments that were never cleaned up, roles granted to people who left, backups that have been failing silently since a server move. Those need attention and some of them need it urgently. But there is a difference between fixing what is broken and reorganising what is merely unfamiliar, and the second is the more common instinct in a new administrator's first month. The platform will still be here in six months. Spend the first of those learning what it is actually doing before deciding what it should be doing instead.

There is one more thing worth saying to anybody in the first month of this job, and it concerns confidence rather than technique. You will be asked questions you cannot answer about a system you did not build, by people who assume you know, and the temptation is to produce an answer rather than admit the gap. Resist it. An administrator who says they will find out and then does builds a reputation that survives the occasional genuine mistake. One who guesses builds a reputation that does not survive the first time a guess turns out to have been wrong about something that mattered, and in a system holding assessment records the things that matter are not always the ones that looked important at the time.