Why you must rate enterprise software requirements
While rating 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 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.
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.
Chris Doig graduated from the University of Cape Town, South Africa with a bachelor of electrical engineering degree. While at university, he founded Cirrus Technology to supply information technology products to the corporate market. The focus at Cirrus was helping companies buy the best IT products for their particular needs. Cirrus also developed custom software for the South African 7-Eleven franchise holder and other corporate clients.
In the 1990s, Chris immigrated to the United States and worked at several companies in technical and IT management roles: Seagate, Biogen, Netflix, Boeing, Bechtel SAIC, Discovery Communications and several startups. At all of these companies he repeatedly saw software being purchased with an immature selection process. Invariably this software would take longer to implement than planned and cost more than budgeted. To make matters worse, the software seldom met expectations.
Having struggled with software selection himself, Chris founded Wayferry, a consulting company that helps organizations acquire enterprise software. He is also the author of Rethinking Enterprise Software Selection: Stop buying square pegs for round holes. While ERP projects account for much of Wayferry's work, other types of enterprise software acquisitions include CRM, HRIS, help desk, call center software, clinical trials management systems and so on. For Chris, the ultimate satisfaction is when clients report meeting or even exceeding expectations with their new software.
The opinions expressed in this blog are those of Chris Doig and do not necessarily represent those of IDG Communications Inc. or its parent, subsidiary or affiliated companies.