RFPs: Get Them Right from the Start

As the Rolling Stones taught us, you can’t always get what you want. In the IT world, you don’t always get what you need, either. The reason is simple: Poorly written requests for proposals.

RFPs are the jumping-off point for equipment and software purchases, but they don’t always guarantee the right responses. Even vendors that follow an RFP to the letter might propose a useless solution. Often that happens because the RFP is poorly written or it is missing vital information – problems that sometimes don’t come to light until after a solution is implemented.

Given that the Office of Management and Budget has a goal of achieving $3 billion in cost savings by 2015 by closing and consolidating data centers, incorrect RFPs are a huge problem. Choosing the wrong technology for a data center build or rebuild could have serious financial and usability consequences.

Where’s the Disconnect?
There are two reasons that RFPs often run into trouble. The first relates to usability. Often, IT employees create an RFP based on what they think the line of business needs, skipping the all-important step of asking the business team about its requirements. The true requirements should come from those who are going to use it, not the people who are going to support it in IT, said Steve Duplessie, senior analyst at research firm Enterprise Strategy Group.

The second problem is that the IT folks might write an RFP after they decide what they want instead of outlining their requirements and asking vendors what’s available to meet those needs.

“They decide they want this system with this software and this stuff as opposed to starting with the requirements and asking the vendors to give them ideas,” Duplessie said. “They should say, ‘What I really want is an inventory control system that can do X, Y and Z,’ taking the bias of what you assume it to be out of the equation. But people don’t do it that way. They say, ‘Ooh, this is what I want,’ and take the vendor’s spec sheet and write the RFP.”

The result in both situations is a system that doesn’t meet user needs and may not integrate with existing hardware and software. Consequently, users – even in the public sector – often buy IT services without having the IT team’s support or permission. This is a problem, Duplessie said. “The users understand requirements from a functional perspective, but IT understands the ‘gotchas’ – security and backup, for instance,” he said. “The marketing guru doesn’t care about backup or how their [customer relationship management] app is going to integrate with other resources. Today, the RFP is often being bypassed completely.”

RFPs should outline the specific business problems an organization or agency is looking to solve, the contract term, scope of work and any reporting or compliance requirements. It may also include a confidentiality clause and a request for references.

When the right planning goes into an RFP, there are fewer problems in the long run, said Chris Gibes, manager of the solutions practice at CDW-G. One of his customers recently issued an RFP that specified down to the version number the software and hardware drivers needed to be successful, he said.
“They were smart enough upfront to realize they were on a nonstandard platform and build it into the proposal so all the solutions we suggested had those elements included from the start,” Gibes said. “Without doing so, there would have been assumptions from everyone that could have slowed or stalled the process.”