Is Your Learning Data Being Held Hostage?
When you work with [learning] data, you often run into odd situations. From data stored in some old format that may as well be hieroglyphics, to the mission critical data existing on one – and only one – person’s laptop, to using Excel sheets with tens of thousands of rows and hundreds of columns for ‘analysis’.
If you manage your company’s L&D data, I will bet you have dealt with a few of these yourself; and while these situations can be frustrating, and sometimes downright infuriating, they are typically not created maliciously.
But we have been hearing more and more of a different issue from our largest clients that is not as benign. That issue is LMS vendors refusing to help their clients regain full control of their data.
In essence, they are holding the data hostage. And like all good (bad?) hostage takers, they have the same agenda: Give us (more) money or the hostage gets it!
But Why Should I Care?
Before I dive into what this hostage situation looks like and how you can flip the tables on the offending parties, I think it would be helpful to go over why this is so important.
Training departments are using more technology than ever and this can be very helpful to businesses. However, in order to recognize the full benefits of these tools, data needs to be shared freely amongst the systems and analytic tools.
As I have written before on How to Prepare for the Learning Tech Explosion, L&D tech stacks fall far short of what marketing and other business units possess. A main reason for this is that the traditional LMS model has not allowed for data to be shared freely and openly between systems.
Data can form the backbone of a complex, but seamless, ecosystem that allows for better experiences for learners and admins alike…but not if it is locked away and hard to access directly.
Even if you have no desire to update your learning tech ecosystem, being in control of your data is still important. Depending on your location and industry, you may face a whole host of regulations and policies that require you to know exactly what data you are storing and how it is being stored. From governmental regulations (GDPR in the EU, HIPAA/FERPA in the US), to industry-specific rules and best practices (finance, healthcare, etc.), to company and legal policies, leaving data in some LMS’s blackbox is a huge liability.
As Peter Drucker famously preached “You can’t manage what you can’t measure”; and by making data more siloed and harder to access and analyze, these LMSs are hurting your ability to provide meaningful reports to your managers and stakeholders.
L&D has long been denied a seat at the same table as other departments. A big reason is that it is very hard to convincingly show, with data and metrics, the impact you are making every day to the core business.
That becomes much easier once data is collected in a central location, from all sources, and can be analyzed freely.
Disclaimer: Before I continue, I would like to state that although we’re not normally the type of business to call out specific companies, we feel that for the sake of the industry as a whole, such downright bad practice should be called out if it is to be eradicated and customers are to be treated as they would – and should – expect to be when dealing with vendors, especially those which charge upwards of $1million a year for their ‘service’.
What Does A Data Hostage Situation Look Like?
To give you an idea of how these conversations unfold, and how frustrating they can be for everybody involved, I will outline a real situation that occured recently when a large technology company (a Fortune 500 Global) came to us (HT2 Labs) wanting to start using an LRS…
The first thing they wanted to do was collect some data from their LMS, Cornerstone OnDemand (CSOD). They wanted to send this data into a Learning Locker LRS, which is a store for xAPI data.
As the CSOD Help Center implies they have xAPI support, as long as certain criteria are met, this should have been an easy first step. But, alas, that was not to be the case.
Early Warning Signs
The first warning sign was that there was nothing within CSOD that indicated how to set up xAPI. (One of the great things about using xAPI is that it is a generally agreed upon standard, so connecting systems that support it is (or at least should be), very easy.)
The person I was working with had to reach out to their CSOD Administrator, who also did not know how to connect the CSOD data to an LRS.
So we collectively scheduled a call with a CSOD Account Manager to describe the process that is outlined in the CSOD Help Center.
On that call, we were told that CSOD actually does NOT support xAPI, but it would be coming within the next month. (At the time of writing, they are still yet to do so – but we’d like to invite CSOD to get in touch with us to clarify things as we’d be happy to publish their position.)
That timing seemed unlikely, as CSOD had put that Help Center article up at least 18 months prior. What were the chances that the next month would actually be the month it went live?
The person I was working with agreed, and then sought to escalate it within CSOD. That is where it got even more bizarre…
More Alarm Bells
On our next call (this time with a CSOD technical resource) we were told that xAPI support did not exist and that they could build something that would be able to pass data to the LRS. I asked about all of the previous mentions of xAPI in CSOD literature and by the account manager, and was brushed off.
Following that call, the customer was given a statement of work (SOW) related to generating xAPI-like data. Let’s just say the fee was rather more than anticipated.
At this point, everybody was getting frustrated, and rightfully so, so there was another call with CSOD scheduled to try and get to the bottom of this issue.
During this call, CSOD tried to sell their own version of an LRS. Which seemed very strange as the most basic criteria of what constitutes an LRS is that it accepts xAPI data. How could CSOD have an LRS if they do not even generate xAPI data?
It was very clear that at every step CSOD was trying to stall, and deflect answering questions in order to prevent their client’s data from being used in the way that their client wanted.
This was not done for the client’s benefit by any means. It was done in order to protect CSOD from being replaced, which is where the analogy of a hostage situation comes in: By keeping the data locked away and hard to access, CSOD is able to demand more money (through renewals and additional fees and SOWs).
Cornerstone is not unique in this practice by any means; we have, unfortunately seen similar situations with many of the large LMSs (but generally to a lesser extent) – few document the xAPI practices they say they do, only to not really do them.
As next generation learning ecosystems gain market share, the status quo LMS vendors are leveraging what power they have to fight back. But that hurts their clients and it hurts the L&D industry as a whole.
So, what can you do about it?
3 Steps to De-Escalating the Situation
1) Recognize if you are being held hostage
The hardest part of the situation outlined above was that there were never clear answers. Knowing the score is half the battle.
If right from the beginning, CSOD had said “we do not support xAPI, nor do we plan to any time soon” we could have developed a plan to get the data into an LRS without any assistance from CSOD.
To find out if your LMS is holding you hostage, try getting the data out using a free LRS .
If your LMS hems and haws and throws up roadblocks rather than helping you, it is a sure sign that your data is being held hostage.
If that is the case, do not worry – you can still regain control of situation.
2) Use a third party mediator
Like all hostage situations, it can get quite tense between the two parties – which is when a third party mediator is brought in.
By being impartial, the third party is able to help calm the situation and bring about a result that everybody can live with.
In the CSOD example, we were able to find a way to get data out of CSOD and into Learning Locker that did not require any help from CSOD. In that case, our customer was able to get their data out and start using it alongside other data for more advanced reporting and is not at risk of losing that data if they decide to move on from CSOD down the road (and, really, who could blame them if they did?).
Now you might think, “But now you are holding their data hostage instead of CSOD…they just traded one bad situation for another!” but that is not the case, because with Learning Locker, the data is completely yours.
If you want to send it to another LRS or reporting tool or maybe even the new LMS you upgraded to, we have the ability to forward any and all of the xAPI statements you have created wherever you want, and without the need for any extra assistance from our team.
In fact, the statement forwarding feature sits right on Learning Locker’s main menu:
3) Put a plan in place to avoid the situation again
After you have mitigated the hostage situation, it’s time to take a deep breath and then put into place a plan to avoid getting stuck in that situation again, starting with establishing what you actually (might) want to do with your data, not just what you are able to do with it at the moment.
When dealing with vendors, determine if they will help you reach your data goals or if they are more interested in their goals for your data. For example, if you ask for something the vendor cannot provide, do they help you find a solution or try to fit you into their ill-fitting box?
In short, the data being generated within your organization is your data. Do not allow vendors to tell you that you have to jump through hoops or pay them more money just to gain access to it.
If they are collecting something, you should, nay, you need to have direct access to that data. Your company’s well-being and your own career mandate it.
At HT2 Labs, we have data-focused team and customer-first mentality, and we’ll be happy to help you at any time – just reach out and let us know how we can help!