RFP strategy

Follow these dos and don'ts for getting the best deal for your network project.

By Tim Greene, Network World
May 19, 2003 12:02 AM ET

As the manager of telecom procurement for insurance giant Aetna, Donna Daigle oversees purchases of $143 million in telecom services and network gear. She also is a member of the Caucus, an association of technology procurement professionals. Recently at a Caucus seminar called "Writing Strategic RFPs" she shared some of her expertise in creating RFPs, assembling teams to write and analyze the documents, and how to effectively negotiate with the vendors who submit them.

Do

Don't

Building an RFP team

•	DO involve members representing all areas of buy-in and sign-off – end users, IT staff, legal staff, network security, procurement, human resources. They all have to be involved at some point anyway, so they might as well have input from the beginning.
•	DO restrict who on the team is allowed to speak directly to suppliers. Keep it to two people: a technical person to talk to the suppliers’ technical people, and someone who can describe the business needs that the RFP is intended to fulfill.
•	DO point out that through their 401K or profit sharing, employees are invested in the company’s performance. Getting a good deal on the RFP will help the bottom line.

•	DON'T let groups represented on the team rotate people in and out. They’ll have no continuity, be unaware of agreements the team has already reached and generally slow things down.
•	DON'T let vendors contact employees outside of team meetings or this will tie up too much time. Also, vendors will use the opportunity to ferret out information such as deadlines and budgets that can give them an advantage.
•	DON'T promote the idea that the RFP must yield the best product at all costs. The cost must be in balance with business needs.

Dealing with vendors

•	DO look for the slide vendors flash up quickly to show the names of their marquee customers. Assign team members to write down the names in a quadrant of the screen to get as many as you can for checking out later. These customers may not be on the list of satisfied customers vendors give you to contact as references.
•	DO get vendors to sign non-disclosure agreements regarding the RFP, otherwise they may pass it around and you will be flooded with bids from vendors you have no interest in. The RFP may also contain information your company considers proprietary.

•	DON'T tell suppliers who else is submitting an RFP. They know their competitors’ prices and will tailor their bid to slightly undercut them rather than giving you the best deal.
•	DON'T ever reveal your budget. That will tell suppliers just how high they can push the price of their proposal.

Writing the RFP

•	DO: Allow space for creative thinking by the suppliers. Describe your business needs and see what they come up with rather than describe the exact network gear or service you have in mind. They may pleasantly surprise you with something you hadn’t considered.
•	DO: Notify vendors the RFP will become part of the awarded contract. If they won’t stand by it contractually, the RFP should be suspect.
•	DO specify the format you want proposals sent in – CD, paper, floppy – and the number of copies you want. You want to be able to immediately distribute the RFP to your team without waiting days to get copies.
•	DO require separate attachments that can be distributed easily among your corporate departments. For example, the vendor’s financials will have to be checked out by your financial people, so have that information attached separately for easy detachment and disbursal.

•	DON'T let vendors ramble on and on. Limit the number of pages they are allowed to submit. This reduces the time it will take to review them. You can even specify the minimum font size.
•	DON'T let vendors keep information that is proprietary to your business. Get it back. Don’t describe more of your network environment than they need to know to bid.

Evaluating RFPs

•	DO ask end users what features they need vs. those that would be just nice to have. Make the must haves your high-level requirements.
•	DO develop a point system. You need some objective way of ranking the proposals. Divide the RFP requests into must haves and nice-to-haves and award more points for must haves.
•	DO drop further consideration of an RFP immediately if it contains a deal-breaker. If you have a McIntosh shop and a vendor doesn’t support McIntosh, don’t waste more time evaluating. Your goal is to get between one and three finalists.

•	DON'T have a large number of choices for scoring. Award one, three and five points only based on individual requirements. By excluding scores of two and four points, you spread out the numerical value so when you calculate the average, you get a bigger difference between competitors.
•	DON'T have everyone read the entire RFP. Divvy up the work into sub-teams that take only certain sections from all the RFPs and compare them.

Demonstrations

•	DO make sure features and functions are actually demonstrated, not just talked about.
•	DO find out if any product modifications were made to get the demo to work. This means you may have to pay extra for these same modifications if you sign with them.
•	DO document what you heard in the session as soon as possible, and certainly before you sit through another vendor’s demonstration. You have to keep the vendors clear and distinct in your mind.
•	DO watch non-verbal communications. See whether the sales pitch makes the vendor’s technical team fidget or roll their eyes.

•	DON'T pay for product evaluations. You don’t pay to test drive cars, do you? But you need to know if a product works in your environment.
•	DON'T consider alpha and beta products. Just view what is generally available or will be when the contract has to be fulfilled.
•	DON'T go to the vendor’s facility for a demonstration. You want to see it work in your network environment and see how it affects performance of other traffic.
•	DON'T permit vendors to stray from a technical discussion and avoid answering your questions.