Child Care Administrator’s Improper Payments Information Technology Guide

Download Guide in Word (993 KB) or PDF (635KB) format.

C. Developing and Evaluating a Request for Proposal (continued)

2. Key Success Factors

Each State must follow its own clearly articulated RFP process. Within that existing framework, the success or failure of a RFP depends on a number of key success factors. The following section discusses many of those factors and includes guidance on establishing an effective team, developing a plan, defining requirements, and using components of a successful RFP.

a. Establishing a RFP Team

Putting together the right team is one of the initial and most important steps in the RFP process. Drawing on the appropriate individuals that represent key stakeholder groups helps establish buy-in of key stakeholders, especially front-line workers or other users of the system. Additionally, benefit service systems are notoriously complex, as are the issues related to the acquisition of any new IT architecture. To address this complexity, the ideal RFP team would include a procurement specialist, a policy representative, an end user, and an IT business analyst. Depending on the nature of the need and potential solutions, other key stakeholders need to be involved at different points in the process, including legal counsel, budget representatives, and more specialized IT staff members, such as a security officer, systems architect, and database administrator.

The following are other considerations for the RFP team:

• One or more team members should be effective leaders and posses strong program management skills.
• Team members should be multifunctional and have abilities to write, analyze, and communicate.
• Team members should have experience in RFP development and IT development.
• Team members should possess relevant program knowledge and technical knowledge from all the programs affected by the procurement.
• Adequate training in writing successful RFPs and in evaluating responses is a must for team members.
• To avoid time delays, States should develop a list of alternates to stand in for members who cannot attend meetings.
• States should develop a preferred method of communication; many States are effectively using a shared workspace that includes project documents, schedule, and online discussion capabilities.

b. Developing a Procurement Management Plan

Once the team is established and trained, the first order of business is creating a procurement management plan that describes all the phases and activities involved in the procurement process. The plan keeps the RFP team focused and prevents critical items from being overlooked and deliverable dates from being missed. Having the team develop the plan as one of its first activities engenders ownership among team members and helps identify the full breadth of necessary activities.

c. Establishing an Online RFP Document Library

Developing a library of governance documents enables team members to review, create, upload, check out, and modify documents. The library may retain some or all of the following resources:

• RFPs and responses;
• RFIs and responses;
• Project Plan Templates and copies of plans from past IT projects;
• Proposal Evaluations Criteria Templates;
• Procurement training courses;
• Blanket Purchase Agreements;
• Employee and citizen satisfaction surveys; and
• Statement of Needs.

d. Writing the RFP

Successful RFPs clearly and succinctly communicate the State’s business needs, outline performance expectations, include only necessary technical specifications, and provide a balanced set of terms and conditions that mitigate risk without driving up the bid cost.

Once the RFP team understands the needs of end users through the methods described in the previous section, Preparing for Procurement, it should decide whether the solution is self-evident or the procurement should simply present the business need and desired outcome and then allow vendors to propose solutions. In most cases, RFPs should focus on desired outcomes rather than technical requirements, incorporate both short, and long-term goals for the requested solution, and define the criteria on which a State bases its acceptance or rejection.

By prioritizing desired outcomes over technical specifications, States leave respondents open to the exploration of cutting-edge or out-of-the box strategies as well as opening up the vendor pool. According to the National Association of State Chief Information Officers (NASCIO), States should find the balance between specifications “that focus on what the desired outcome of procurement is and how the IT system must perform once implemented to satisfy the State’s expectations.” While it is permissible to attach an addendum to the RFP that includes requirements, States should be wary of providing too much information. Additionally, excessive detail can shift design responsibility to the State, which may allow a vendor to avoid liability for successful implementation of a State’s faulty design requirements.

e. Establishing Acceptable Terms and Conditions

States typically use standard terms and conditions in their contracts. To the extent possible, sharing these terms or a draft of terms up front (instead of during the negotiation) helps vendors assess their risk and liability and more accurately account for these factors in their bid. Many States have mandatory terms and conditions that assign all or the majority of risk to the vendor as a means of safeguarding public funds. These limitations of liability (or unlimited liability) clauses often do not reflect the terms and conditions in similar contracts in the commercial sector, which share the risk among parties. For this reason, vendors are likely to pass along the cost of this risk to the State via their bid or choose not to bid at all.

The Information Technology Association of America (ITAA), NASCIO, and the National Association of State Procurement Officials have all published briefs discussing specific terms and conditions included in State contracts, which may limit the number of vendors choosing to bid on projects and drive up the cost of bids among vendors that choose to bid. The bibliography at the end of this chapter includes references to these briefs.

The terms and conditions include:

• Limitation-of-liability clauses (or unlimited liability);
• Intellectual property rights (IP) clauses;
• License rights clauses;
• Warranty and indemnification clauses; and
• Most-favored-customer pricing clauses.