Over the past 23 years as an information technology (IT) consultant and sales leader I have observed many cases when both software companies and potential buyers wasted valuable company resources performing evaluations of software products they were very unlikely to buy. This may be because vendor sales reps enjoy offering proof of concepts as much a engineers like participating in them.
For evaluations to provide value they should: First, be offered only when there is qualified opportunity. Second, they should be performed in a structured manner much like any other IT project. Below are four recommendations on what constitutes a qualified opportunity and how to prepare for a proof of concept.
The vendor and customer should both have a good understanding the problems they are trying to solve as well as their IT stack. The software product should be able to solve all or most of their must-haves in a solution. The customer environment and must-haves should be documented and agreed upon by the customer.
Before conducting a proof of concept, a customer should participate in a demo of the product and should agree that they believe it will meet their needs. In addition to demos, many vendors offer self-service education or learning virtual machines that can help a company determine if they should move to a proof of concept. Some software companies I have worked with provide cloud based demo environments to customers. They can borrow those cloud based environments for a two-week period as opposed to installing the software in their environment. This typically is less time consuming than a customer installed proof of concept.
The customer should review a written budgetary proposal for the product and agree they could get funding for the product if the proof of concept is successful. Discussing budget early will force the customer to get executive buy-in for the proof of concept. Without budget, a proof of concept is nothing more than a science project.
The customer and vendor should develop a written project plan for the proof of concept. If you have never written a document like this, Craig Borysowich provides a great sample on his web site. The proof of concept project plan should include the installation requirements such as how many servers of what configuration are needed in the test lab. The project plan should also include a timeline and required resources from the vendor and customer. Finally, the project plan should include pass/fail criteria and who will sign off on each of the milestones.
If you follow these four recommendations for proof of concepts, vendors and customers will make good use of their company resources. As Brene Brown says, "Clear is kind. Unclear is unkind." Taking the extra time to document a test plan shows you care and you value your most precious resource which is your time.