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.
- 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
Requires Free Membership to View
SearchSecurity.com members gain immediate and unlimited access to breaking industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchSecurity.com today!
Michael S. Mimoso, Editorial Director
- 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.
- 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.
- 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.
- 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.
- 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 first published in June 2005