Problem solve Get help with specific problems with your technologies, process and projects.

Demand good proposals: Tips for writing an RFP

Learn five guidelines that will improve prospects for proposals that actually respond directly to your requirements.

When you publish a Request for Proposal (RFP), you're looking for responses that tell you clearly and concisely...

how a security vendor is going to solve your problem. Too often, though, you're left reading through page after page of marketing filler laced with company acronyms, with little or no sense of what it means to your environment -- heck, you can get that off the vendor's Web site.

IT security professionals don't have time for this. Some proposals are so painful to get through that organizations would simply eliminate them outright regardless of how well the solution might fit.

The RFP response is an opportunity for vendors to earn your business. Write the RFP as concisely as possible and include a description about your mandates for responses. It's time to define some ground rules. Vendors won't stop playing wasteful marketing games until users set expectations on what is acceptable.

Below are five guidelines that will improve prospects for proposals that actually respond directly to your requirements.

1. All questions and requirements must be addressed directly

This means the vendor needs to avoid the marketing rhetoric and acronyms, and simply address the specific needs presented in the document. A vendor that can't meet a certain requirement should be honest and state this in plain English. Fulfilling this requirement requires conciseness, not unbearable detail -- figure five to seven pages of text in most cases. A well-prepared and thorough RFP response (supported by graphics and figures) may be longer than seven pages; the point, however, is that useful content is good, marketing double-talk is bad.

2. The response should include details about architecture and deployment

Vendors love to talk about features and benefits but often forget to address the physical layout of their solutions or the effort required for implementation projects. Where do the components sit? How will a distributed solution communicate? Are there security concerns? Are there deployment options or complexities to consider? Can a solution tier administration? Can it be implemented in either a distributed or centralized fashion? Can it be configured so it is efficient in terms of network bandwidth? Remember, the vendors are the technology experts here, so they should be creative and meticulous.

3. Text must be supported with graphics

A proposal should weave together graphics and text in an effort to make the document both succinct and thorough. Insist that vendors include graphics that illustrate how it addresses requirements. For example, distributed solutions should be supported by topology maps that help users visualize the product architecture. Management tools should include screen shots that specifically address user needs.

4. Comprehensive pricing is required

Software and maintenance costs are only a piece of the puzzle. What about additional hardware like servers, switches or management consoles? Will you need a back-end database? How about professional services and user training? Again, demand that vendors "walk a mile in your shoes" and provide details, not a runaround.

5. A business solution must speak to your needs

The RFP response should reveal that the vendor understands your business issues, addresses them effectively and can deliver near-term ROI. State your business problems clearly and demand that the vendor respond in kind.

About the author:
Jon Oltsik is a senior analyst at the Enterprise Strategy Group, and previously VP of marketing and strategy at GiantLoop Network and senior analyst at Forrester Research.

This was last published in June 2005

Dig Deeper on Microsoft Patch Tuesday and patch management

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Another good tip is to do your research before writing the RFP and know what to include and what to exclude from the RFP. Our organization has been performing valuation activities (derived from applied information economics) on many of our projects. These activities not only help us understand the value provided by the projects, but one of the byproducts is that we are able to see what project information provides little or no value to the project as a whole. The results are often surprising because information we thought would be extremely valuable often turns out to have little or no value whatsoever. The same principles can be applied to writing an RFP so that the information that will provide the most value can be included in the RFP, and less valuable (or no value) information can be omitted, thereby allowing both you and the vendor to provide and focus on the most relevant information.