After an all nighter watching India lose pretty badly to Australia in World Cup Cricket semifinals, I am beginning the healing process. One of the things that will make me heal quickly is for Australia to lose to New Zealand in the finals. Given that the New Zealanders already beat the Aussies once in this tournament and won their semi finals in a dramatic fashion, I am hopeful that they will clinch the finals. I know most of you don’t care about cricket, sorry, but remember I am going through healing.

I was invited to watch a demo of yet another software product that we are looking at that will help us with affordable care act reporting requirements. (As a side note, ever wonder when these regulations will stop adding to the cost of Higher Ed?) In light of this demo, I was thinking about our experiences in purchasing third party software and it immediately dawned on me that “Lies, Damned Lies and Statistics” is so appropriate parallel to software.

The problem is simple. The cycle begins typically when a faculty member or staff member sees the use of a software in another institution or have been blown away by a software at a conference or through a webinar. We are then called in to assess. I should say that I am so thankful that LTS is involved in very early stages of this cycle at Wellesley.  I know this is not the case in many other institutions.

Whoever initiated the request generally has brought along their department staff to like the software! We start asking piercing questions because we have to live with this thingy. Those who initiated the request think that we are doing this in order to say no to the software. Our probing in reality has to do with supportability, scalability, data security, true cost of initial implementation as well as ongoing costs. In general this step is adversarial – those who like the software (who generally do not have the full picture) and the technologists (who tend to go overboard in analysis) see each other as an adversary. It is almost always the case that the software tends to be a solution for an unstated problem! It goes like “if we had this software, we could be far more efficient”, a hypothesis that never goes tested.

It is for this reason that many software sales people reach out to the departments first and bypass the technologists. Those in the leadership role have an important role to play in moderating both the sides and assess the solution as objectively as possible. I should also say that the technologists fall into this trap too! We all go to conferences, see some solutions, fall in love etc. etc.

Now, to the point. I am yet to see a software which delivers everything that the sales folks claim that it does (Lies and Damned Lies part). Typically some functionalities exist and work well, but others are in development for delivery in the future. In many cases, these new functionalities are vaporware. Or that these additional functionalities are add-ons, bolt-ons or whatever, costing more money. Minor detail that someone forgot to tell you. Or that they told us, but we are in such love with the software that we didn’t hear it properly.

Similarly, more often than not software implementations are not done within the budget. The vendor estimates are generally low and the estimates from the institution is low too, because, again, we want to get it through all the channels as fast as we can. Then we struggle to keep within the budget. The result of this very institution dependent, some pour more money (depending on who is in love with the product) or finger pointing will begin and reduced implementation will result, not exploiting all available functionality.

The solution to this is rather simple – common sense. Accept the fact that our users will always find software that they like. Be as objective as possible and present your realistic assessment. If you are implementing a software, be diligent and get the vendor to be as specific as possible and get everything in writing. Present a realistic multi-year budget that has contingencies built in and clearly includes what is required from our own internal resources. When the finance folks see how much internal resources are required for the completion of the project and its valuation, generally, their jaws drop. In the budgeting, one needs to figure in the backfilling required when you take your staff away from their day job and allocate them to the project. Budget for training! And worry about intangibles like relationship building, communication etc. for the success of the software implementation.

And I can promise you that the vendor who sells you the software does not count the cost of all of this!