Follow these dos and don'ts for getting the best deal for your network project.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.DoDon'tBuilding an RFP team \u2022DO involve members representing all areas of buy-in and sign-off \u2013 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. \u2022DO 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\u2019 technical people, and someone who can describe the business needs that the RFP is intended to fulfill. \u2022DO point out that through their 401K or profit sharing, employees are invested in the company\u2019s performance. Getting a good deal on the RFP will help the bottom line.\u2022DON'T let groups represented on the team rotate people in and out. They\u2019ll have no continuity, be unaware of agreements the team has already reached and generally slow things down. \u2022DON'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. \u2022DON'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 \u2022DO 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.\u2022DO 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. \u2022DON'T tell suppliers who else is submitting an RFP. They know their competitors\u2019 prices and will tailor their bid to slightly undercut them rather than giving you the best deal.\u2022DON'T ever reveal your budget. That will tell suppliers just how high they can push the price of their proposal.Writing the RFP \u2022DO: 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\u2019t considered.\u2022DO: Notify vendors the RFP will become part of the awarded contract. If they won\u2019t stand by it contractually, the RFP should be suspect.\u2022DO specify the format you want proposals sent in \u2013 CD, paper, floppy \u2013 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.\u2022DO require separate attachments that can be distributed easily among your corporate departments. For example, the vendor\u2019s financials will have to be checked out by your financial people, so have that information attached separately for easy detachment and disbursal.\u2022DON'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.\u2022DON'T let vendors keep information that is proprietary to your business. Get it back. Don\u2019t describe more of your network environment than they need to know to bid.Evaluating RFPs \u2022DO ask end users what features they need vs. those that would be just nice to have. Make the must haves your high-level requirements.\u2022DO 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. \u2022DO drop further consideration of an RFP immediately if it contains a deal-breaker. If you have a McIntosh shop and a vendor doesn\u2019t support McIntosh, don\u2019t waste more time evaluating. Your goal is to get between one and three finalists. \u2022DON'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. \u2022DON'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 \u2022DO make sure features and functions are actually demonstrated, not just talked about.\u2022DO 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.\u2022DO document what you heard in the session as soon as possible, and certainly before you sit through another vendor\u2019s demonstration. You have to keep the vendors clear and distinct in your mind.\u2022DO watch non-verbal communications. See whether the sales pitch makes the vendor\u2019s technical team fidget or roll their eyes.\u2022DON'T pay for product evaluations. You don\u2019t pay to test drive cars, do you? But you need to know if a product works in your environment.\u2022DON'T consider alpha and beta products. Just view what is generally available or will be when the contract has to be fulfilled.\u2022DON'T go to the vendor\u2019s facility for a demonstration. You want to see it work in your network environment and see how it affects performance of other traffic.\u2022DON'T permit vendors to stray from a technical discussion and avoid answering your questions.