Why You Should Ditch the Requirements Checklist

You’ve made the choice to acquire new technology for your agency. Maybe your first vendor didn’t deliver the right solution  – or changing conditions in your agency, realm of responsibility, mission and/or area of operation necessitate a solution you didn’t have before. Whatever the reason, evaluating new technology will require a long process involving drafting requirements, putting out an RFP and evaluating vendors. To make sure you get it right the first time, I strongly suggest considering your agency’s objectives first, and requirements only after you know what you want to achieve.

One of the biggest problems in government procurement is solving for requirements vs. objectives. Focusing too much on requirements and not enough on objectives often results in a solution that does a lot but doesn’t always exactly fit the procuring agency’s needs. A requirement typically describes a hard-line function or feature in an application to a high degree of specificity. For example:

• A user shall be able to change the text color of all labels in the application
• The application shall use Fortran as its server-side language

At first blush, some of these seem reasonable. Changing text colors adds flexibility and hey, Fortran still has its place in the world. And it’s important to note that focusing on requirements vs. objectives isn’t the fault of the agency. Requirements are highly objective, will achieve a very specific outcome and they don’t afford the vendor much room for error. But, there are drawbacks.

Let’s look at each of these functionalities more deeply, understand why they could be problematic and guess at what the user really is asking for (hint: let’s determine the objective of the user, rather than letting the user prescribe the requirement).

Example 1: A user shall be able to change the text color of all labels in the application

A user wants to make error messaging bright and general text easy on the eyes. Maybe the user changes error text from a default dark pink to a harsh red and picks calming, light blue for all other application text.

In each case, while the changes seem obvious, the overall usability of the application may degrade. Bright red text may instinctively imply an error, but in an application that relies heavily on persistent error messaging, pink may be easier to read for a long time – hence the original decision to use a more delicate hue.

Maybe light blue is known to be calming, but it’s hard to read on a white background – and what if the application doesn’t allow for background color changes? In the first case, it sounds like the user wants to make sure “the application shall use different stylistic techniques (color, font, size, etc.) to increase the readability of different text segments of the application.” In the second case, perhaps the user is asking that “the application shall be considered readable for longs periods of time by a group of users representative of the agency’s population.”

In both cases, we’ve taken the hard, limiting requirement and up-leveled it to its assumed objective. Of course we would have to confirm with the user, but now the vendor can use their expertise to come up with an elegant, well-designed solution –that’s what you’re paying them for – rather than introducing functionality that could negatively impact the department in the hands of an untrained user.

Example 2: The application shall use Fortran as it’s server-side language

Maybe an agency’s data warehouse plugs into Fortran nicely. Or maybe they care about application speed, which is an important consideration – in a narrow set of situations, Fortran is very fast. Nowadays, however, Fortran squarely has a place in scientific computing and not much else. A responding vendor would then be limited to an extremely small set of libraries, resources and talent that could maybe help them build some Fortran-based application, all so the procuring agency can have an application that plugs into a data warehouse and is maybe fast. Instead, the agency should describe its objectives:

• The application shall offer some well-defined, standard method of receiving and transmitting data to other applications
• The application shall be performant such that all functions have an average execution time of less than 200 milliseconds

With goal-oriented objectives – vs. hard-line requirements – the agency can expect the vendor to provide an interoperable application – perhaps REST-based – that is as fast as the agency needs. At the same time, the vendor can use widely-supported, modern technology that will ultimately drive down costs for the agency while helping keep the agency modern.

It’s a win all around – the agency, upon launch, will have an application that does exactly what it wants, and the vendor is able to use its expertise to provide an application that is robust and of lower cost to the agency.

Better technology solutions begin with better procurement strategies. Releasing an RFP is no small feat, and we’ve only just touched on the comprehensive ocean of how to improve your agency’s RFP process. However, by following the guidance above, you can be sure your procurement process will be more forward-looking, low-risk and satisfactory for your agency.

Matthew Polega is part of the GovLoop Featured Blogger program, where we feature blog posts by government voices from all across the country (and world!). To see more Featured Blogger posts, click here.