The Main Sections of an Rfp Can Include the Statement of Work and Schedule Information.

Abstract

The request for proposal (RFP) procedure provides a mechanism for organizations to learn better products and services for their project solutions than they might otherwise be able to provide from internally developed projection solutions. The RFP procedure also provides vendors (suppliers) with a mechanism for selling their production or services to organizations based on a platform of stable project specifications which they can work from. The reasons why an organization can larn better products and solutions are varied but often include:

• The projection requires unlike 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 feasible solution that will satisfy the project needs
• Multiple dissimilar approaches and solutions already exist externally that can satisfy the project needs
• Internal project resources lack the fourth dimension 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 production or solution for the organization. All the same, from our experiences working with many projection teams across many industries, nosotros find that the expected "better" solutions resulting from RFP activities are not always realized on projects. Far too oftentimes we are asked to help on a project to define requirements to supervene upon a purchased solution that could not be used, or was implemented only never fully met the project needs. But every bit there are multiple reasons why an organization may choose to utilize an RFP process, in that location 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 non necessarily our needs
• The project requirements provided in the RFP are non complete, clear, or achievable
• The schedule associated with the RFP activities and/or the overall project effort is unrealistic
• The budget allocated to larn 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 projection managing director and projection stakeholders close the gap between understanding the concepts that underlie successful RFP projects and having cognition of the right tools and techniques to enable success on every RFP project endeavour.

RFP Process Facilitated Meetings

Projection teams oftentimes struggle with obtaining and managing the appropriate level of stakeholder participation in project telescopic, requirements definition, RFP creation, and vendor response evaluation activities. This can lead to poorly defined or missing project requirements and scope deliverables. Project managers oftentimes lack the skills enabling them to run meetings and pb projection stakeholders through the collaborative process of defining their requirements. Instead, the project director, or a subset of projection team members, write the requirements on behalf of the stakeholders, construct the RFP document, and try to work with vendors during the RFP evaluation phase of the project—all without a clear definition and alignment on the bodily projection requirements. This approach introduces instability into the RFP procedure. The RFP does non stand for the full latitude of the project needs, and advice of these needs is probable to change equally the project progresses. This opens the door for vendors to interpret the project needs in a manner that validates the employ of their own production, when in reality their product may autumn curt of satisfying the project needs.

Facilitated articulation application pattern (JAD) meetings have been shown to improve the quality of project deliverables and activities needed to define the telescopic and requirements for a project. JAD meetings incorporate collaborative meetings and group direction and determination making techniques led by a neutral facilitator (i.due east., someone without a pale in the project effect). The facilitated meetings are structured to engage all of the appropriate stakeholders equally 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 exist used during the Collect Requirements process (Project Management Institute [PMI], 2008, pp. 105, 107). To leverage the success of whatsoever facilitated JAD coming together, the coming together must be fully planned. Planning enables the project direction squad and the facilitator to set expectations and concord on the purpose of each meeting, the decisions to exist made, and the deliverables to be produced during the coming together. 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 data, validate this information, and help participants adjust the information to ensure it is clear, complete, and addresses the needs of the projection 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, besides as the firsthand availability of deliverables that are produced throughout the meeting.

Improving the Success of RFP Efforts

The RFP activities comprise a procedure focused on engaging a vendor to deliver a project solution that cannot be provided by the internal projection squad. The RFP allows vendors to understand the project's needs (business requirements) and provide a solution that addresses this demand. The RFP is also a machinery 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 take access to the same fix of rules, requirements, schedules, and information needed to provide the projection solution as would be provided to an internal projection team. Based on the vendor'south agreement of the projection needs, each vendor volition 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 squad with validation of their requirements—helping to decide if their requirements for the project are reasonable and/or achievable (Porter-Roth, 2002, p. six). RFIs are also used to identify and explore possible technologies for a projection solution, likewise equally to validate whether an anticipated approach is viable and affordable for a project. Project teams ofttimes use an RFI equally an activity to place potential vendors who can participate in a asking for proposal activity.

RFP Critical Success Factors

In that location are 4 critical success factors that an organization needs to comprehend to aid foster the effectiveness of RFP activities. These success factors are focused on the organization adopting these fundamental concepts for every effort (every bit illustrated in Showroom 1):

• Quality information
• RFP presentation, construction, and system
• Partnering with vendor
• Management back up

Exhibit 1: RFP critical success factors.

Quality of Information

This success cistron is intentionally placed at the lesser of the "disquisitional success factor pyramid" shown in Figure 1. Whether a project solution volition exist adult and provided by an internal team, or acquired through a third party using an RFP, success of the project is based on the projection stakeholders being able to conspicuously and completely define their project needs in the form of a projection scope statement and business concern requirements (i.e., the project statement of work). Over the years, I have received multiple RFPs in my do asking for proposals to satisfy a particular business demand. These RFPs were vague, containing merely a brief overview of the problem or business need and a generic clarification of the business processes affected by the project. The RFPs were so open up-ended that almost any solution would appear to be valid and petty direction was provided to assistance us focus a proposal on the existent concerns for the projection. 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 non the starting point for a project. The RFP is a tool to be used to solicit proposals only after the needs of the project accept been defined as illustrated in the RFP life cycle (Exhibit two). Facilitated meetings tin 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 organisation requirements certificate to provide the foundation of quality information that a vendor requires to fully empathize the telescopic and intent of a project. These deliverables must be incorporated into the RFP document.

Exhibit 2: RFP life cycle.

RFP Presentation, Structure, and Arrangement

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, and so they understand the functional project needs, and all of the instructions, rules, time frames, and requested formats for participating in the RFP action. The anatomy of a complete RFP (Porter-Roth, 2002, p 17) provides the vendor with the thorough argument of work for the projection represented by seven RFP sections, every bit illustrated in Exhibit 3.

Exhibit iii: Beefcake of an RFP.

Administrative Information

This section of the RFP consists of projection overview information, including a argument of the problem or concern demand to be solved for by the projection, 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 betwixt 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'south" for the project versus solution-oriented "How" statements. Each business requirement need should be written as individual requirement statements, every bit 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 merely partially provided for or not provided for at all.

Vendor Questionnaire

This section contains the qualifying questions almost the vendor's organization, structure, and practices. The answers provided past these additional questions will help the project team determine the viability and stability of the vendor to become a partner and project team fellow member, as well as clarify engineering science, support, and project management practices that may exist relevant to the proposed solution.

Management Requirements

This section of the RFP communicates the additional nonfunctional requirements that the vendor is expected to meet, likewise as provide valuable information regarding Project Assumptions, Projection Constraints (which limit the projection solution or the style in which the project is run). Management requirements often include expectations around testing and grooming 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'south proposal with that of another, it is important for the team to specify how they expect the vendor to structure their bids. This section volition include major cost categories that the vendors should employ when preparing proposals, including information for one-fourth dimension 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 social club to partner with the system to provide the project solution. Informing vendors of these contractual requirements early on during the RFP process allows vendors to decide if information technology is appropriate for them to respond to the RFP. This section might also comprise nondisclosure agreements, expected contract types, and payment terms.

Appendix

The last section of the RFP will provide the vendor with additional groundwork information that would help the vendor sympathise the project need, including architectural diagrams, studies that accept been performed, and even the projection plan that the squad has prepared.

Partnering With the Vendor

To enhance the likelihood of executing an RFP effort that results in project success, the system submitting the RFP needs to look at the contract beingness signed as a partnering opportunity between the vendor and the organization, where both parties have a vested interested and stand to proceeds from the human relationship. The vendor volition go role of the project squad, 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 projection squad and respect their input and needs regarding the delivery of the solution. Creating unrealistic budgets and schedules that cannot be met will but result in project failure and is likely to dissuade otherwise viable vendors from responding to the proposal.

Management Support

This last success gene addresses the need for sponsorship and management support of the RFP try. The project squad and the vendor will look to the project direction 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

Information technology is non likely that all requirements identified for the projection hold the same level of importance to the project stakeholders. Although all requirements may exist desired as part of the platonic 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.east., the solution is not feasible without providing these capabilities) and desirable requirements (those that are optional—i.e., the projection could initially or permanently alive 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 projection squad spends reviewing RFP responses and deciding on the best vendor to select is dependent on the quality of the responses received every bit well as on the consistency of the proposals submitted. Electronically scored RFP documents (Showroom 4) reduce the scoring subjectivity associated with the caste to which a vendor indicates that their proposal satisfies a business organization need (Section ii 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 utilize 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 exist completed in a thing of minutes. Raw and weighted score columns are hidden in the version of the document sent to vendors. The projection team only unlocks and expands the score columns to encounter how each vendor'south proposal compares against the highest possible cumulative score as well as against the other proposals. Vendor "A" may accept scored 3,400 points out of a total 4,000 points, while Vendor "B" may have scored i,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 depression scoring proposals to be uncharacteristically out of line with others and determine 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 and so automatically adapted (increased) by multiplying the score by the weight assigned to the business concern procedure 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 consummate the automated 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 cardinal 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.

Showroom iv - Electronically scored RFP documents

Product Demos

As the project works to attain a recommendation for the sole vendor who will exist 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 blazon of product being proposed. These demonstrations will provide an opportunity for the project team to wait 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 really meets the needs of the project.

In lodge to continue to eliminate subjectivity during the evaluation process, nosotros recommend that the project team provide the vendors with a fix of test or demonstration scenarios. These scenarios can exist at a high level, identifying key functions that the team is interested in looking more than closely at. High-level scenarios can include the outset and ending transaction for the scenario to guide the vendors through the demonstration. Optionally, the scenarios may also be more than detailed and provide specific steps that the team wants to run across performed as the transactions are executed. During these demonstrations, the squad will ask questions and make note of what they consider to exist 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 Assay 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 projection stakeholders on areas where their proposals autumn brusque of coming together the project need. Even so, even if the vendors are not immune to change their proposal, belongings a Vendor Proposal Gap Analysis Meeting with each vendor can provide valuable insight to the project team and vendor on any additional endeavor 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 exist used by the vendor to prepare final adjustments for their proposal, if allowed, and the projection 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 volition be closed will be captured in a Vendor Solutions document (Exhibit v). Actions to close gaps may vary past projection and department within an arrangement, then these need to be agreed upon at the starting time of the coming together.

Considerations for closing the gaps might include:

• Customization: The proposed unique evolution for your organization's solution needed to exist made by the vendor or the project squad. These modifications are typically non 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 cadre product offering.
• Implementation: Clarification of configurable features of the project that are intended to be set during the implementation of the production (i.e., features that are turned on or off).
• Process Change: Recommended changes to the organization's business processes, practices, and requirements in social club to permit 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 demand, as currently designed and implemented.

Exhibit five: Vendor solution document.

Ultimately the value provided to the vendor from holding the Vendor Proposal Gap Assay meeting includes achieving clarification on where their proposals autumn brusk of the business need and alignment with the project stakeholders regarding the nature of adjustments to exist made (with the proposed product and/or inside the organization itself). Although the clarification and alignment coming out of these meetings are non intended to be a commitment to accolade 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 non intended to disqualify the vendor, only rather to clarify how the approach to the proposed solution can exist adjusted to better meet the project needs. A gap analysis coming together is held separately for each vendor, and vendors need to exist assured that the weaknesses discussed and adjustments proposed will not exist disclosed to their competitors or other customers. Nosotros have found that vendors who come up into these meetings somewhat hesitantly, e'er 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 projection needs.

Summary – Working Collaboratively Toward Successful RFP Engagements

Vendors truly simply understand their own production and services in bully item 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-concluded, vague, or incomplete, we leave it upwards to each vendor to make up one's mind what are our needs and how they tin can best fix 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 correct vendor, simply likewise increase the risk of selecting the wrong solution or the incorrect vendor to partner with.

By investing the fourth dimension upwards front end in the project to fully identifying the statement of work to communicate the projection demand and incorporating this detailed information into a consummate and electronic RFP document, project teams will reduce the subjectivity of evaluating responses and increase the positive feel for both the vendor and the arrangement of selecting the right project solution and the right vendor partner.

References

Porter-Roth, B. (2002). Asking for proposal: A guide to effective RFP development. Newtown Foursquare, PA: Pearson Pedagogy, Inc..

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK^® guide)— Quaternary Edition. Newtown Foursquare, PA: Author.

This textile has been reproduced with the permission of the copyright possessor. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or whatever listed author.

© 2009 Paul Burek, PMP
Originally published every bit role of 2009 PMI Global Congress Proceedings – Orlando, Florida, The states

playfairdres1965.blogspot.com

Source: https://www.pmi.org/learning/library/project-requirements-rfps-vendor-proposals-6673

Share this post