There’s plenty of cliches I could start with here about the place to lead and so-on, but this post is more about where your control lies and where you control your system. You’d be excused for thinking I might be stating the obvious here, after all you don’t fly a plane from a seat in the back, or drive a car (yes, we all know some exceptions here) from the backseat or lead the world in rugby from anywhere but the front, but actually for learning systems it’s not always that simple. The first thing is that often the controls for your LMS don’t sit with the people leading the learning function. I know, that’s crazy right? Being a leader isn’t about being the best or knowing everything, it’s about knowing how to get your people pulling together in the right direction. For your LMS if your ‘owner’ isn’t in the line of your learning function (yes, above can work fine) then you’re going to have some troubles ahead and a coup maybe needed to bring things together! The most common misplacement for an LMS is sitting in IT. Sure there’s all that complex environmental stuff that they have to take care of, but when it comes to flying the plane, the engineers don’t have the final say do they (I mean during flight before someone shoots me down here)? I firmly believe IT/IS play a vital role in your successful system, but putting them at the front isn’t the right strategy for most organisations (a caveat on this is it really does depend on your business and who drives what you do).
So assuming you’ve got the leadership of your learning and your LMS ownership aligned, it should be fairly plain sailing from here right? Not necessarily, it’s still easy to end up with the tail wagging the dog (one of my favourite expressions for sure). What I mean by this is that despite the ownership of the system officially sitting with learning functions, you can find the system is so locked down to your administrator that anything you want changed or altered can only be done through the ‘back-end’. At Kineo Pacific we’re a front-end organisation when it comes to LMS implementations, consultancy and support; what that means is that we’re all about learning and the use of the system, not about the technology and ‘code’ that sits behind it. Our IT ‘department’ is often sub-contracted or pulls on our world-wide team and that works for us, because of our ‘front-end’ philosophy. For your LMS the most important functions are the outward facing ones, the things that you can do. Think back to our plane example (yes, I’m on one as I write this as is often the case!), the pilot has complex functions and the ability to do everything that they need to in order to successfully take-off, fly, navigate, land, communicate etc. Can you imagine a case where a plane took off and the pilot needed to change course mid-flight because of… well, these things happen, but didn’t have the capability to make that change? Sorry captain, the system doesn’t allow you to do that, but if you want we’ll work out what needs to happen and change it at the engineering level so that the change can occur… you just need to land (stop your learning) and catch us when we have some time to look at it. Same should be true of your learning where a system’s crash may not be quite as life threatening but will certainly cause you some flak. You’re mid-programme and you need to change direction because of legislation changes, or you need to be able to move everyone into a different route or… well, you need to change course. You’d expert your learning leaders to be able to do that mid-flight surely? The only way that can happen is if they have the abilities to do that.
Of course this also has a flow down effect. If you’re in ‘learning’ and the owner or lead of the system, make sure you give the right powers to those leading the learning functions (or at least have a responsive approach when changes need to occur). You also need to make sure that you have the capabilities that you need to make the system run. Remember leading your system is like leading a team, it’s not about how much you know about the system or being best in it, it’s about getting the resources pulling together in the right direction.
The other point is about when your system doesn’t work quite the way you want it to. I’ve talked about this before and my take is always configuration over customisation as a first option. In essence if you can look at the way your system is setup and working, or even your own processes, do that before getting your system ‘back-end’ customised. Configuration is about ‘front-end’ and just like leading, it’s the best place to start. We work with organisations on looking at all the possible ways to achieve what they want to using the front-end first approach, it doesn’t mean we can’t or won’t customise (we work with open source so it’s something that we can do with relative ease) but that the tail gets wagged when the dog knows that’s what it wants. If you jump to the back-end right off the bat, it’s easy to find that tail wagging you and your decisions along.
Of course you can ignore all of this, plenty of dogs are happy after all without so much as a thought seeming to pass through their front end and if you want a crazy alternative you can also ignore what your supposed to be doing and just spend your time chasing your tail instead!