It’s not always as bad as Theranos, but it is bad.
Since last year, articles about technology startup Theranos have popped up all over. At first, the articles were about the blood-testing technology Theranos was developing didn’t always seem to give accurate results. In some cases, the results were dangerously, fatally wrong. And now it seems that perhaps the company, at least the founder, knew this and concealed it.
I wasn’t surprised. I deal with it every day.
Vaporware: Software That Disappears
The first significant scandal that I remember was dBase IV. Ashton-Tate was the developer of dBase. The company announced a new version to replace its working, but clunky, dBase III as early as 1986. Finally, in 1988 (an eternity in the tech world), dBase IV was announced in February with an anticipated release in July. dBase IV version 1.0 finally arrived in October of 1988. It was buggy and slow. Ashton-Tate finally delivered an upgrade to version 1.1 almost two years later in July of 1990.
It was about that time the term “vaporware” became popular. Vaporware is an announced software product with announced features that does not exist; sometimes it never comes to market. It fades like vapor into the air.
Features that exist, sort of
I continue to hear from customers about things they have read. This software does such and so. This should work like this. Sometimes, it’s “we just signed a contract with x to do our y.” Trouble is, many times I know the software they are talking about. I ask (trying to gather information and tip them off without creating doubt), “Were they using some add-on to do that?” or “May I take a look at the proposal?”
Too often, the reality is that software WILL do what the customer thinks it will. To put it in business terms, the transaction is possible. However, the issue is often that it doesn’t work the way the client was led to believe it worked.
Case Study: Oops, hand over $50K
Several years ago, we met with a client who wanted to buy software for a particular purpose. We made a proposal and included some customization (which was going to be required). The customization was to add a feature that came up in the first 10 minutes of the first conversation about their needs. They purchased the software from a larger provider who quoted a lower price.
Twelve or fifteen months later, I got a call from their IT Director. The conversation started like this, “Bob, you remember the proposal you gave us for our system about a year ago?”
“Yes, I remember,” I replied (biting my tongue because they’d bought from someone else).
“You remember the feature X we discussed?”
“Yes, it was very important to you, I replied.
“Was there some specific secret you knew about how to do that with the software?” he asked.
“Why?” I replied.
“Because our vendor has just now gotten to the point of implementing the software,” he started, “and they want at least $50,000 more to customize it to do that.”
“Oh. Well,” I started, “I knew that the feature was going to have to be customized. I included that in my proposal.”
“I was afraid of that,” he said.
Unfortunately, they were too far into the implementation to change providers at the moment.
Other examples
I wish I could say this was isolated. I’ve run into far too many technology companies pushing products that had severe limitations. Low-end products in the market today are sold to companies that will ultimately find that the architecture (the basic way the software is built) won’t support the volume of transactions they have. I see boxes of software gathering dust in offices; the company purchased them with the belief that they met their needs, and they did not.
As competition increases, I see and hear about more and more proposals that seem dramatically under-stated. A consultant for a now defunct consulting firm told me that it was a regular practice at his firm to submit proposals that underestimated the required hours by 50%. The employees doing the work were then responsible for “selling” the need for the more time to the customer.
Avoiding the issues
Here’s the fact: most vendor salespeople know their product at a features level, not at an implementation level. They know that the payroll system does multi-state payroll. They don’t know how the multi-state features related to worker’s compensation in multiple states, or how multi-state withholding works, or what the system requires if they have employees that work in multiple states during the same pay period. As a result, when a requirements document says, “multi-state payroll,” they say, “We have it.” The fact is that they don’t know enough about payroll or their software to ask the questions they need to ask to give a meaningful answer.
For 30+ years, I’ve believed that before a customer buys software, someone ought to think through HOW they were going to implement the major features. Without this, you may be sold a Theranos: a device that over-promises and doesn’t deliver.
Here’s the key: Ask not “Will the software do this?” for key functions; ask, “Can you show me how the software will do this?”
My CRM server told me that there were Windows Updates to be installed. I typed “Windows Update” in the search, clicked the appropriate item, and clicked “Install now.”