Why you must rate enterprise software requirements

Too often, RFPs (or RFIs, or RFQs) are just lists of requirements with little thought of how important those requirements are. In the absence of importance ratings, all requirements must be treated equally. This is never accurate because some requirements are always more important than others. Here’s a look at why it is worth rating requirements for importance, and how to do it.

Rating requirements for importance means capturing who wants them, why they want them and how important they are. In doing this, the organization is exploring, discovering, and documenting their needs. Rating requirements should be done by the process owners and subject matter experts, and not by those who capture the requirements in the first place. While most organizations looking at a particular type of enterprise software have very similar requirements, it is the relative importance of those requirements that makes each organization unique.

Capturing this information creates the requirements matrix, where all requirements can be traced back to their owners. If any requirements need refining, the owners of those requirements are known and can be approached for further information. Since the organization is capturing requirements to select off the shelf software, there is no need to tie requirements to processes. That level of detail is only necessary when developing software.

Requirement importance is also used during software implementation. Why the requirement is wanted and how important it is guides the implementation team. If they need more information when configuring the software, they have the names of the requirement owners to contact. Having this information readily available reduces implementation time and cost over-runs.

Rating requirements for importance allows the elimination of unimportant requirements, which reduces the work of evaluating products. It also creates an audit trail. Anybody can come back later and see that the requirement was considered and deemed unimportant. They can also see why this decision was taken, and who made it.

Vendors are sometimes reluctant to respond to RFPs, and this can cause best-fit software to be overlooked. One way of enticing vendors to respond is to do two rounds of RFPs. The first round contains only showstopper requirements, which is usually about 10 percent of the total. Since there is much less work to do, more vendors tend to respond. Shortlisted vendors are then identified and sent the full RFP. Because the vendor knows they are on the short list, they are more likely to respond to that full RFP.

Occasionally vendors can be “over optimistic” in their RFP responses. Rating requirements for importance is used to audit RFPs and eliminate inappropriate responses before the software is purchased. More on that in a future post.

How to rate requirements for importance

Gather subject matter experts and process owners around the table when rating requirements for importance. Keep team sizes to less than about a dozen people, and focused on their subject areas. If teams get too large, they slow down. Break them up into sub-teams that focus on subject matter that is more specific.

One unexpected benefit we discovered from using teams is this: When people rate requirements for importance, they feel listened to and involved. Their name is attached to a number of requirements, and they have been heard. This builds process buy-in, and these people become champions for the new software when it is launched.

Ensure all people in the meeting use the same scale when rating requirements. Give them a Requirements Ratings printout with explanations of what each rating means. See the example below. Note that each requirement has a weight. The weight is used to calculate a score when rating products against the requirements.

Chris Doig

Requirement rating meetings go faster if there is one person managing the meeting, and a second person documenting user responses. We average about 30 requirements an hour, but that can vary tremendously. In general, the more detailed the requirements are, the less time ratings take because the requirement scope is smaller. Broad requirements tend to be endlessly debated.

A comprehensive list of requirements rated for importance forms the foundation of a data driven approach to evaluating software. Particularly important for governmental organizations, this can prove the software was selected without undue influence. But even more important, the act of capturing a comprehensive list of requirements and rating them for importance means the organization thoroughly understands its needs. This goes a long way towards avoiding those software disasters that so regularly bubble up into the technical press.