Jim Farmer’s financial analysis of Blackboard certainly has gotten a lot of attention–and for good reason. To start with, that ~$250K cost per sale is a truly eye-popping number. But upon further reflection, I’ve come to the conclusion that it’s not the most important part of the story that Jim tells. Here is the most important part:
Software suppliers do not spend on sales and marketing not considered ?necessary.? The costs are driven by customer demands and customer expectations. Enterprise procurements can be very expensive for software suppliers. Requiring extensive proposal responses, large-scale demonstrations using extensive prescribed scripts, and presentations with experts drawn throughout the company are required by customers as a condition of doing business; this is costly.
Blackboard spends a ton of money to acquire each new customer because they have to. It’s the only way they can successfully run the gauntlet of the higher education sales process often enough to make money. The procurement process itself is broken. It requires proprietary vendors to spend between a quarter and a third of their revenue on sales–money that could be better spent on product development or discounts to customers. It blocks Open Source support vendors that don’t have armies of salespeople from participating in many RFP’s. And, according to Jim’s analysis, it results in a net price increase of as much as 26% for the customers. Everybody loses.
The good news is that this problem is fixable.
Why are enterprise software sales cycles so expensive? Because the purchaser needs to gather and organize a lot of data in order to make a good descision. And since we don’t have many industry standards for measuring quality and organizational fit of enterprise software, most organizations end up re-inventing the wheel, gathering data that other organizations have already gathered, and run various kinds of tests that other organizations have already run. Even worse, after all of this work, the data we end up with is still pretty weak in terms of giving us a good comparative sense of how well a particular enterprise product (like an LMS) will serve our institutional needs. If we only had a standard yet flexible methodology for evaluating software–whether Open or proprietary–we could solve all of these problems by creating shared repositories of evaluation data, somewhat like Edutools, but encompassing all aspects of software evaluation, including code quality, support quality, compatibility, and so on. For the most part, organizations could just take existing data in standardized formats, pour it into their customized evaluation rubric, and come out with competitive product ratings.
As it turns out, my colleague Ken Udas and I are working on just such an approach. We’re writing a report for The Observatory on Borderless Higher Education that applies an Open Source software maturity evaluation model called the Business Readiness Rating (BRR) to both Open and proprietary LMS’s. The OpenBRR community has already created example evaluations of Moodle and Sakai, so we’re starting with some good examples of how the methodology’s creators intend for it to be applied in this space. And since the BRR was cooperatively created by Carnegie Mellon, O’Reilly, SpikeSource, and Intel, it has an excellent pedigree. We’re going to adjust it by adding some more LMS-specific understanding to flesh out the evaluation criteria and consider how the model can be extended to work with proprietary products as well as Open Source. (The methodology creators specifically state they believe this is possible.) Using BRR, coupled with a shared repository of evaluation documents by participating institutions, we could substantially reduce procurement costs for Learning Management Systems, to the benefit of everyone.
That doesn’t mean that adopting a new method will be easy. To begin with, proprietary vendors have something to lose–especially those with large market share and big marketing budgets–because the process tends to commodify the evaluation of the software. But the cost savings is a compelling argument, particularly if Open Source continues to pick up steam anyway, eroding any advantage a market leader may have in a battle of the bullet points. But the vendors alone can’t change the procurement process, even if they want to. It has to come from the purchasing institutions. And since procurement processes are deeply enmeshed both with institutional politics and with fiduciary management rules (or laws, in the case of a public institution), these practices don’t change easily or quickly.
