- Introduction
- Different Types of RFPs
- Why Write an RFP?
- RFP Development and Preparation
- Anatomy of an RFP
- RFP Activities
- The Importance of the RFP from a Contract Perspective
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
RFP Development and Preparation
RFP Project Development
The request to buy technology or services can come from almost any department within a company. It may initially come from workers who are unable to keep pace with their work and know that there is technology available to help them. Alternatively, the request may come from the information technology (IT) group, which may want to build a corporate Intranet to share information more easily with employees.
NOTE
Users buy tactical; IT buys strategic.
Most often, the "users" in a company are the force behind RFPs that involves buying products to increase or enhance the efficiency of a department or a business process. IT buyers are the drivers for companywide products that add to or enhance existing IT services or provide corporate infrastructure such as a corporate Intranet or Internet site. It is important to have both the users and the IT group participate in an RFP effort when it is appropriate.
The project team should include an equal balance of skills among the following three departments:
Operations, or system users. Users, whether claims adjusters, customer service, or a supporting service such as human resources, perform the work of the business. Users know what they do now, as well as what they want to do but cannot currently do, and they can develop the operational and functional requirements for the system. Users are typically not strong on the underlying technology of systems, such as how a network connects to servers, how to set up and run an acceptance test, or how to pass data through a firewall. They depend on the IT group for those aspects of the technology requirements.
Information technology. IT staff are typically knowledgeable about whether a product will technically fit into existing technical infrastructures and what those requirements will be, what is needed to support the product, and what is needed to support the users when the product is installed. IT staff typically do not know how a department works on a business level or how to specify those business requirements.
Procurement (purchasing office). Procurement personnel understand what type of contract should be provided with the proposal (hardware versus software versus services) and can help in identifying suppliers, requesting D&Bs to ascertain financial stability, and reviewing and negotiating supplier contracts. It is vital to involve procurement personnel early in the RFP process so that they become familiar with the project and can lend their contract expertise to the effort. Procurement personnel typically are familiar neither with underlying technologies nor with project organization requirements and will depend on the RFP team for those decisions.
The planning phase of the RFP should include the following key areas:
RFP project personnel and organization.
Project schedule.
Technology and supplier education.
Budget estimation and development.
Return on investment (ROI) analysis (if required).
RFP development.
Proposal evaluation.
Contracts and awards.
Post-RFP activities.
Project personnel and organization for the new product.
Planning should be a team activity and all parties should be part of each planning session. Depending on the company culture, one person should become the project leader and manager. If the project is to purchase a new business application, the project leader may come from the user community, which is the primary driver for the project. Depending on the company culture and history, the project leader may be from the user community or the IT community. In many companies, IT takes the lead on major acquisition projects because IT staff have the knowledge of technology, project management skills, and experience dealing with suppliers. Other companies may not have a strong IT department, in which case the user community becomes the lead, tapping the IT resources when needed.
More detailed information on RFP planning activities and developing project budgets can be found in Chapter 2, "RFP Planning and Preparation," and in Appendix D, "Budget Planning and Investment Analysis."
Evaluation Criteria
NOTE
Evaluation criteria provide the method for measuring proposals.
As the project requirements are confirmed and agreed upon, the method for evaluating requirements must also be established. Requirements can range from hard technical requirements to more subjective ones such as a supplier's references. Chapter 7, "Evaluation Guidelines" contains more detailed information and examples for the evaluation process.
The following are examples of suitable areas for evaluation:
Technical requirements.
Management requirements.
Price.
References.
Qualifications/similar projects.
Site visits/oral presentations.
Product tests or demonstrations.
Overall response to the RFP.
Ability to work with the supplier's team.
Some requirements will be more difficult to measure than others and will therefore be judged subjectively. Ideally, all requirements should be measured by the same agreed-upon criteria, with subjective requirements being discussed during the evaluation team meetings. Keep in mind that all requirements should have measurable criteria.
|
An RFP is, in some sense, a collection of requirements. It must be made clear to the suppliers what are requirements and what is simply information. Requirements may be divided between mandatory and optional requirements. Mandatory requirements are those requirements that are essential to meeting the project's needs, and suppliers that take exception to mandatory requirements may be disqualified. Optional requirements are often termed "nice to have but not essential." |
Reviewing the RFP
NOTE
Allow time for an independent review of the RFP.
Before an RFP is sent out, it should be reviewed by people outside the primary RFP team. This review group may look at different aspects of the RFP, for example:
Are there any basic system architectural concerns?
Is the current working environment description accurate?
Are the functional requirements stated clearly and accurately?
Does the pricing section meet company standards?
Is the project plan achievable?
This "objective" review will help team members to see their RFP's strengths and weaknesses. Once the review is complete and the review issues responded to, the RFP should be a stronger document.