Product Selection and POC Management

As part of our advisory services, Daman helps guide critical architectural decisions for our clients. Once a client has accepted a technical architecture with key technical components identified, we move to the next critical exercise ― the selection of appropriate products.

The technical-component classification scheme (delivered during Architecture Design) typically identifies product functionality necessary for the client. Daman further refines these criteria using pre-existing evaluation classification schemes, informed by client specific needs. A weighting scheme is applied to this selection process by mutual agreement with the client. At this point, we are ready to proceed with an industry survey and vendor short-listing.

Daman can efficiently and effectively short-list viable options for the client based on our prior experience, surveys of existing clients, opinions of analysts and other industry information. The selection process can be as streamlined or detailed as required by circumstances or client needs.
Often responses to preliminary requests for information (RFIs) can assist in defining draft scores for vendors and their products. These responses, along with the evaluation criteria and target architecture definition are then used to help define appropriate proofs-of-concept.

Proof-of-concept

Selecting the appropriate tool is critical to a successful proof of concept (POC) process, and Daman can help you make the right choices based on the following fundamental best practices:

“Just-right” specifications. The POC must test the functionality that is most critical in your environment but also, and maybe more importantly, the functionality that will truly discriminate between products and help you compare your options. Select use cases that are meaningful, interesting and can demonstrate business value. At the same time, select those with manageable scope.

“Just-right” duration. A successful POC can neither be too short or too long. One or two days is not adequate for proper evaluation, and two weeks is too long and verges on becoming a mini-pilot. Somewhere in between is the right amount of time to learn about the product, get some hands-on experience with the tool, understand the vendor, and see whatever needs to be seen to make a fair evaluation.

“Just-right” evaluation team. It is important that the evaluation team have all key decision makers (management, business representative and IT architect). It is equally important that the team is lean enough to be effective. Organizational science tells us that teams in excess of five can be dysfunctional, and we agree.

“Just-right” involvement. You, the client, must stay engaged during the process to see what it actually took to achieve the end goal. Simply evaluating the results will not do. Having a well-defined plan prior to the POC start ensures client personnel availability and also tests the vendor in terms of their ability to meet a pre-defined plan in terms of both personnel and product. Further, if your own personnel present the POC results, you are assured of true engagement and a better understanding of the product.

“Just-right” infrastructure. The install should be part of the POC. Run the software from hardware inside your firewall. This will make it much easier to ensure that the software is a fit for your hardware environment. Integration needs to be a key element of your evaluation. Unless the software is installed inside your firewall, integration to your components is not going to be possible.