I’m in the midst of an exchange with Kris Rockwell (@hybridkris) about a Patrick Dunn’s post ranting that rapid tools do not stimulate more creative E-Learning. I couldn’t agree more. That’s not me hating on rapid development tools — I think Articulate, in particular, is a GREAT tool. You can do a lot with it and what the team did with Ariculate 09 is a whole delta better than Ariculate 5.
But like any system, it has its boundaries, and to leverage it for something that it’s not designed for… well, you’re kinda on your own. In the ensuing discussion, Kris advocates…
…I think companies should hire firms to build their elearning. Good firms. Good small firms that love their customers.
And he’s right. They should. I’d caveat though, that companies should hire firms to build their elearning if companies know what they want, or at least what they don’t want.
Having worked both sides of these transactions, I can tell you that being an E-Learning vendor can be a tough gig. You’re an independent consultant. You’re competing against local competitors as hungry and probably committed in their way to rocking out their customers as you. You’re competing against offshore vendors who, because of their overhead, can compete on price and increasingly on quality. And you’re competing with your last job for your client, because you need to both one-up the last job you did for them while slashing your pricing.
And… you have to manage your client’s expectations. In some organizations, that’s an impossible task, because, quite frankly, your client just doesn’t know much about E-Learning, even though they’re neck deep in it. I think outsiders would be surprised (and I expect some head nodding while reading this from insiders) that there are so many companies who are banking on E-Learning who, even at just the technical perspective, have varying degrees of understanding (let alone expertise) about the systems they’ve invested in. When the conversation turns to why doesn’t a particular E-learning content work, there’s two routes it goes in: one is the design, and one is the tech. Let’s take the tech off the table, first.
I recently rifled off a litany of misconceptions clients have about SCORM systems, and for the sake of argument let’s just assume that much of the technical squabbling over E-Learning has something to do with SCORM. The objections/misconceptions I’ve experienced working on all sides of the E-Learning trade include:
- Folks don’t understand there are differences in versions of SCORM, and what that means for any content they have/will build.
- Folks aren’t aware of the capabilities in any given version of SCORM, let alone SCORM in general (ex: run-time tracking).
- Folks don’t understand what the pain points are of an integration, and what that means in terms of level of effort.
- Folks sincerely believe (long for/hope for) buying their way out of having a quality process for integration.
- Folks balk at the expense of implementation without having a clear benefits case for doing it to begin with (shifting blame).
- Folks put together RFPs laden with buzzwords (“SCORM” “Sequencing”) without a real assessment of needs and/or an understanding of what they’re asking for.
- RFPs without an end in mind never result with intended consequences, because there’s no picture of what’s right to compare with.
- Vendors assume that the client knows what they’re after. Not always the case, even if they sound like it.
Of the eight litanies I just mentioned, how many of them must be in the vendor’s domain of accountability? Not how many ARE there — but how many SHOULD BE there? (The answer, to me, is #8).
Now take the “design” track of where a client/vendor relationship can go south. How many of the above, if you swap out the word “SCORM” with the word “Design” or even “User Experience” — how many of the above should be in the vendor’s domain of accountability? (Again, my answer is #8).
Now on either side of the design/tech coin, the vendor is completely accountable for helping me identify my needs, reconciling those needs with what I want and delivering on the hard deck requirements that whatever you build needs to work in my system — “I” being a client.
Now, me as Aaron, working in an organization that builds or buys E-Learning, I want to have really good relationships with my vendors. I know the trade. I know who’s good. I know whom I want to work with. If the budget allows me (assuming I’m a decision maker instead of a translator) to work with vendors for a project, I’m going to guys like Kris or Stephen Martin (@smartinx). I’ve not even seen their work, but because they’re bringing their A-game into EVERY EXCHANGE I HAVE WITH THEM, I’m talking to them. There’s at least three other companies I like (but can’t disclose) because everytime I talk with THEIR people, not even related to actual work, they bring their A-game. I know that they’re going to give my company the best learning it can get, because I know who these people are and they’re not putting up a front. They’ve built estimable social capital with me.
But… even when an insider knows know the vendors are legit and are commited to knocking down any barrier to a “loving” relationship, if the client can’t get on the same page — and more problematic: stay on the same page… Well, there’s little hope for a vendor to survive in that kind of relationship.
Now admittedly — maybe I’m jilted after having seen vendor relationships turn sour, both as the client and as the vendor. Regardless, that’s why I advocate to companies to use Rapid Tools first. Get a feel for what you don’t like about E-Learning; discover the full extent of what your capabilities are. And then, when you’ve defined what the next level has to be for your project, engage in a vendor who will love you.