CIO Insight: The before and after of the RFP

   For a company buying technology, it’s often easy to get caught up in the delirium of what that system will provide. Never mind the process of choosing a vendor, preparing for deployment, and implementing, it’s all about the end result.
   But the reality is the end result is never as satisfying when companies forget about the hard work of preparing a suitable request for proposal (RFP). And when they do, it really puts the onus on software vendors to raise their games, to look internally at themselves at their products, support capabilities, and vision for the future.
   I was recently reminded of how critical a step this initial process is toward a successful deployment of technology when speaking to Gary Chisamore, vice president of the logistics solutions provider Freightgate.
   Chisamore described to me, in great detail, the painstaking process it took to respond to an RFP from a top 10 global shipper (in this case, a freight forwarder). Back in 2014, the shipper was looking to acquire a transportation management system (TMS), with embedded rate management and routing guide functionality.
   Since Freightgate offers software to handle those functions, the next step was to answer initial inquiries, a process that precedes the RFP and is known as a request for information (RFI). This is essentially the step where a prospective buyer determines whether the software vendor is even suited to provide the solution sought.
   The RFI included areas like the scope of solutions, languages supported by the software, and the partners involved in delivering the services.
   Once Freightgate had cleared that initial hurdle, the real work began. And the shipper had certainly done its homework.
   “The RFP was much more detailed than we expected,” Chisamore said. “The ‘nice to have’ and ‘must have’ functional requirements had over 250 questions. Of course [the customer wanted] details of [Freightgate’s] financial stability, disaster recovery, management continuation, architecture, infrastructure security, support policies and procedures, organizational structure, technical resources, staff relations philosophy, EDI formats supported, and experience. It became a scramble to complete all that before Christmas 2014. In total we completed over 600 questions in five sections, excluding the pricing proposal. We took the opportunity to provide an outline about the solutions that we thought would help the client and work in concert with our platform.”
   Chisamore called the RFP and evaluation the “most detailed and thorough review we had ever experienced. The ‘must haves’ and ‘nice to haves’ were obviously written by domain experts. They certainly knew what they were talking about.”
   Freightgate held three meetings with the customer’s global experts to run through their respective sections of the proposal. That led to the next stage—a demo of the solution.
   Chisamore said the customer didn’t want dummy data or a theoretical exercise. The customer wanted its own data (for all modes) used to show what the solution could do for rate and tender management. By this point Freightgate was, of course, operating under a non-disclosure agreement.
   The demo required “significant configuration, mapping, and deployment,” he said. “These were not just 10,000-foot sales demos, but detailed drill downs by the domain experts. Each of the 200 or so functional requirements had to be shown. Multiple sets of demos were arranged to accommodate time zones.”
   At this stage, Freightgate’s demo was scorecarded against other finalists, and subject to pricing, the vendor was told they had won the bid. The customer wanted Freightgate’s hosted application, but wanted it installed in its own network.
   “We scrambled to get our architecture team to determine what was involved in deployment, learn about their network architecture, security, and operating system,” he said. “On top of that, we had to give a new proposal for deploying in a network of which we had little knowledge. Very stressful.”
   Once the contract was awarded there was one final hurdle. The customer required a two-month proof of concept of the solution, run from Freightgate’s network, but the deployment ran for four months due to internal functional requirement decisions and changes to the configuration.
   “The saying ‘you are only late once, but you’re wrong forever’ now seems so apropos,” Chisamore said. “The forwarder took great pains to examine, test and try to break our solution, on several occasions extending the review.”
   Deployment started in early 2015 and has been currently rolled out globally across all of the client’s regions.
   “Did we ever envision what we would go through when we were invited to express an interest in providing our solutions? We didn’t have any idea. It’s as if they whetted our appetite with an RFI and then drew us in via ‘must have’ and ‘nice to have’ functional requirements into the deep dark jungle of minuscule details, scenarios, and ‘under the covers.’ When it was all over, at first we didn’t believe it, and then it sank in,” Chisamore said.
   He said the process not only helped prove Freightgate’s solutions could compete with bigger providers, but could also compete for the business of a massive global shipper or forwarder. More broadly, the process showed that the more prepared the buyer is, the more ready the software vendor is to show what it can do, regardless of size or reputation.