Migrated from eDJGroupInc.com. Author: Mikki Tomlinson. Published: 2012-05-23 14:00:20 Chuck Rothman wrote a great post on Separating the Wheat from the eDiscovery Software Chaff last week. I would like to expand on that and take it two steps further. If you are evaluating software for purposes of a long-term partnership with a preferred vendor or are making the commitment to bring something behind your firewall, you should add formal request for information (“RFI”) and proof of concept (“POC”) phases to your project.When done properly, developing an RFI will force you to fully flesh out and document your needs. It is a tedious but worthwhile process. Committing the time and effort at the front end of the project – the RFI phase – will make the POC phase much easier because you will have already determined what your needs and priorities are. Thus, the scripts/use-case scenarios to be used in the POC are essentially already developed.A law firm recently asked us to make recommendations for a long-term solution without going through the RFI and POC process. Their expectation is that eDJ’s vast knowledge of the eDiscovery market and tools puts us in a position to do that. Yes, we have a significant amount of knowledge of the tools and their capabilities, but that doesn’t mean we can or should make a straight out recommendation without getting to the granular level of documenting needs and priorities. I liken this to asking a realtor to select a house for you without telling him or her what you need. How many bedrooms, what area, old versus new construction, what are your have-to-have requirements versus your nice-to-have requirements, budget, etc.?Going through the RFI and POC process is the purest way to judge how well a solution truly aligns with your needs. Every RFI and POC I have gone through has proven to be a healthy exercise for the team. Each one has also produced “lessons learned” to be carried to the next project. At the end of the day, working through these processes leaves the team with confidence in their decision, a good sense of where the “gotchas” are and work-arounds may be required, and the ability to present a solid proposal to the check-signing powers that be.I have heard horror stories of RFI’s and POC’s gone bad. In order to avoid being the next horror story, below is a list of elements and methodologies for a successful project.The RFI Process:
- Define project team roles and responsibilities at the outset and invite the right stakeholders to the requirements gathering table.
- Be sure to incorporate not only questions about what the solution does, but also about the provider or software company, such as how long they have been in business, the profile of their client base, number of installations, and number of clients on active maintenance.
- Formulate the solution/product questions in a voice that requires a response format that can be scored. The scoring method should include the weight of importance of the product functionalities to your company or firm. (Note: the scoring function is done by the project team and should not be exposed to the responding vendors.) This will allow you to easily select which vendors will move to the next step.
- If you have engaged a consultant to assist with the project, consider having them present the RFI to potential responding vendors as a “blind” RFI. This will save you a considerable amount of time in dealing with endless sales calls, emails, and other tactics. Once vendors are selected to move to the next phase of the project, the consultant can set the guidelines for when and how the vendors should communicate (or not communicate) directly with you prior to revealing your identity.
- Prepare a list of reference questions in advance and ask the same questions of each reference.
- Document your findings and recommendations and present them to the person(s) that will ultimately approve the purchase prior to moving to the POC phase.
The POC Process:
- Be sure to engage the proper IT resources throughout the entire POC phase.
- Use the questions from the RFI to script use-case scenarios to be put to the test.
- Ensure that each participating vendor has equal opportunity (e.g., the same amount of face time, follow-up options, etc.).
- Building on the scoring you did in the RFI phase, score the success of the product in action based on your requirements and use-case scenarios.
- Don’t be shy about your subjective opinions of using the product (e.g., how much you like the look of the user-interface, intuitiveness of the solution, etc.). This is an important factor in the decision making process.
Once you have gone through the RFI and POC process and are ready to make a recommendation for purchase, you will have a very impressive story to tell to the ultimate decision maker. In my experience, a presentation that describes the process, milestones, and findings that brought you to the proposed recommendations leaves the decision maker with a confidence that a thorough job was done and the recommendations made are appropriate.At the end of the day, the result is worth the effort.