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.
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.