10.5 Doing RFPs Right

 < Day Day Up > 



10.5 Doing RFPs Right

The purpose of the last section is to sensitize you to the vendor mindset so that when you manage your next RFP process, you can better understand why responses do not come back exactly as you expected. Keep in mind that the vendor really wants to know:

  • What exactly is the customer asking for in terms of design, implementation, documentation, and support?

  • How much work will the customer perform (i.e., what are the roles and responsibilities of each party)?

  • How will risks and exceptions be handled? In other words, how is potential scope creep defined and addressed both managerially and financially?

  • What is the preferred pricing methodology?

  • What is the targeted price?

  • What desired vendor services are "baseline," and which are considered optional and can be presented and priced as such?

  • What future opportunities can result from a job well done this time around?

This last question may appear to be out of place, but it is not. Vendors quite naturally desire long-term relationships. From your RFP perspective, the opportunity for future business may give them cause to shave your potential costs up front, with the expectation of gaining future opportunities. This is, of course, a big carrot, but one you must use carefully. The vendor does not expect any promises, but is in actuality trying to gauge your willingness to negotiate and be open minded during this courtship. This is particularly true if the RFP deliverables represent a new technology or process for the customer.

If you do not do a good job of projecting your open mindedness, most vendors will respond somewhat cynically, unless the sales manager for a particular vendor is desperate to make quota or is new to the role and thus somewhat naïve. If you are not open minded because you prefer, or are directed to prefer, a specific vendor, understand that most vendors anticipate this. They may be disinclined to respond to you with value, either now or in the future. I see a lot of people disregard this, but in the business world as it appears to be shaping up at the start of the new millennium, I would remind you that your own personal credibility is all you have, given the disappearing corporate loyalty and tenure characterizing the work-place.

Exhibit 4 is dedicated to the RFP process and the steps through which you should manage, in case this is the vehicle selected for meeting one or more project deliverables.

Exhibit 4: RFP Process

start example

  1. Verify that existing vendor contracts do not meet project requirements.

  2. Understand corporate RFP requirements (e.g., legal, procurement).

  3. Clearly define scope, requirements, and implementation strategy.

  4. Develop supporting data, drawings, and workflows.

  5. Clearly define key milestones, including dates and attributes.

  6. Clearly define risk.

  7. Identify key tasks and deliverables desired from the vendor.

  8. Identify any optional tasks that could be assigned to the vendor.

  9. Gain stakeholder agreement on items 1 through 8 before writing your RFP.

  10. Include project background, scope, and anticipated vendor deliverables.

  11. Include all information that will help the bidders understand your project.

  12. Include "boilerplate" terms and conditions your contract will incorporate.

  13. Include a schedule for the process, with deadlines and decision dates.

  14. Include vendor selection criteria.

  15. Issue the RFP.

  16. Solicit questions.

  17. Distribute answers to all questions to all respondents.

  18. Hold a bidders' conference to allow one final round of clarification.

  19. Perform a thorough analysis of all responses.

  20. Make your vendor selection as per your predefined process.

end example

It is important that you fully understand the project before launching into the RFP process. If the RFP is not clear, then you cannot expect the responses to add much value either. A rough RFP can generate a lot of chaos as potential bidders flood you with questions. You can expect a lot anyway, but you want to avoid spending any more time on that than you have to. In any case, it is important that you capture all questions, and distribute answers to all vendors on the bid list. Do not identify the source of any question. This may require paraphrasing some questions if the bidder uses language or product names that might reveal his or her identity. Protecting anonymity helps maintain probity, which you should feel obligated to do.

It is also a good idea to schedule a bidders' conference. This should occur sometime between publishing answers to the initial bidder questions and the due date of the final responses. Be sure everyone has a chance to participate. These meetings are generally quite awkward because you are hosting a room full of competitors. I like to review the project one more time, go over the published questions and answers, and allow some time, but not too much, for questioning. It is important to try to control this session because you can expect one or more individuals to try capturing your attention as though this meeting were a sales opportunity.

During this process, you must avoid communicating with individual vendor reps about the RFP from the time its existence becomes public knowledge through the award date. I once protested an award to a different vendor when it was quite obvious that the customer was cozying up to that vendor at everyone else's expense. I actually got an audience with the firm's senior procurement officer as a consequence. Although he denied my supposition of favoritism, the bid went to the suspected favorite. Oddly enough, however, I began receiving business from this customer who had previously ignored yours truly and my company. In some instances, the repercussions for being disingenuous with this process can be far worse than getting a cranky letter from a disappointed salesperson, so be circumspect in this regard.

Many RFP issuers predetermine a selection criterion and, in fact, may include it in the RFP itself because most bidders are going to ask on what basis the award will be made. This process often is a scorecard system, where the first level of analysis is based on the percent to which each bidder professes compliance against individual RFP requirements. Pricing is generally, but not always, given as a key but not sole determinant of the award. Be sure and leave yourself wiggle room on this. Unless your procurement rules stipulate that the lowest bid must win, you want to reserve the right to make your final decision on the overall quality of a particular response in conjunction with other factors that you do not necessarily have to share with the vendors.

Vendor relationships created in this manner end up going through the contract process. During this phase, people in purchasing and legal will become your best friends. This is rarely a quick or pleasant experience. This document will end up with a statement of work (SOW) detailing what is required of the vendor. Of course, a pricing section is included, where the actual costs are embedded, along with payment and penalty schedules. Organizational commitments may be included, too, whereby the two companies formalize the interactions from a management and escalation perspective. And finally, there will be terms and conditions regarding exit strategies, indemnifications, protection of intellectual property, and so on.

It is difficult to generalize regarding the proper level of your involvement in this process, other than to mention that it is not unusual for it to drag on for so long that work is started and dollars are expended by both sides before all the paperwork gets hammered out. The other issue to anticipate is that once the lawyers get involved, the process tends to turn into a risk-avoidance exercise. Each side will be looking to protect itself from any evil the other side could knowingly or unwittingly visit upon the other. Besides being the root cause of interminable delays in getting the final document executed, it gives project managers reason to worry that the contractual definition of deliverables, roles, and responsibilities might be diluted beyond recognition. There is no magic bullet for this other than staying involved and trying to keep things moving along.



 < Day Day Up > 



Complex IT project management(c) 16 steps to success
Complex IT Project Management: 16 Steps to Success
ISBN: 0849319323
EAN: 2147483647
Year: 2004
Pages: 231
Authors: Peter Schulte

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net