Resources
Conducting a Dynamic Proof of Concept
Eliminating Risk in Product and Vendor Selection
In today’s economy, it is more important than ever to achieve success when embarking on an enterprise level software project. Of the various techniques used in product evaluation and vendor selection, a well conceived software Proof of Concept (POC) could be your best hedge against project failure. A POC is an excellent way to put a vendor solution through its paces using test cases that are reflective of your business requirements.
Canned software demonstrations definitely have their place in pre-sale and early stages of an evaluation process, but rarely do they deliver the level of detail a prospect should require before making a product, and coinciding vendor selection. It is also unfortunate to note there are vendors whose standard or “canned” software demonstrations are often not demonstrating all they may seem. Vendor demonstrations often contain a mix of real functionality intermingled with screens and features that seem to demonstrate specific functionality but in effect are nothing more than fields on screens with no underlying business logic. Unfortunately this is not an uncommon occurrence in the enterprise software marketplace. We believe the best way to ensure you are not taken in by this practice is to conduct a “dynamic” POC.
A dynamic POC is not that dissimilar to a standard POC, however there are certain key elements that must be included:
- The bulk of the processing should be done on-site with direct involvement from your evaluation team. This will ensure all results were produced by the system with no manual intervention or back-end system manipulation.
- New test cases and new requirements should be introduced as part of the POC in order to gauge ease of setup and flexibility of the product.
- Selected test cases should be slightly modified prior to the processing run as a means of ensuring the system is configurable (as opposed to hard coded).
- Retroactive adjustments to previously processed test cases should be part of the dynamic POC. Retroactivity is a complex concept that requires a total recasting of all previously processed results including the ability to maintain integrity of date specific processing. Many systems fall short in this area which is a critical factor in creation and evaluation of product and project ROI.
It is our belief that dynamic POC’s best identify products capable of supporting your requirements. Another benefit to this approach is the opportunity to work closely with each vendor team in system configuration and problem solving exercises. Pushing hard on specific features and the vendor team in a dynamic POC, may result in a small percentage of computation errors. However, we do not believe this should be overly concerning, especially if errors are the exception and not the rule. Any exceptions encountered in the dynamic POC can be addressed in a follow up session or noted for refinement in the testing cycles leading up to the vendor’s next release. Welcome to the real world of software development; it is simply not magic.
Summary
In conclusion, canned demonstrations that seem to work like magic may in fact contain some sleight of hand. In addition, taking the time to conduct a thorough, well conceived POC will limit the ability of vendors to ignore your requirements while highlighting their strengths. As a final note, don’t bow to the pressure of vendors, who push back when asked to participate in a dynamic POC. A large client base or mention of clients with similar requirements does not guarantee the product will work for you.