Abstract
The request for proposal (RFP) process provides a mechanism for organizations to acquire better products and services for their project solutions than they might otherwise be able to provide from internally developed project solutions. The RFP process also provides vendors (suppliers) with a mechanism for selling their product or services to organizations based on a platform of stable project specifications which they can work from. The reasons why an organization can acquire better products and solutions are varied but often include:
- The project requires different skills, expertise, or technical capabilities than those available internally
- A solution for the project cannot be clearly identified or specified
- Multiple suppliers already have a viable solution that will satisfy the project needs
- Multiple different approaches and solutions already exist externally that can satisfy the project needs
- Internal project resources lack the time required to develop and implement the project solution
Regardless of the underlying reason for the decision to implement an RFP process, it is assumed that the result of the RFP will produce the appropriate product or solution for the organization. However, from our experiences working with many project teams across many industries, we find that the expected “better” solutions resulting from RFP activities are not always realized on projects. Far too often we are asked to assist on a project to define requirements to replace a purchased solution that could not be used, or was implemented but never fully met the project needs. Just as there are multiple reasons why an organization may choose to utilize an RFP process, there are also multiple reasons why many RFP activities ultimately fail or vendors fail to provide the solutions that we expect (Porter-Roth, 2002, Foreword - p xv), including:
- Vendors understand their products and services but not necessarily our needs
- The project requirements provided in the RFP are not complete, clear, or achievable
- The schedule associated with the RFP activities and/or the overall project effort is unrealistic
- The budget allocated to acquire the project solution is unrealistic
- The sought-after technology associated with the desired solution is unavailable or it is prohibitive to implement it
This paper focuses on helping the project manager and project stakeholders close the gap between understanding the concepts that underlie successful RFP projects and having knowledge of the right tools and techniques to enable success on every RFP project effort.
RFP Process Facilitated Meetings
Project teams often struggle with obtaining and managing the appropriate level of stakeholder participation in project scope, requirements definition, RFP creation, and vendor response evaluation activities. This can lead to poorly defined or missing project requirements and scope deliverables. Project managers often lack the skills enabling them to run meetings and lead project stakeholders through the collaborative process of defining their requirements. Instead, the project manager, or a subset of project team members, write the requirements on behalf of the stakeholders, construct the RFP document, and attempt to work with vendors during the RFP evaluation phase of the project—all without a clear definition and alignment on the actual project requirements. This approach introduces instability into the RFP process. The RFP does not represent the full breadth of the project needs, and communication of these needs is likely to change as the project progresses. This opens the door for vendors to interpret the project needs in a manner that validates the use of their own product, when in reality their product may fall short of satisfying the project needs.
Facilitated joint application design (JAD) meetings have been shown to improve the quality of project deliverables and activities needed to define the scope and requirements for a project. JAD meetings incorporate collaborative meetings and group management and decision making techniques led by a neutral facilitator (i.e., someone without a stake in the project outcome). The facilitated meetings are structured to engage all of the appropriate stakeholders as participants who collaboratively meet, make decisions, and interactively build their project deliverables during the meeting, taking significantly less time and generating higher quality than is generally possible through non-JAD facilitated methods.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition refers to a facilitated workshop as a tool that can be used during the Collect Requirements process (Project Management Institute [PMI], 2008, pp. 105, 107). To leverage the success of any facilitated JAD meeting, the meeting must be fully planned. Planning enables the project management team and the facilitator to set expectations and agree on the purpose of each meeting, the decisions to be made, and the deliverables to be produced during the meeting. The neutral facilitator is responsible for providing the meeting process, and the meeting attendees are responsible for providing the content of the meeting. The facilitator conducts the meeting using collaborative techniques to collect information, validate this information, and help participants adjust the information to ensure it is clear, complete, and addresses the needs of the project stakeholders. The results of facilitated JAD meetings, when coupled with electronic information capture techniques (i.e., electronic flip charting) are consensus among participants, ownership and buy-in on all decisions, as well as the immediate availability of deliverables that are produced throughout the meeting.
Improving the Success of RFP Efforts
The RFP activities comprise a process focused on engaging a vendor to deliver a project solution that cannot be provided by the internal project team. The RFP allows vendors to understand the project's needs (business requirements) and provide a solution that addresses this need. The RFP is also a mechanism allowing project teams to gather multiple proposals and evaluate and rate each vendor's ability to meet the needs of the project. Successful RFPs provide a level playing field for all participants, whereby vendors have access to the same set of rules, requirements, schedules, and information needed to provide the project solution as would be provided to an internal project team. Based on the vendor's understanding of the project needs, each vendor will propose a solution that is focused on strengths of their specific products and services.
An RFP is not the same as a request for information (RFI). An RFI is a tool used by project teams when they are unsure of or are unable to clarify their needs for a project or the appropriate technologies for the project solution. RFIs are used to assist the project team with validation of their requirements—helping to determine if their requirements for the project are reasonable and/or achievable (Porter-Roth, 2002, p. 6). RFIs are also used to identify and explore possible technologies for a project solution, as well as to validate whether an anticipated approach is viable and affordable for a project. Project teams often use an RFI as an activity to identify potential vendors who can participate in a request for proposal activity.
RFP Critical Success Factors
There are four critical success factors that an organization needs to embrace to help foster the effectiveness of RFP activities. These success factors are focused on the organization adopting these key concepts for every effort (as illustrated in Exhibit 1):
- Quality information
- RFP presentation, structure, and organization
- Partnering with vendor
- Management support
Exhibit 1: RFP critical success factors.
Quality of Information
This success factor is intentionally placed at the bottom of the “critical success factor pyramid” shown in Figure 1. Whether a project solution will be developed and provided by an internal team, or acquired through a third party using an RFP, success of the project is based on the project stakeholders being able to clearly and completely define their project needs in the form of a project scope statement and business requirements (i.e., the project statement of work). Over the years, I have received multiple RFPs in my practice asking for proposals to satisfy a particular business need. These RFPs were vague, containing only a brief overview of the problem or business need and a generic description of the business processes affected by the project. The RFPs were so open-ended that almost any solution would appear to be valid and little direction was provided to help us focus a proposal on the real concerns for the project. Unless the project statement of work contains a clear description of the project boundaries and the specific list of the project needs that the solution must satisfy, the project team and the vendor are handicapped by being left to guess what the needs of the project are and what the scope of the project solution encompasses.
Creating the RFP is not the starting point for a project. The RFP is a tool to be used to solicit proposals only after the needs of the project have been defined as illustrated in the RFP life cycle (Exhibit 2). Facilitated meetings can be used to reduce the time it takes to produce, and to increase the quality of producing the Project Scope Statement deliverables and the business requirements document to provide the foundation of quality information that a vendor requires to fully understand the scope and intent of a project. These deliverables must be incorporated into the RFP document.
Exhibit 2: RFP life cycle.
RFP Presentation, Structure, and Organization
This success factor relates to the creation of a complete RFP document that includes both the information needed to create a level playing field for the vendor, so they understand the functional project needs, and all of the instructions, rules, time frames, and requested formats for participating in the RFP activity. The anatomy of a complete RFP (Porter-Roth, 2002, p 17) provides the vendor with the thorough statement of work for the project represented by seven RFP sections, as illustrated in Exhibit 3.
Exhibit 3: Anatomy of an RFP.
Administrative Information
This section of the RFP consists of project overview information, including a statement of the problem or business need to be solved for by the project, information regarding the timing and place to submit RFP proposals, instructions for preparing proposal responses, the RFP process timeline, an overview of the evaluation process, and the single point of contact for RFP communication between the vendor and the project team.
Project Requirements
This is the list of business requirement statements that state the specific needs of the project stakeholders. Business requirements are written from the perspective of describing “What's” for the project versus solution-oriented “How” statements. Each business requirement need should be written as individual requirement statements, as opposed to lengthy narrative paragraphs combining multiple needs. Writing requirements in this manner allows vendors to easily mark, on a requirement-by-requirement basis in the electronic-scored RFP document, which needs their solution fully addresses versus which needs are only partially provided for or not provided for at all.
Vendor Questionnaire
This section contains the qualifying questions about the vendor's organization, structure, and practices. The answers provided by these additional questions will help the project team determine the viability and stability of the vendor to become a partner and project team member, as well as clarify technology, support, and project management practices that may be relevant to the proposed solution.
Management Requirements
This section of the RFP communicates the additional nonfunctional requirements that the vendor is expected to meet, as well as provide valuable information regarding Project Assumptions, Project Constraints (which limit the project solution or the manner in which the project is run). Management requirements often include expectations around testing and training requirements associated with the proposed solution, documentation requirements that the vendor must provide for, and expectations for the level of participation on project activities that the vendor is expected to plan for.
Pricing Instructions
In order to ensure that the project team is able to compare one vendor's proposal with that of another, it is important for the team to specify how they expect the vendor to structure their bids. This section will include major cost categories that the vendors should use when preparing proposals, including information for one-time costs, recurring costs over the life of the product, and discounts that may be appropriate.
Contracts and Licenses
This section of the RFP is used to communicate specific contractual terms with which vendors would be expected to comply in order to partner with the organization to provide the project solution. Informing vendors of these contractual requirements early during the RFP process allows vendors to decide if it is appropriate for them to respond to the RFP. This section might also contain nondisclosure agreements, expected contract types, and payment terms.
Appendix
The last section of the RFP will provide the vendor with additional background information that would help the vendor understand the project need, including architectural diagrams, studies that have been performed, and even the project plan that the team has prepared.
Partnering With the Vendor
To enhance the likelihood of executing an RFP effort that results in project success, the organization submitting the RFP needs to look at the contract being signed as a partnering opportunity between the vendor and the organization, where both parties have a vested interested and stand to gain from the relationship. The vendor will become part of the project team, and the organization is looking to the vendor to provide a solution that is not available from internal efforts. For this reason, it is necessary to view the vendor as a valued resource and addition to the project team and respect their input and needs regarding the delivery of the solution. Creating unrealistic budgets and schedules that cannot be met will only result in project failure and is likely to dissuade otherwise viable vendors from responding to the proposal.
Management Support
This last success factor addresses the need for sponsorship and management support of the RFP effort. The project team and the vendor will look to the project management stakeholders for budget and schedule approvals and timely involvement for finalizing contracts. Additionally, support for resolving disputes that may arise during the execution of the contract is needed to keep the project moving forward.
Closing the Gap Between Proposed Solutions and Project Requirements
Determining the Importance of Project Needs
It is not likely that all requirements identified for the project hold the same level of importance to the project stakeholders. Although all requirements may be desired as part of the ideal solution, factors related to schedule, costs, environment readiness, etc. may require the project team to draw the line between absolutely critical requirements (those that are mandatory—i.e., the solution is not viable without providing these capabilities) and desirable requirements (those that are optional—i.e., the project could initially or permanently live without these requirements if necessary). As part of the requirements collection activities, during the facilitated JAD meetings, the project stakeholders participate in an activity to document the priority of each requirement statement.
Electronically Scored RFP Documents
The amount of time that a project team spends reviewing RFP responses and deciding on the best vendor to select is dependent on the quality of the responses received as well as on the consistency of the proposals submitted. Electronically scored RFP documents (Exhibit 4) reduce the scoring subjectivity associated with the degree to which a vendor indicates that their proposal satisfies a business need (Section 2 of the RFP) or with the nature of the answers provided on the Vendor Questionnaire (Section 3) of the RFP. A simple electronic scoring document can be created using Microsoft Excel that allows the use of formulas to calculate the RFP raw and weighted scores based on score values and weights included in the formulas.
The initial comparison of proposals, and the possible elimination of proposals that are out of line with the other proposals, can be completed in a matter of minutes. Raw and weighted score columns are hidden in the version of the document sent to vendors. The project team simply unlocks and expands the score columns to see how each vendor's proposal compares against the highest possible cumulative score as well as against the other proposals. Vendor “A” may have scored 3,400 points out of a total 4,000 points, while Vendor “B” may have scored 1,200 points and the scores for all remaining vendor proposals fall between 2,400 and 2,800 points. The team can then try to determine if there appears to be a mistake in how the answers cause the high and low scoring proposals to be uncharacteristically out of line with others and decide to either investigate these further or reject them.
Based on the importance of each requirement to project need, as indicated by the assigned priority of mandatory or optional, each response automatically receives a raw score. This raw score is then automatically adjusted (increased) by multiplying the score by the weight assigned to the business process for which each requirement is associated, to determine the final weighted score at both the requirement level and cumulatively for the entire RFP response. To complete the automatic scoring of the RFP responses, the project team can hold facilitated meetings to review the answers to the Vendor Questionnaire. The team members reach consensus on which a score column receives an “X” based on an answer key for Preferred Answer, Acceptable Answer, Undesirable or Knock Out Answer, which the team prepared prior to publishing the RFP. This activity provides the final set of scores for each proposal.
Exhibit 4 - Electronically scored RFP documents
Product Demos
As the project works to reach a recommendation for the sole vendor who will be awarded the contract to provide the project solution, it is common to request that each vendor conduct a demonstration of their product, assuming this is feasible for the type of product being proposed. These demonstrations will provide an opportunity for the project team to look more closely at the proposals and identify gaps between how the vendor indicated that their solution met the business requirements and what the team is able to discern regarding how closely it actually meets the needs of the project.
In order to continue to eliminate subjectivity during the evaluation process, we recommend that the project team provide the vendors with a set of test or demonstration scenarios. These scenarios can be at a high level, identifying key functions that the team is interested in looking more closely at. High-level scenarios can include the beginning and ending transaction for the scenario to guide the vendors through the demonstration. Optionally, the scenarios may also be more detailed and provide specific steps that the team wants to see performed as the transactions are executed. During these demonstrations, the team will ask questions and make note of what they consider to be gaps in the proposals compared with how well the business requirements are satisfied. These gaps will be the basis for the Vendor Proposal Gap Analysis meetings.
Vendor Proposal Gap Analysis Meetings
On some projects, vendors are allowed an opportunity to adjust and finalize their proposals after participating in product demonstrations and gaining alignment from the project stakeholders on areas where their proposals fall short of meeting the project need. However, even if the vendors are not allowed to change their proposal, holding a Vendor Proposal Gap Analysis Meeting with each vendor can provide valuable insight to the project team and vendor on any additional effort that may be needed to successfully implement the vendor's solution. These meetings should be facilitated to ensure that project stakeholders and the vendor remain focused on closing gaps and documenting the adjustments required to close the gaps. The output from these meetings will be used by the vendor to prepare final adjustments for their proposal, if allowed, and the project team to plan for the appropriate effort to implement the vendor's solution.
Each identified gap is reviewed during the meeting, and clear documentation for how the gap will be closed will be captured in a Vendor Solutions document (Exhibit 5). Actions to close gaps may vary by project and department within an organization, so these need to be agreed upon at the beginning of the meeting.
Considerations for closing the gaps might include:
- Customization: The proposed unique development for your organization's solution needed to be made by the vendor or the project team. These modifications are typically not part of the core product offering available to other customers.
- Release: New functionality that is already published for, or will be included in, upcoming product releases and will be part of the core product offering.
- Implementation: Clarification of configurable features of the project that are intended to be set during the implementation of the product (i.e., features that are turned on or off).
- Process Change: Recommended changes to the organization's business processes, practices, and requirements in order to allow the solution proposed by the vendor to function as designed and proposed.
- Existing Functionality: Clarification on how the proposed product functionality actually does meet the business requirement need, as currently designed and implemented.
Exhibit 5: Vendor solution document.
Ultimately the value provided to the vendor from holding the Vendor Proposal Gap Analysis meeting includes achieving clarification on where their proposals fall short of the business need and alignment with the project stakeholders regarding the nature of adjustments to be made (with the proposed product and/or within the organization itself). Although the clarification and alignment coming out of these meetings are not intended to be a commitment to award the contract to the vendor, they should reduce the amount of guesswork and potential padding in the adjusted estimates associated with closing the identified gaps.
The success of these meetings is dependent on clarifying with the vendor that acknowledging the weaknesses in their proposal is not intended to disqualify the vendor, but rather to clarify how the approach to the proposed solution can be adjusted to better meet the project needs. A gap analysis meeting is held separately for each vendor, and vendors need to be assured that the weaknesses discussed and adjustments proposed will not be disclosed to their competitors or other customers. We have found that vendors who come into these meetings somewhat hesitantly, always leave with a sense of accomplishment and confidence that they are aligned with the project stakeholders on the effort needed to improve the fit of their proposed solution with the project needs.
Summary – Working Collaboratively Toward Successful RFP Engagements
Vendors truly only understand their own product and services in great detail and likewise each organization, seeking a outside solution, knows what their own needs are and can decide which vendor's solution addresses their needs best. If the RFPs that we prepare are open-ended, vague, or incomplete, we leave it up to each vendor to decide what are our needs and how they can best prepare a proposal to justify their products and services based on their interpretation. Working through inconsistently prepared proposals and proposals focused on general versus specific requirements will not only add time and costs to selecting the right vendor, but also increase the risk of selecting the wrong solution or the wrong vendor to partner with.
By investing the time up front in the project to fully identifying the statement of work to communicate the project need and incorporating this detailed information into a complete and electronic RFP document, project teams will reduce the subjectivity of evaluating responses and increase the positive experience for both the vendor and the organization of selecting the right project solution and the right vendor partner.
