In-Depth
The Three Cs of RFPs
Avoid RFP nightmares with three simple but effective project-management best practices: Communicate, Coordinate, Cooperate.
A Request for Proposal (RFP) is a simple concept, but its execution can be anything but. On the surface, an RFP is simply an invitation to external vendors, service providers or consultants (collectively referred to as offerors) to propose a solution to your organization's problem, either complex or critical—or both.
The execution of an RFP, however, is where the real challenge lies. A badly designed RFP can scare away potential offerors … or worse, mislead them into providing inappropriate solutions.
Unlike bids, where you already have a solution in mind and are looking for the lowest cost provider, RFPs invite offerors to propose their best solutions. Though you may have a general idea of what you need, an RFP opens the door to technology you may not have contemplated and approaches you may not have considered.
Evaluating offerors' proposals requires far more analytical effort than evaluating bids, because you're looking at substantially more than just price. You'll consider, among other factors, technical details, the skills and reputation of the offeror, and a timetable for implementation. You'll use a combination of evaluation criteria and methods to find the solution that's best for your company.
At the enterprise level, the RFP process can be time-consuming and a lot of work. Writing the RFP is just one step; you must also invest time in managing the process (and the RFP team), including answering offerors' questions, evaluating their proposals, and making the final award.
Fortunately, following project management best practices—Communication, Coordination and Cooperation—can help you avoid the many pitfalls of the RFP process.
Communicate. Composer/conductor Leonard Bernstein said music “can name the unnamable and communicate the unknowable.” In the business world, we have no such shortcut. We must communicate everything we know—schedules, constraints and project milestones.
Communication isn't just necessary among your internal team players—you'll have to be particularly focused on communicating with your vendors, such as developing explicit requirements that remove any guessing or interpretation. Your project will need to make a contact point available for questions, no matter how seemingly trivial they may be, and team members responding to such questions must realize that a vendor's frequent contact isn't meant to pester but to ensure that all angles of a problem (and solution) have been explored.
Whether you use a project Web site, intranet, or daily status memos sent via e-mail to communicate with your project team, clear, concise, regular communication is the single most important best practice you can incorporate into your RFP process. While it may sometimes seem that you're over-communicating, or that communication prevents you from getting any real work done, keep in mind that communication is what enables others to do their work effectively.
Coordinate. It would be nice if everyone on your team was on the same wavelength or could intuit everything the project leader needs. Instead, you'll have to work in and between departments, with the complications inherent in use of outside consultants. You must deal with all the knotty details of keeping your vendors informed of deadlines, changes in requirements, and clarifications to requirements. It's all a gigantic juggling act, requiring a steady hand, a cool head, and a clear vision of your project's goals. Keep focused, and keep your team focused, by making all the project pieces fit.
Cooperate. Putting aside your own feelings for the good of the project is often hard. Egos, strong wills, prejudices, and unwillingness to change or try new things, can often stymie—if not derail—a project. That's doubly true when you throw in the complexity of dealing with outside vendors, each with specific quirks and ways of doing business.
Adopt a mindset where cooperation is king. In fact, think of an RFP as a Request for Partnership. Ask your vendors how they prefer to receive requirement changes or feedback. Be flexible in setting deadlines and a project schedule
With these Three Cs in mind, we'll look at ways to get the most out of each step in the RFP process.
Build your team.
Without question, an RFP is a team effort, where group dynamics play an important role. Building a team with the right mix of technical and managerial know-how can be tricky, of course. To make the most of your team:
Appoint a Leader Early. You'll need one focal point for the project—a principal contact for all staff involved (and a first point of contact for all offerors). Make sure the leadership is established up front.
Keep the Team Whole for the Entire Process. Make sure everyone on your team understands the RFP process and the commitment required. The staff that prepares the RFP must be the same staff that evaluates vendor proposals and listens to vendor presentations. Continuity and consistency are key.
Solve Internal Problems Before You Begin. Make sure you understand which division or department is leading the project, who is authorized to make decisions, and ensure that funding has been approved (and at what level). Have your political ducks in a row before you submit an RFP. An unclear chain of command or departments in a turf war make your company look less than professional, and that can affect the quality of the results you receive.
Collect and document needs and requirements in your RFP.
With your team's players in place, your next step is to define the problem to be solved. In most cases this will be a lot harder than it appeared at first glance. For one thing, getting everyone on the team to agree to requirements and the language describing them can be challenging.
Identifying (and agreeing to) the problem—and getting it down on paper—is never the one-hour exercise you think it will be.
Make sure everyone on the team understands—and agrees—that they must work together and be prepared to compromise with other team members. The project leader must have enough authority within the group to cast the final vote and put an end to the discussion when necessary.
When writing your RFP, consider these points:
Provide Your Offerors the Lay of the Land. Start by explaining your existing environment—everything from a high-level look at the company climate down to your network topology, location and operation of processing centers, current and projected transaction volumes, and the like. Provide a range of how much you have budgeted for this project, thus helping the offeror to know at a glance if they can reasonably expect to meet your needs and still make a profit. Discuss in black and white the development and implementation standards of your IT department, and explain the key deliverables, how they will be tested, and the penalties for non-compliance. Be specific about the support you will offer (on-site desks and telephones?), what your responsibilities will be, and what you expect the offeror to provide—and in what format.
Supply a List of Limitations. Spell out any contractual obligations, regulatory compliance issues, operations standards and other limitations that may affect the relevance of the offeror's response. Are there security protocols that must be followed? Must the proposal be compatible with existing licenses? Is subcontracting allowed and must subcontractors be approved before they can work on the project? Whatever the restrictions, be sure you're clear about them.
Be Thorough. An RFP can sometimes serve as the basis for a legal contract. Often, it's attached as an addendum to contracts, so be sure you've specified all key points: performance standards, user requirements, training plan, your responsibilities and those of the offe or, and so on. Your thoroughness will pay off in shorter contract negotiations.
Be Specific, But Keep Your Options Open. Your vendors need to know exactly what the requirements of your project are. Explain what you need, but remain flexible. Nothing should indicate you've already made up your mind. You are, after all, asking offerors to propose solutions that solve your problem in innovative and effective ways.
Separate Wants from Needs. Don't turn a blind eye to the nice-to-have features, but be sure you have clearly prioritized the requirements so that your have-to-have features are evaluated with greater weight than the bells and whistles you might turn on later. (Trust me—those bells and whistles look good now but seldom are switched on.)
Think Long Term. Provide perspective on your historical growth patterns. Your projections should ensure the proposed solutions include sufficient capacity today and can grow as your volumes grow.
10 Steps to RFP Success: 1. Build a team that bridges technical and managerial staffs. 2. Write down both the problem and your requirements. 3. Submit the RFP to offerors. 4. Reply promptly to questions. 5. Accept turndowns graciously; be open to multiple solutions. 6. Eliminate non-responsive and late RFPs. 7. Apply your review criteria to each proposal. 8. Invite top scorers to present to your team. 9. Ask for best and final offers; make your final choice 10. Create a contract and award the project quickly. | |
Be Realistic. If your RFP includes a project requirement of 100 percent uptime on your network, your offeror will know you aren't serious. If the response promises 100 percent uptime, you know they're not serious.
Timing is Everything. Don't expect your vendors to turn in their proposals in an unreasonable time frame. If it took you a month to prepare the RFP, allow your vendors at least that much time—and typically more. Remember to add sufficient time to allow for delivery of the RFP to your vendors and for them to send their response back to you. Allow time to check references and review examples of the offeror's work if you've asked for them.
And for heaven's sake, don't schedule an RFP anytime between mid-November and Jan. 1. You may be working full tilt during those days, but it's doubtful everyone on your team or the vendor's team is available during this period. Year-end planning, the holidays, and use-it-or-lose-it vacation days take precedence. If you must start an RFP then, build time for vendor and staff delays into the process.
Submit RFP to offerors.
Once your RFP has been approved by your team and your legal department, it's time to present it to offerors.
Choose Your Offerors Wisely. Keep in mind that in many cases the larger and more complex your RFP, the more effort—and expense—companies must spend to prepare a proposal … and the fewer responses you're likely to receive in return. And the more companies you approach, the more likely you are to receive inappropriate proposals, which wastes everyone's time.
How many companies should you approach? As a general rule, I suggest submitting your RFP to between three and five offerors, but remember other factors involved (regulations, existing partnerships, number of available vendors capable of providing solutions and so on) can impact this number.
Explain the Process. The RFP should clearly describe how you want to receive responses (a checklist helps you evaluate vendors' abilities to support key features, and can easily be transformed into a comparative spreadsheet). If you want to see costs for specific parts of your project, say so.
Explain the project deadlines and timelines and how people on your team will make their decisions. Delineate the criteria for your decisions, such as how many points you will award for cost and timeliness of delivery and what percent of the total score this represents. Do you want a sample license agreement? Make that requirement known in your RFP. You may wish to state that it's to be part of a special section attached at the end of the proposal.
If possible, require that vendors use forms to respond to crucial points such as pricing and major milestones. Standardizing such responses can make things much easier on the evaluation side of things, since your team won't be trying to compare the apples in one vendor's response to the oranges in another.
Specify Deadlines. Make sure your RFP spells out in precise terms when you need the offeror's responses, how and in what format they should be delivered, and to whom.
Answer offeror's questions.
No matter how much care you put into writing the text, there will be room for interpretation. To handle this: Make Vendor Contacts Available at All Times. If separate contacts are necessary (you might need a technical contact, as well as a business contact), include that person's complete information (name, address, e-mail, telephone, fax) in the RFP. Make sure all contacts are always available (during regular business hours) to your offerors during the RFP process. If a contact is out of the office, make sure someone is screening his/her calls and e-mails. For an offeror—and for everyone on your team—every day is critical.
Have a Plan for Answering Questions Promptly. During the RFP process, offerors will undoubtedly have questions. Because you've established the contact personnel, you've also established the lines of communication. You'll also have to spell out to vendors how questions will be answered. For example, you will need to create a mechanism for capturing all questions and ensuring all offerors receive the entire list of questions along with your answers.
If questions contain proprietary information, you may wish to edit the questions, but do so carefully. (Tell vendors that proprietary information must be so marked.) Your answers may be posted on your Web site, e-mailed to each offeror or otherwise electronically distributed. The key point: Keep everyone in the loop, and keep the playing field level.
Receive the RFPs.
What if a key player, one you were really counting on, decides to take a pass on this great opportunity?
Accept a Turndown Graciously. If an offeror chooses not to respond, or recognizes that it can't meet your needs within the budget, gracefully accept the response to pass on your project. Don't short yourself by eliminating that offeror from future RFPs, however.
Remember, turndowns may be due to something as simple as timing—the vendor doesn't have the staff to adequately manage the project, is busy with another large contract or can't devote the time necessary to properly respond to you. I'd much rather hear that a company is interested in a project but chooses not to reply for whatever reason, than to waste my time reading a half-baked proposal.
Accept Multiple Proposals from an Offeror. Don't be surprised if an offeror makes more than one proposal. Just as you're seeking different ideas from your offerors, allow an offeror to put forward more than one solution.
Weed out non-responsive RFPs.
It's important that the team make a first pass at the proposals in order to eliminate any that do not comply with your requirements or include incomplete answers, omit data or fail to include requested documents. Such RFPs are called “non-responsive” and can't be properly evaluated.
Reject Late RFPs. RFPs submitted after your deadline should never be accepted. Unless there's a major incident that disrupts your industry (think Sept. 11), late RFPs should be considered non-responsive.
Rate and rank the responses.
Remember the review criteria you established in Step 3? It's time to follow them. If you have discovered new requirements during the question and answer phase, it's certainly permissible to expand your ratings grid to add new factors or requirements, but it's only fair to your offerors to stick to the original criteria, point-scoring system and timetable you established in your RFP.
If an offeror has made more than one proposal, evaluate each proposal separately.
Invite top offerors to make a presentation.
This step is optional. Though it extends the overall RFP process, I've found it immensely valuable.
You may wish to use presentations to nail down the details, become comfortable with the offeror, see a demonstration or ask questions about their bid and who will be working on the project.
Based on this interaction, you can extend a final iteration of the proposal, where offerors prepare a revised—and final—offer. (Be sure you've explained this step in your original RFP document.)
Assemble the Same Team. It's tempting (especially in today's short-handed IT environments) to have one or two team members attend an offeror's presentation, then report back to the group. Don't make this mistake.
Make sure that the team that created the RFP is the same team that participates in the offeror's presentation. Such give-and-take sessions allow you to clear up any questions, rather than making assumptions about what the offeror is saying in its proposal only to have questions arise later. The interaction may also give you some insight into the offeror's competencies or help you assess your confidence in the offeror's ability to deliver the proposed solution.
Allow offerors to make their “best and final” offer, then make your selection.
In this stage, an offeror considers all the feedback, additional requirements and insights gained from presentations, and assembles its “best and final” proposal. Typically, this may be a simple tweak of the original proposal, with perhaps some adjustments to timelines and costs.
When making your selection, Step 7's rules apply: Be consistent, use the criteria you've already established and be sure your evaluation team is the same team that created the RFP.
Award the project.
Here's where the rubber meets the road. It's time to get your legal department involved and create a contract. If you don't act promptly and according to the timetable noted in the RFP, an offeror might withdraw a proposal because you appear indecisive.
Be sure to write the offerors who were not selected and thank them for their efforts.
Some Final Words of Advice
Keep a Level Playing Field.
Think of this as “Everything I Need to Know about RFPs I Learned Growing Up.” Do you like applying for a job when you know the candidate has already been chosen? RFPs require an investment by your vendors; if the questions are loaded or the deck is stacked against them, you may soon find they'll dismiss your company's future RFPs—especially when you need these vendors the most.
Play fair with your vendors and never use an RFP for the wrong reasons. An RFP should never be used to validate options already chosen. It's not a tool for making sure your current supplier is giving you the best price.
Don't use the RFP process to educate your staff on the latest technology. Do your fact finding first; explore a company's Web site, promotional material or conferences. Find colleagues in a non-competitive company who are willing to provide leads, suggestions and references.
Consider this the first step in building (or improving) a relationship. Remember, you want a problem solved today, but you may also want post-implementation support, such as tech support or quarterly training classes. Keeping good vendor relations during the RFP process is one key ingredient to successful project completion, and to smooth ongoing operations.
Keep your team under control.
When collecting the requirements and building the RFP document, you'll need to call on all your resources as a project lead.
A strong leader can keep discussions on track and prevent them from going astray. You may want to assign someone to draft a rough requirements document ahead of time. Most people find it easier to work from an existing framework, tearing it down and adding components as necessary. Start a requirements-gathering meeting with a blank slate and the discussion can quickly veer off course.
You may find your company already has boilerplate text you can use as the outline for your RFP. That's useful for two reasons: It saves time (no more re-inventing the wheel), and the legal language (the right to cancel or withdraw an RFP, for example) is already included. If your company doesn't have such a boilerplate, your company's legal representative may be able to help you create one.