Skip to Main Content

blogpost

The
one-page
RFP: How to create lean, mean, and focused RFPs

By:

Gina is a consultant in BerryDunn’s state government consulting practice, with a focus on state agency projects. She brings experience with policy analysis, organizational leadership, community service oversight, and complex project coordination to her client work.

Gina Occhipinti
03.13.19

Writing a Request for Proposal (RFP) for a new software system can be complex, time-consuming, and—let’s face it—frustrating, especially if you don’t often write RFPs. The process seems dogged by endless questions, such as:

  • How specific should the problem statement and system requirements be?
  • How can the RFP solicit a response that proves the vendor is qualified?
  • Should the RFP include legal terms and conditions? If so, which ones? 
  • Is there another strategy that can help cut down on size without forfeiting a quality response?

The public RFP process can be onerous for both the issuer and the respondents, as they can reach lengths upwards of 100 pages. And, while your procurement department would probably never let you get away with developing an RFP that is only one page, we know a smaller document requires less labor and time devoted to writing and reading. What if you could create a lean, mean, and focused RFP? Here are some tips for creating such a document: 

Describe the problem as simply as possible. At its core, an RFP is a problem statement—your organization has a particular problem, and it needs the right solution. To get the right solution, keep your RFP laser-focused: adequately but briefly convey your problem and desired outcomes, provide simple rules and guidelines for respondents to submit their proposed solutions, and clarify how you will evaluate responses to make a selection. Additional information can be white noise, making it harder for respondents to give you what you want: easy-to-read and evaluate proposals. Use bullet points and keep the narrative to a minimum.

Be creative and open about how vendors must respond. RFPs often have pages of directions on how vendors need to write responses or describe their products. The most important component is to emphasize vendor qualifications. Do you want to know if the vendor can deliver a quality product? Request sample deliverables from past projects. Also ask for the number of successful past projects, with statistics on the percent deviation to client schedule, budget, including explanations for large variances. Does your new system need to keep audit trails and product billing reports? Rely on a list of pass/fail requirements and then a separate table for nice-to-have or desired functionalities.

Save the legal stuff until the end. Consider including legal terms and conditions as an attachment instead of in the body of an RFP. If you’re worried about compliance, you can require respondents to attest in writing that they found, read, and understand your terms and conditions, or state that by responding to the RFP they have read and agreed to them. State that any requested deviations can be negotiated later to save space in the RFP. You can also decrease length by attaching a glossary of terms. What’s more, if you find yourself including language from your state’s procurement manual, provide a link to the manual itself instead.

Create a quality template to save time later. Chances are your organization has at least one RFP template you use to save time, but are you using that template because it gets you the best responses, or because you’re in the habit of using it? If your answer is the latter, it may be to time review and revise those old templates to reflect your current business needs. Maybe the writing style can be clearer and more concise, or sections combined or reordered to make the RFP more intuitive.

Qualify providers in advance and reduce the scope. Another time-saver is a pre-qualification, where solution providers propose on an RFP focused primarily on their experience and qualifications. Smaller statements of work are then issued to the qualified providers, allowing for shorter drafting, response, and award timelines. If procurement rules allow, break the procurement up into a requests for information (RFI) and then a smaller RFP.

Need additional RFP assistance?
A simplified RFP can reduce long hours needed to develop and evaluate responses to RFPs, while vendors have more flexibility to propose the solutions you need. To learn more about how BerryDunn’s extensive procurement experience can help your organization develop effective RFPs.
 

Related Services

Consulting

Information Systems

Law enforcement, courts, prosecutors, and corrections personnel provide many complex, seemingly limitless services. Seemingly is the key word here, for in reality these personnel provide a set number of incredibly important services.

Therefore, it should surprise no one that justice and public safety (J&PS) IT departments should also provide a well-defined set of services. However, these departments are often viewed as parking lots for all technical problems. The disconnect between IT and other J&PS business units often stems from differences in organizational culture and structure, and differing department objectives and goals. As a result, J&PS organizations often experience misperception between business units and IT. The solution to this disconnect and misperception? Defining IT department services.

The benefits of defined IT services

  1. Increased business customer satisfaction. Once IT services align with customer needs, and expectations are established (e.g., service costs and service level agreements), customers can expect to receive the services they agreed to, and the IT department can align staff and skill levels to successfully meet those needs.
  2. Improved IT personnel morale. With clear definition of the services they provide to their customers, including clearly defined processes for customers to request those services, IT personnel will no longer be subject to “rogue” questions or requests, and customers won’t be inclined to circumvent the process. This decreases IT staff stress and enables them to focus on their roles in providing the defined services. 
  3. Better alignment of IT services to organizational needs. Through collaboration between the business and IT organizations, the business is able to clearly articulate the IT services that are, and aren’t, required. IT can help define realistic service levels and associated services costs, and can align IT staff and skills to the agreed-upon services. This results in increased IT effectiveness and reduced confusion regarding what services the business can expect from IT.
  4. More collaboration between IT and the organization. The collaboration between the IT and business units in defining services results in an enhanced relationship between these organizations, increasing trust and clarifying expectations. This collaborative model continues as the services required by the business evolve, and IT evolves to support them.
  5. Reduced costs. J&PS organizations that fail to strategically align IT and business strategy face increasing financial costs, as the organization is unable to invest IT dollars wisely. When a business doesn’t see IT as an enabler of business strategy, IT is no longer the provider of choice—and ultimately risks IT services being outsourced to a third-party vendor.

Next steps
Once a J&PS IT department defines its services to support business needs, it then can align the IT staffing model (i.e., numbers of staff, skill sets, roles and responsibilities), and continue to collaborate with the business to identify evolving services, as well as remove services that are no longer relevant. Contact us for help with this next step and other IT strategies and tactics for justice and public safety organizations.

Blog
The definition of success: J&PS IT departments must define services

When an organization wants to select and implement a new software solution, the following process typically occurs:

  1. The organization compiles a list of requirements for essential and non-essential (but helpful) functions.
  2. The organization incorporates the requirements into an RFP to solicit solutions from vendors.
  3. The organization selects finalist vendors to provide presentations and demonstrations.
  4. The organization selects one preferred vendor based on various qualifications, including how well the vendor’s solution meets the requirements listed in the RFP. A contract between the organization and vendor is executed for delivery of the solution.
  5. The preferred vendor conducts a gap analysis to see if there are gaps between the requirements and its solution—and discloses those gaps.
  6. The preferred vendor resolves the gaps, which often results in change orders, cost adjustments, and delays.

Sound painful? It can be. Step #5—the gap analysis, and its post-contract timing—is the main culprit. However, without it, an organization will be unaware of solution shortcomings, which can lead to countless problems down the road. So what’s an organization to do?

A Possible Solution
One suggestion: Don’t wait until you choose the preferred vendor for a gap analysis. Have finalist vendors conduct pre-contract gap analyses for you.

You read that right. Pay each finalist vendor to visit your organization for a week to learn about your current and desired software needs. Then pay them to develop and present a report, based on both the RFP and on-site discussions, which outlines how their solution will meet your current and desired software needs—as well as how they will meet any gaps. Among other things, a pre-contract gap analysis will help finalist vendors determine:

  • Whether programming changes are necessary to meet requirements
  • Whether functions can be provided through configuration setup, changes in database tables, or some other non-customized solution
  • What workarounds will be necessary
  • What functionalities they can't, or won't, provide

Select a preferred vendor based on both their initial proposal and solution report.
Of course, to save time and money, you could select only one finalist vendor for the pre-contract gap analysis. But having multiple finalist vendors creates a competitive environment that can benefit your organization, and can prevent your organization from having to go back to other vendors if you’re dissatisfied with the single finalist vendor’s proposal and solution report, or if contract negotiations prove unsuccessful.

Pros
You can set realistic expectations. By having finalist vendors conduct gap analyses during the selection process, they will gain a better understanding of your organization, and both your essential and nonessential software needs. In turn, your organization gets a better understanding of the functionality and limitations of the proposed solutions. This allows your organization to pinpoint costs for system essentials, including costs to address identified gaps. Your organization can also explore the benefits and costs of optional functions. Knowing the price breakdowns ahead of time will allow your organization to adjust its system requirements list.

You can reduce the need for, or pressure to accept, scope changes and change orders. Adding to, or deleting from, the scope of work after solution implementation is underway can create project delays and frustration. Nailing down gaps—and the preferred vendor’s solutions to meet those gaps—on the front end increases efficiency, helps to ensure best use of project resources, and minimizes unnecessary work or rework. It may also save you expense later on in the process.

Cons
You will incur additional up-front costs. Obviously, your organization will have to pay to bring finalist vendors on-site so they can learn the intricacies of your business and technical environment, and demonstrate their proposed solutions. Expenses will include vendors’ time, costs for transportation, lodging, and meals. These costs will need to be less than those typically incurred in the usual approach, or else any advantage to the modified gap analysis is minimized.

You might encounter resistance. Some finalist vendors might not be willing to invest the time and effort required to travel and conduct gap analyses for a system they may not be selected to implement. They will be more interested in the larger paycheck. Likewise, stakeholders in your own organization might feel that the required costs and time investments are impractical or unrealistic. Remind staff of the upfront investment and take note of which vendors are willing to do the same.

Blog
The pros and cons of pre-contract gap analyses

This site uses cookies to provide you with an improved user experience. By using this site you consent to the use of cookies. Please read our Privacy Policy for more information on the cookies we use and how you can manage them.