During my years in the Quality Management Systems arena, I was always intrigued by the fact that companies felt confident enough to purchase business-critical software on the basis of watching a demo but without evaluating the product on their home turf, infrastructure, and organizational context. Naturally most software vendors like it that way, and in the past there were actually some technological briars preventing POCs and trial periods. However, I believe that with today’s technology and shift in customer’s buying process, I believe it’s time to revisit the old approach and challenge old assumptions.
In this article, I will try to outline the challenges to having a POC, in Part II I will discuss why I believe that a POC is a win-win exercise for both you and your software provider, and in Part III I will share some of the lessons I learned the hard way from running POCs and implementation projects, which should help you to successfully engage in a POC and select the right software for you. For the purpose of this series, by “POC” I mean a Proof of Concept or a Pilot period, usually lasting 1 month, sometime paid but usually unpaid.
Like Buying a Car
Let’s say you are interested in buying a car. You’ll probably try to identify your needs and preferences to the car of choice, maybe define some decision-making criteria, and read a lot of articles and competitive analysis of the cars available on the market. But would you even consider actually purchasing it without driving it? Would you have sufficient confidence, after all of the information you’ve gathered, that this is the car for you?
Of course not! You’d probably want to take if for a spin, and make sure that it drives the way you expect (and ensure that the engine is as powerful / economic as you expect it to) , that your partner for life likes it as well (making sure it has all of the security features he was promised), that your kids like the back seat (and that they have a power output for their smartphones), etc. You get the idea, right? Analysis and data gathering goes a long way, but there’s nothing like trying out for yourselves.
But while our buying habits as private consumers has come a long way in the past years, B2B purchasing process didn’t change much and today companies are still purchasing business critical software without trying it out in their own organizational environment, despite a much higher potential damage incurred by selecting the wrong product for the business; The worst that could happen when you buy the wrong car is that you sell it and buy another, but for a company purchasing the wrong software could mean losing millions of dollars in licenses, wasting significant employee effort, and even endangering brand reputation!
In the current B2B purchasing process, the only times that business users evaluate system functionalities is usually during the demo(s). Now demos are a great evaluation tool, but they usually utilize a way more advanced software version from the one on the market, and are built and configured to bypass software bugs, to look good, and to have a “wow” effect using capabilities which are sometimes yet to be available to the market. Moreover, the demo is driven by a highly experienced specialist, who has demonstrated the software many times in the past and knows very well how to stir away from the software’s pitfalls and weaknesses. Going back to the Car analogy, this would be like being taken to a test drive in a super car driven by a Nascar driver.
Software providers usually object the mere idea of trial periods and POCs claiming that for Enterprise software to work it must be tailor made to the requirements of the customer and therefore requires extensive requirements analysis, configuration, testing, integrations, validation, etc. Moreover, many organizations claim that spending a full month on evaluating a software and doing so within their infrastructure is too time consuming and requires too much effort from business and IT alike.
Now, I’d agree that this used to be the case some years ago, when everything had to be installed on premise and built from scratch for each instance, thus requiring significant IT effort to even begin any sort of evaluation. However, do you really need to test drive a car with the exact same seats, tires, color, and finishing of the one you are about to order? Moreover, do you need to drive it cost to cost to evaluate whether or not this is the car for you?
Of course not. You should drive a car from the same model and similar enough to the level of the one you’re about to order, and drive it long enough to evaluate how it drives and operates; just enough to help you envision a day in your life with the car of your choice.Similarly, with today’s Saas technologies, along with industry best practices, Quality Management software today comes fully loaded and ready to go, despite any customizations and integrations that each company might do in the future, and therefore POCs are completely possible from both technological as well as business aspects. By evaluating the software’s core capabilities, and focusing on key capabilities that are important for you team, you can tell very quickly if this is the right choice for your business.
Moreover, it doesn’t take that long and it’s not as time consuming as one might think! Our experience from running POCs shows that out of the formal 1 month allocated for the POC, users usually spend no more 2-3 hours per week evaluating the software. Now that’s not insignificant by any means, but to me it seems like a reasonable price to pay in order to make sure you’re selecting the product most suitable for the needs of your business So far for Part I, stay tuned for the next chapters in which we’ll discuss why a trial period is a win-win, and a few critical things to consider when in a POC.
Have your thoughts about POCs? Share them with us in the comments!
