Edward Claughton, President
PRI Management Group
May 29, 2019
Technology projects in law enforcement agencies often fail or never seem to meet lofty expectations through a combination of poor planning and muddled project management, and most importantly a focus on features, not clear objectives. Many of these projects are disadvantaged from the beginning — due to an outdated RFP process. It’s time to look for a better approach.
$12.6M spent, with $6M over budget. 4 years late. 43 law enforcement agencies impacted. Most importantly, officer and citizen safety called into question. That was the outcome of the RegJIN (Regional Justice Information Network) project, a two-state shared records management system (RMS) initiative among Washington and Oregon police agencies.
With extensive, unfavorable news coverage, RegJIN certainly represented a black eye for the participating agencies. Within just three years of going live, the project was deemed a “disaster” as participating agencies began to pull out and the decision was made to replace the system.
When technology projects fail, it’s typically due to a combination of lack of planning, poor project management, scope creep, insufficient project and system governance, politics, and a failure to involve the right stakeholders or end users.
All of those were apparent in the RegJIN project from the start. The system had nearly 5,000 total users in over 40 agencies, generating 50,000 police reports a month. A complex project? Certainly, and one that would be likely to face bumps along the way. Yet RegJIN’s troubles ran deeper than the typical hurdles that come with such projects.
A Closer Look at the Problem
Blaming the technology is easy to do but, complicated software is sometimes a symptom, not a cause. The roots of the RegJIN RMS failure can be traced back to the purchasing document that was drafted for its acquisition — a Request for Proposals (RFP) which was itself overly complex with 221 pages and over 2,500 system specifications. The system – which ultimately did not serve the agencies’ needs – was a reflection of the RFP.
The modern governmental procurement process was born out of the need to develop fair, equitable, and transparent purchasing practices in the 1960s. This approach was created in a pre-tech era centered around purchasing commodities with a focus on ensuring compliance with complex procurement requirements and obtaining items at the lowest cost possible. RFPs were very prescriptive, strictly defining each and every element of the thing being sought.
The 1990s brought the technology era to government, and technology has only accelerated since then. Unfortunately, the procurement process of yesteryear remained and is still used today — where it has proved to be insufficient for purchasing a product that changes at lightning speed with every new version. Indeed, the incompatibility of prescriptive, cost-driven purchasing documents and rapidly evolving technology has become quite obvious.
“Buying technology requires nimbleness and flexibility,” says David Gragan, senior procurement executive of the federal Consumer Financial Protection Bureau. “Using a system that was designed to buy pens to buy a complex item like a technology system just doesn’t work, and that’s been proven over and over.”
Market forces have driven some progress. The convergence of outdated procurement procedure and today’s software pricing structures and models have led to new purchasing vehicles that allow government agencies to buy technology directly from providers. Subscription-based software-as-a-service (SaaS) means lower upfront costs, negating the need for an RFP altogether for some purchase decisions.
Nonetheless, the government sector is still largely operating under traditional purchasing practices. Some changes have occurred — “cost is not the only determining factor in the selection of a vendor” is now a common statement in today’s RFPs. But such language is not a panacea for addressing the complexities of buying technology, and RFPs can be executed in better ways.
A Better RFP
There are two approaches to procuring technology through an RFP process. One approach tells vendors what is wanted by describing very specific features and functionalities that must be provided. The other approach encompasses a document which describes the buyer’s needs and issues, and invites vendors to describe how their system can potentially resolve them. The former approach is prescriptive. The latter is solutions-based and leaves room for innovation by way of allowing the technology community to bring creativity to the table.
The prescriptive RFP, like the one used in the RegJIN project, creates the risk of two consequential outcomes. The first is scaring away vendors who might have the right solution, simply because they may not fit every specific criterium. The second is awarding a contract to a vendor simply because they checked off all the boxes required to get through the RFP process.
As Justine Brown puts it: “Perhaps the biggest challenge today is that procurement’s ties to arcane policies not only make the system difficult to navigate, it also stifles innovation and creativity. Because federal, state and local governments fear bad results, they write layers of regulations and rules around contracting, which tends to scare off some of the IT industry’s most innovative companies.”
The solutions-based RFP offers a better way. With it, room is left for ideas and features that may resolve the buyer’s challenges in more productive, streamlined ways than would have been foreseen.
Flexibility is the key to a successful outcome. Too rigid of a process, the kind which prevents discussion between the buyer and seller, is self-defeating, as is an RFP that prescribes to the vendor how the buyer thinks their system should function.
In place of specific feature requests and arcane policies, government agencies should draft RFPs using probative objective-based questions which allow vendors, in their own words, to describe how their system, expertise and business acumen would benefit them. A list of 50 such questions will likely yield far more insight than 2500 system specifications in a spreadsheet. Asking a vendor to “Describe how your system would…” can be far more informative than binary questions, that force one-dimensional answers.
Additionally, agencies will benefit from sharing key metrics that are used internally in the RFP; this allows vendors to demonstrate how they can make a measurable impact on solving/improving on the challenges that the agencies face today. Next, adding scenarios to evaluation criteria will achieve two goals for the agency. First, it will give visibility into how the solution will work in the field, and second, it provides a way to rate vendors on the ability to solve the problems with thought innovation rather than prescription.
As stated by the IJIS Institute in its research paper Strategies for Procurement Reform and Innovation: “Central to this problem is the inherent prohibition of communicating with potential bidders during the procurement process. Communication between buyers and sellers is artificially stifled at a time when information and clarification is essential to the success of a procurement and implementation of projects, particularly with technology projects. Buyers often assume the conservative view that they must not communicate with sellers except by the formal documents within the procurement process.”
The key takeaway: decide early on, in collaboration with all stakeholders, what approach you will take and what solution you truly need. The likelihood of getting the right system for your department’s needs increase exponentially when the project is viewed through the lens of partnership. Overbearing expectations and unwieldy requirements will lead to a system that operates just the same way — and that likely means a failed technology project.
 “Bringing Innovation to Procurement”, Justine Brown. Governing.com March 4, 2014 https://www.govtech.com/budget-finance/Bringing-Innovation-to-Procurement.html
 “Strategies for Procurement Innovation and Reform”, IJIS Institute, December 10, 2013