If you're not writing an RFP correctly, you won't get the right tool or contract for your data center's needs....
Here's how to broadcast exactly what you want to the vendors that can provide it.
Request for quote (RFQ) and request for proposal (RFP) mean fundamentally different things. An RFQ is a request by an enterprise or government organization for a quote on a specific configuration. The organization knows what it wants and vendors respond accordingly. The winning bidder delivers that well-defined configuration in the least expensive manner.
RFQs help IT teams scale up existing configurations. They are a useful way to source products when an IT organization is certain that the specified configurations are the best possible way to address a given problem, set of problems or business need. If you've performed internal analysis and have deep expertise on the deployment, or interfaced with another IT team that tackled a similar problem, use RFQs to bring in the right vendors.
An RFP is looser than an RFQ in that an enterprise may describe a particular challenge and related service requirements. Vendors respond with a variety of technology configurations, architectures and/or services to address those problems. The IT organization gives vendors flexibility to design a resolution to the given problem rather than simply supplying a specified product. If you don't know the best path forward, write an RFP and let vendors propose ideas for the best hardware, software and services mix.
Mistakes will cost you
Pre-existing bias causes the biggest mistakes in the vendor proposal process. Some IT executives believe they know exactly which technologies will successfully address a given computing problem and specify RFQs accordingly. But what if the executives don't fully understand alternative architectures and approaches? They may choose a suboptimal environment that costs more than other setups to install and manage, and that may not deliver the expected quality-of-service level.
Here's what a potentially bad RFQ decision can do: An IT executive needs to execute an I/O-intensive, heavy transaction workload, and believes x86-based servers will best handle the compute load with easy management. But it could cost over a million more dollars to deploy the workload on an x86 architecture instead of a mainframe server. Mainframes have massive I/O subsystems and do a better job utilizing computing resources. Writing an RFQ to favor x86-based infrastructure precludes the mainframe option. Conversely, a mainframe-biased RFQ for light, fast Web thread computing capacity would exclude efficient and significantly less expensive x86 servers. Pre-existing bias sometimes yields undesirable, expensive results.
Bias can also get in the way when writing RFPs. A data center manager or IT director sometimes only understands one particular architecture (such as hard disk drives, HDDs), and pre-ordains that technology in the RFP. Perhaps they wrote in language that favors HDDs for the RFP because they believe that spinning disks cost far less than solid-state drives (SSDs). In reality, SSDs may outperform HDD solutions for the given storage situation, costing considerably less when implemented properly.
By some estimates, flash storage now costs about $10 per Gigabyte, whereas hard disk drive storage is about $6 per GB. So solid-state flash is at least 40% more expensive, right? Maybe not.
IT managers are reluctant to fully populate a hard disk. Disks holding mission-critical data use only the first few tracks on each drive, or perhaps only a third of the available storage. A single SDD could reliably hold the same amount of data spread across multiple hard drives, complicating the price equation. With such low utilization rates on hard drives, HDDs' real cost could hit $50 per GB. By putting together an RFP that leads respondents toward HDD architectures, the data center won't get the most cost-effective solution available.
This HDD versus SDD case illustrates another hidden danger in RFPs: a failure to plan for better future technologies. Diligence belongs in an RFQ. Specifying RFPs with limited-life offerings that may be replaced by other, more potent evolving technologies in the short term can also create sub-optimal IT installations.
When writing an RFP, state the requirements of a given workload along with dependencies, service levels and projected future requirements. Don't use biased language that will lead vendors to bid solutions that were pre-ordained by the IT team. Remember -- RFPs invite technological expertise to solve a problem. RFP writers need to give vendors some leeway to propose new ideas without fear of bidding the wrong systems and software because the RFP wording appeared to favor a particular hardware or software outcome. Allow for forward-looking architectural proposals that will help the enterprise grow or utilize systems better.
About the author:
Joe Clabby is the president of Clabby Analytics and has more than 32 years of experience in the IT industry, with positions in marketing, research and analysis. Clabby is an expert in application reengineering services, systems and storage design, data center infrastructure and integrated service management. He has produced in-depth technical reports on various technologies, such as virtualization, provisioning, cloud computing and application design.
Don't put up with vendor fluff: Get straight RFP responses
Check out RFP templates to get started
Colocation RFPs: Eight suggested questions