Why you must weight enterprise software requirements

While weighting requirements for importance is critical to selecting best-fit enterprise software, other benefits that flow from the exercise are reduced implementation costs and improved end user buy-in.

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 weight requirements for importance

Gather subject matter experts and process owners around the table when weighting 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 weight 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 weighting requirements. Give them a Requirements Weights printout with explanations of what each weight 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.


Example of a Requirements Weights Table
Weight Weight Name Description
6 Show stopper If features satisfying this requirement are inadequate, the product is almost certainly excluded. Few requirements are true show stoppers, usually most of these are critical.
5 Critical Functional integrity would be compromised if this requirement is not adequately met. Major effort would be needed to work around the limitation.
4 Very important There would be significant limitations if this requirement is not adequately met. Substantial effort would be needed to work around the limitation.
3 Important If this requirement is not adequately met, some effort would be needed to work around the limitation.
2 Useful Somewhat important. Useful if the requirement is satisfied, but if not there would only be a minor inconvenience in working around it.
1 Nice to have This is not an important feature. Nice to have if it is included, but nothing to worry about if it is missing.
0 No interest No need for this feature, don't care if it is included or not. This importance weight verifies the requirement has been considered for a particular person or group, and they have no need of it.


Requirement weighting 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 weights 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 weighting 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.

This article was origionally published on CIO.com on April 10, 2015 and updated on February 12, 2017.