Based on this informal Linkedin poll, 70% of us agree with the proposition that we could live with half the features in our applications, and that performance and reliability are more important qualities.

This is not a surprising result. We all know our apps would be healthier if they lost weight. We understand that the very best apps do exactly what users need and nothing more!

If we know leaner is better, but yet our apps are morbidly obese and getting fatter every day, there must be some opposing force — a ravenous, insatiable appetite — that keeps the feature-kitchens cooking.

The root of the problem is the pretense that our industry produces COTS (commercial off-the-shelf) solutions. RFPs almost universally call for COTS solutions, but also include (often mandatory) requirements that cannot be met by any extant COTS product. Proposals reflect vendors’ offers to extend their pseudo-COTS applications to meet the new and unique requirements of nearly every incremental customer.

It is essential to understand that this is not customization. Customers do not receive unique one-of-a-kind versions of the product. Rather, the base feature set is expanded to incorporate incremental requirements. Of course, features sometimes conflict. One customer wants multiple dispositions, another wants to force a single disposition. A configuration option is added. Up to a point, this is perfectly reasonable. But when the incorporation of optional configurable features becomes the automatic response to every new requirement, the result is geometric growth in complexity. Effective testing becomes impossible. Defect rates rise.

Real COTS software usually alternates major new feature releases with bug fixes and improvements to performance, manageability, and usability. However, public safety vendors are contractually beholden to an endless backlog of new features. As a consequence, every release is a new feature release. Bug fixes, performance, manageability, and usability suffer.

Users delay upgrades and often skip release levels in response to the frequency with which new revisions introduce errors (in functions that were working just fine). This creates a perverse incentive. When existing customers resist upgrades, and new customers demand the latest and greatest, all of the development effort goes to new customers and new requirements. In the worst case (yet entirely realistic) scenario, a new feature that is of questionable value to a single new customer takes priority over a performance improvement that would benefit hundreds of existing customers and save countless hours, dollars, and errors.

Both public safety vendors and their customers are, at the same time, perpetrators and victims of these deeply ingrained practices. Neither can hope to affect change alone, and there are others whose interests may lead them to oppose constructive change. Procurement bureaucracies and consultants make a living as intermediaries between producers and consumers. Each of the parties has ample room for improvement.

Vendors should stop over-promising. But in a competitive marketplace, the one who does the right thing first will be crushed by their competitors. Industry associations, such as IJIS Institute, have study groups working to recommend industry-wide procurement reform. Some vendors are beginning to provide feedback for RFPs they no-bid, highlighting some of the worst problems. We believe an industry-wide code of conduct that raises the bar for vendor representations and disclosures would be useful.

True SaaS (software as a service) cloud solutions help by forcing all customers onto a common release cycle, resulting in features that benefit the installed base getting higher priority.

In an ideal world, smart software developers who understand the tradeoffs between complexity, quality, and performance would negotiate with users to find the minimum feature set that gets the job done. Almost everyone uses some variant of agile development methodology, the central benefit of which is that such negotiations can take place naturally as requirements are evolved in an iterative process. But in public safety procurement, in which every detail of the requirements must be pre-specified and developers are prohibited from any contact whatsoever with users. There are processes for negotiated procurement that enable more collaborative development. Unfortunately, the pretend-COTS requirement is often based in statute.

If the process can’t be fixed, then buyers have to be smarter about requirements. Here are a few examples from a real RFP (slightly altered to protect the guilty):

1. Entering the unit ID only on the command line and pressing the Enter key shall function in the following manner:

• If the unit is not on duty, the user will be prompted with the log on screen.
• If the unit is on duty but not assigned to an incident, the user will have the unit status displayed
• If the unit is on an incident the incident will be highlighted on the incident grid on the CAD screen.
• When the incident is highlighted, pressing the enter key will open the highlighted incident

2. The proposed solution shall have data fields to store an agency-assigned permanent identification number (PID) and three (3) radio ID (RID) numbers. The RID number fields shall consist of the previous RID number, Current RID number and Future RID number. This information will be used to perform the annual RID change function. The current RID number will be the number used to perform all unit transactions by CAD and MDC users.The PID is a personal identifier that is unique for each user in the CAD database and is permanently assigned to the individual. This number is used for all database identification and tracking of unit activity. It may also be referred to as CNN or IVM. It is agency-defined and is a 8- character alpha-numeric field.

These are detailed specifications, not requirements. The first item suggests requirements that are obvious for a CAD system. Specifying the exact key sequence through which these functions must be accomplished is simply ridiculous. It precludes solutions that might be more usable and more intuitive. Requirements should state the essential processes that users need to carry out and, in general terms, the manner in which the system may support them, such as delivering essential data.

The second requirement appears to say that the new system must work exactly the same as the existing system, but provides no information as to the purpose of the actions. Requirements should explain the challenges users face and solicit solutions, allowing maximum latitude for innovative approaches.

Both the quality and the quantity of requirements should be closely scrutinized. When RFP boilerplate is cut and pasted from one RFP to the next, eventually every RFP includes every requirement that anybody every contemplated. The result: everybody builds the same designed-by-a-committee product. No requirement should ever be included in an RFP unless it represents a real verifiable user need! Boilerplate requirements increase costs and reduce quality.