For small companies, it's about developing relationships. For big companies, it's about developing RFPs. But regardless...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
of company size, analysts and users agree that the key to purchasing new products is knowing precisely what you need and making that clear to the vendor.
A request for proposal (RFP) or request for information (RFI) is a necessity for large companies. RFIs are for "start from scratch" purchases such as evaluating how to replicate data for disaster recovery. On the other hand, RFPs are for when a company knows specifically what products it needs and wants to get the most bang for its buck.
In either case, there is room for error. Bill Peldzus, director of storage architecture at consulting and services company GlassHouse Technologies, Framingham, Mass., said that the most common mistake is "not clearly defining your requirements and not clearly defining the current state of your storage environment."
Peldzus also warned against vague timelines and open-ended questions in RFIs or RFPs. "There should never be a question that can't be answered with 'yes' or 'no' or a number or quantity."
No time for an RFP
Michelle Poolet, president of Mount Vernon Data Systems, a small company in Colorado with only two full-time employees, uses continuous data protection (CDP) software. She has been beta testing TimeSpring Software Inc.'s TimeData for six months, but has just now starting testing XOSoft's WANSync replication software. "I have to evaluate one product at a time to really understand it. If it's too quick, I'll only get the marketing view," she said.
MetLife Investors Group Inc., a subsidiary of Metropolitan Life Insurance Company (MetLife), has 500 employees and has been around for four years. "We're still in the startup mindset, so there just isn't time for an RFP and a lot of testing," said Jesse Correll, manager of IT infrastructure.
Correll said that for product purchases, he gets recommendations from his value-added reseller (VAR) and then will have vendors in for hour-long demos. He will then whittle it down to one vendor and then do proof of concept (POC) testing for 30 days before making a final decision. Correll recommends that companies do POC testing on site rather than at a vendor's lab to make sure the product works with your equipment.
MetLife recently purchased a DX30 virtual tape library (VTL) from Quantum Inc. and did most of the testing at Quatum's lab. Correll said he would have preferred to have done it at his own site. "But when you're a small company, it's often too expensive and time-consuming to have the product brought to you," he said.
Let vendors know where they stand
Colospace Inc., an outsourcing company in Cohasset, Mass., that offers a variety of services including disaster recovery, doesn't do a formal RFP either, but uses a confidentiality agreement.
Colospace typically identifies two or three vendors that can solve their problem. "We look for established vendors, ideally ones we've already worked with," said Aaron Sawchuk, CTO of Colospace. The company follows the apples to apples approach, always creating common criteria to evaluate similar products.
Sawchuk said that it's good practice to be honest with vendors and never rule one out just because it tested poorly. "Vendors appreciate candid feedback, even if it's bad news. And you never know what product you may re-examine later," he said.
Peldzus agreed with being upfront with vendors and recommends having a pre-meeting immediately after an RFP is distributed to see if the vendor has any questions.
Randy Kerns, senior partner at the Evaluator Group, Greenwood Village, Colo. said another common mistake during evaluation is looking at price only. "The bigger issues are storage management and exploitation of features that may lock you into one vendor."
Kerns also said that an evaluation should start out with three or four candidates, but quickly boil down to an A vs. B situation where a common set of requirements (capacity, availability, throughput) are used to pit the vendors against each other.
At that point, it's always interesting to see what vendors will do to win. "Many will throw in free software, free training, discount the maintenance fees or offer to configure your SAN for you," said Peldzus. "When it's down to two, it's fun for the customer -- but not that much fun for the vendor."