It's all about Ownership

So you buy a new car and it's yours right?  Well, at least finance dependent and the day you pick it up etc… but let's assume you're a cash buyer and you drive the car off the lot. It's yours.  You tell everyone it's yours, you show off your new car and you probably don't let anyone else drive the thing because… well… it's yours right?  We even ironically do this with houses that we may never get to truly own in our lifetime (and who knows in a generation or two's time if anyone will ever own a house they didn't just inherit or win?).  Surely it's the same with your Learning Management System or LMS?

No.  Not always and often not at all.  The hardest implementations of Totara that I'm involved in are the ones where it seems no-one really wants to rise up and claim the awesome system we've just put in place for them.  The madness is that a house, a car and an LMS all benefit immensely from taking ownership and responsibility and ultimately you mould them so that they become an integral part of you or your organisation.  Of course maybe owning an LMS is a bit like a dog or children.  When working well it's yours and your proud of them, when they misbehave and pee in the wrong place (hopefully the dog rather than children) you make a hasty retreat and they become your partner's responsibility not yours.  No, that doesn't work, really someone has to own your system, but who?

I've talked in previous blogs (did anyone read them?) about who I believe should own the LMS in an organisation.  Let's take that a little further this time.  I think that an LMS is all about Learning (yes, read my earlier blog on that and re-read, it's all about learning).  That means the LMS should have its ownership roots firmly planted in that area, whether that's in Learning and Development, HR or Capability type parts of your organisation.  That's only really half the story, this is where governance and key stakeholders come in.  It's an imperative for a successful implementation that your LMS has some high-level support from somebody organisationally important - they may not be the owner but they are your top level guidance and offer key backing.  That top-level exec must be a fan of what you are trying to achieve and you must sell them the vision, you can then flow behind them delivering your message.  For want of a better term this person is often referred to internally as the 'sponsor' or even primary stakeholder.  Whilst they are incredibly important to your success, they're not actually the owner so they need to be great at a distant rather than too heavily involved in the project/learning.

The owner is different again, because the owner is going to really shape the LMS and drive it forwards.  This has to be someone with a passion for what the system is going to do (not necessarily the system, but that helps too).  This person has that learning focus, drive and as much responsibility as possible in that area.  But going back to my earlier car analogy they're a bit like a rich car owner - rich enough to pick the right LMS hopefully!  They own the car, they decide where it's going and how it gets used, but the driving?  No, there's staff for that.  The next role may be as important as the owner and sponsor, but almost certainly gets paid a lot less money.  In my analogy this is the driver, the driver in reality is the system administrator or sys-ad.  I've often seen the sys-ad very successfully falling into the lap of what was previously a training co-ordinator.  Ideally they have a great knowledge of how to get things done in training/development/learning and are used to organising things like face-to-face training sessions or meetings without a great deal of fuss.  If ever there was a need to have a switched on cookie in your org this would be it.  As I said before, you may not pay them the most but value them if you have a good one as they will do more than just drive your car for you, they'll service it, and get it running in a way that you hadn't even thought possible.

So with a sponsor, owner and sys-ad in place, it's time to drive your vehicle around your organisation.  Everyone will look at you and be envious of this beautiful machine you have and want a go.  So show it off by all means, keep control, but allow others to be stakeholders in it too - let them own a little piece and make that their own whilst keeping your overall vision communicated and intact.  Once you reach this stage you may be ready to "Love and let go of your LMS" as I once wrote.

As a final note, if your system owner or sponsor or sys-ad doesn't fall anywhere in any learning or training function, you will struggle and that's probably pretty obvious.  Your LMS is also an IT system, so if the above roles don't touch on IT, you've probably got it wrong too.  I'm not saying your owner needs or even should be in IT, but somewhere along the line you need IT to be a stakeholder.  My advice on this would be to do that at the start of your project so that they're on-side with what you're doing and at a high enough level that it doesn't come back down from above later in a way that's damaging. 

Lastly remember if no-one owns your organisation in your organisation, then you are just renting space, and that's a different market altogether - and a dangerous place for something as important as learning to sit.  Remember Life for Rent by Dido?  Bit like that.

Are you Agile enough for Learning Technologies?

The world of learning technologies is fast moving it's true.  I run lots of projects that move me both geographically and sometimes even philosophically.  Someone asked me where I was based yesterday at a meeting in Wellington (and as I sit on my third flight in the last 20 or so hours it seems reasonable that) I replied "the cloud".  But the one that has caught me a little recently and firmly given me a shunt to analyse my style of project management, is the desire for organisations to report on every minute detail along the way.  Now I'm (clearly) not a dedicated project manager (what are these strange beasts anyway?), but I do manage a lot of projects; mostly of a similar nature around the implementation of Totara LMS or Moodle/Mahara.  I manage projects using a kind of approach that seems logical and able to keep up with a rapidly changing environment.  Until recently I never thought about what that actually was enough to give it a label, I knew it wasn't the waterfall style or Prince2 stuff I remember from my military days, but I didn't realise unwittingly that I'd stumbled on to the polar opposite of Prince; Agile project management.

To me being agile is a pretty good word for what I do so I instantly connected with it and read a little more.  If you're reading this article to find out about Agile Management go and read the proper stuff or at least check out Wikipedia and find out what more edumacated people think, but if you want what I believe is at the heart of agile then read on and I'll tell you how I think it relates to your elearning projects.  Agile management of my projects (yes in my speak) is all about making things run smoothly, cutting down on unnecessary stuff and perhaps most importantly of all, empowerment.

Smooth runnings; sounds a bit like that great John Candy movie Cool Runnings (hey, great may be a bit strong, but it was fun) and it almost is that laid back attitude.  As a project manager the job is to not do everything and plan everything down to the nth degree, but to make everything run smoothly.  The difficult part in projects is where hand-overs occur or where people have to work together.  If you can facilitate these by providing the right environment and using the right tools and connecting the right people, stand back and watch the results.  To me the right tools are things that entice collaboration like Dropbox and Trello (if you've not checked out this little collaborative tool, it's really great).  Stuff where sharing and communication is what you do.  I'm sure some of you love MS Project but I don't.  It's too rigorous and not enough people have it.  You have to share by saving and sending and PMs tend to lock it down in that old knowledge and power tradition which goes against everything agile.  It's just a tool I know and Gantt charts and Project programs can work well, but the overcomplex chart scares me and makes the whole project feel over-prescribed to me.

Project Padding; this is the unnecessary stuff which seems to justify why so many PMs charge so much for their services.  For me this is bringing in 5 people to a meeting that is about management and just needs the manager involved.  Trying to pre-plan for every possible eventuality is a ridiculous concept to me.  One thing about the unknown is that it tends to stay that way until choosing to reveal itself.  I believe you should allow time and resource for the unknown, I believe you should be prepared for the unknown to occur, but listing all the unknowns is just something that isn't possible, so why waste masses of project time on it?  I think risks and changes need to be highlighted for sure, but you can't mitigate against every possible outcome without even knowing what the risk is.  Possibly the biggest project padder for me is reporting.  Shock horror all round!  You don't want to produce daily, weekly, monthly, hourly reports??  No, frankly I don't want to really report at all.  To me the agile project reduces the need for the formal planned reports because the project runs and everyone can access a 'live' report at any time and speak to the right people.  Trello is such a tool, we also use collaborative tools like Work Flow Max where clients can see what's going on with tasks and hours and all that jazz.  If I update a task in Trello it sends an email to subscribers so they know.  I do believe in regular catchups too, but meetings have to be the single greatest padder ever invented by businesskind.  Again, meetings are a necessary part, but meet when you need to, have regular catchups that are short, sweet and to the point and if you absolutely must meet, have an agenda and stick to it and don't let the meeting degenerate.

Power to the (right) People; so to me the biggest down-side of the old-fashioned waterfall PM is that everything is set in a complex array of dependencies and responsibilities which actually defines what each person can do and then follows up with reporting, meeting and strict protocols to ensure that everyone is a slave to the almighty plan.  Plans are a bit like models (not the thin otherworldly creatures on the cat-walk mind); some are good, some are not so good, but all are essentially wrong.  As a physicist by training I've seen everything from Newton's laws of motion to Einstein's relativity - they're models to explain what happens in reality, but the truth is they are mathematical approximations to reality and are fundamentally flawed by the unknown.  Without getting terribly deep (not my speciality obviously), a project plan is a similar hierarchical approximation of what is actually going to happen.  If you accept it's 'wrong' you'll be fine.  It will change and it needs to be living and breathing and you (the PM) can't control it alone, you've got to let it go and release control.  To me this is where agile comes in to its own.  Rather than me try and get constant updates on the bit Bob is doing, I let Bob set the original milestone and just update it as we go.  Power for that part goes to Bob not to me.  I need to know, but if I'm using the right approach and tools I will.  Likewise I don't need reports when things are on track; I like exception reporting whereby I need to know if there's an issue.  Otherwise I'll just see things happen using my tools as we go through.

Of course as a final note the best laid plans of mice and men are also known to go to rats if you don't mind me mixing my metaphors.  There's only one way to handle a project that goes wrong and that's roll up your sleeves and get stuck in, throw what you can at it and don't be afraid to evaluate your own performance before getting to heavily into others... hopefully that's not something that happens too often.

Servicing your LMS

In New Zealand it’s the WOF (Warrant of Fitness) in the UK it was the MOT, but whatever you call it and wherever you are there’s something you should do every year (or 6 months if you drive an old car like me) to make sure your car or beloved motorbike (incidentally worth several time what my car is worth) is actually fit for purpose.  Funny thing is that organisations invest significantly in their Learning Management Systems (or LMSs) but how often do they ever check on their fitness for purpose?

First thing to realise is that if you don’t regularly service any piece of equipment for an extended period of time it falls out of shape.  Try skipping the dentist a few years and see what you get… the trick is to keep servicing, keep checking and never letting it get too far out of shape.  I play sport and have done since I was… well it’s been a while and long as I can remember.  Give or take an injury or two I’ve never stopped playing and that’s probably why I’m still able to play at a reasonable level at my ripe old age.  Again it’s harder to start up again then to just keep going, it’s that regular servicing that keeps things working the way they should and stops you getting strains in the most inconvenient of places.

There are lots of places to get your LMS serviced, from the official places that only check fitness (and won’t make any corrections) to large chains of garages and even the dodgy little place round the corner (and some cowboys to boot).  Picking the right one is best done by listening to people, trusting what you see, hear and feel and ultimately by the way you feel when you drive away.  Same thing for getting someone to service your LMS.  There may not be that many LMS service centres, but don’t forget there are millions of cars (yeah, even in New Zealand) and relatively few LMSs so it’s all relative.  Funny thing is the same rules apply, you have to listen to what other people say, looking and evaluating as you go, but ultimately how you feel after the service period is the best way of knowing whether you should return.

Of course an LMS and  a motor vehicle are hardly the same things at heart, in both cases how you use the thing is perhaps more important than the technical capabilities of the thing itself.  The difference in your LMS WOF is that it is as much about how you use it as it is about the way it works, it’s a meeting of man and machine and the overall effectiveness that counts.  As ever in Learning Technologies you need to choose your mechanic wisely and find one that really speaks your language not just the mystical language of tappets and bearings.

Finally remember that when your vehicle is failing badly it may just be time to trade it in or buy a new one.  If you (or your predecessor) roped you in to a long-term deal (I still can’t believe some vendors persist in this) you may have to suck it up for a while but you should already be eying up and checking the performance of the new model.  If you haven’t considered looking at Open Source too, then you probably have already limited yourself to the expensive European market without considering those ‘other’ vehicles that are technically far better at a fraction of the cost with more options and add-ins than you can shake a stick at (the one you should have beat your predecessor with for tying you in for this long).

As a post-statement remember that everything above holds firm equally for motor vehicles and LMSs, but in absolutely no way bears any relevance to your partner.  Servicing, trading in and upgrading are thoughts that should go no further and a lock-in period (even if that period is ‘til death) is part of the deal if you want to secure the ultimate package.