Welcome to the Pondera FraudCast, a weekly blog where we post information on fraud trends, lessons learned from client engagements, and observations from our investigators in the field. We hope you’ll check back often to stay current with our efforts to combat fraud, waste, and abuse in large government programs.
As a company that works with government clients, we spend a tremendous amount of time and money responding to Requests for Proposals (RFPs). We understand that governments use RFPs to ensure competitive bidding processes and to articulate their requirements. However, the process still causes enough angst for prospective bidders that, ironically, it often actually limits competition.
We wrote in a previous blog post about the lengthy RFP procurement cycles and their impacts on the final project. Today I’d like to discuss the formats of the RFPs themselves which often cause confusion, leading to large numbers of vendor questions, which in turn leads to delayed timelines and incorrectly submitted bids. I confess that I have never been on the “other side of the table” writing an RFP and I can only imagine how difficult it must be. But I still have one simple suggestion that I wish government agencies would take prior to releasing an RFP.
Before releasing an RFP to the vendor community, I suggest that government run an internal “mock” procurement: “release” the bid to a few agency employees and ask them to respond to it. They don’t have to provide actual answers, just an outline so they can make sure they understand what the RFP requires, where responses should go, how the format works, and other structural issues. It’s important that these people had nothing to do with the writing of the RFP document itself because then they’d naturally understand what they intended when they wrote it.
Commonly confusing issues we see in RFPs include where to place a Statement of Work (in tables or in text), repeated questions, seemingly mutually exclusive statements or requirements, and “thrown in” requirements that belong in other sections and break up the flow of the response.
I think government officials would be amazed at how much confusion and time they could take out of their procurements by performing this simple quality assurance exercise. This would also reduce the number of questions the state would have to respond to and provide more focus on issues of substance rather than administrative or formatting issues. Finally, it would lead to more uniformity of responses allowing governments to evaluate responses for their merit rather than having to search for answers to their requirements.
This week, my company is responding to an RFP for SaaS fraud detection services. While we are thankful for the opportunity to respond, the RFP and its process also illustrates the need for governments to adjust their procurement processes with the advent of cloud computing. After all, we responded to the RFI for this procurement over two years ago!
This means that the current solicitation is at least partly based on product capabilities from early 2014. While this might not be a big problem for traditional IT projects, this is a lifetime in SaaS. In fact, if a SaaS solution offered mostly similar functionality over a two-year period, I’d recommend not selecting that solution. Effective SaaS solutions push new features in days and weeks, not months or years.
With this background in mind, I’d like to propose that governments consider the following three modifications to their procurement policies. Some of these changes may require assistance from legislative bodies and funding organizations in addition to procurement professionals.
1. Reduce the time between RFI and RFP: This will help governments avoid building their requirements on functionality that has long since been replaced. SaaS functionality is a moving target – it’s supposed to be.
2. Smooth out funding over multiple years: Traditional IT projects required large upfront implementation costs followed by lower ongoing support, maintenance, and operations costs (assuming the initial implementation was successful). SaaS solutions spread the cost more evenly over time as the solution continues to improve.
3. Make sure your staff is ready when you award: True SaaS solutions can be implemented quickly, often in as few as 120 days. By the time you award a project, you should be ready to discuss security plans, access the required program data, assign staff (not just project staff but system users), and address many other details that could often be delayed in lengthy IT projects.