16 places to use requirements when selecting enterprise software
Not understanding how important business requirements are and where they are used is a major cause of problems with implementing enterprise software.
Industry is littered with enterprise software purchases that failed to meet expectations and objectives. While you might read about outright failures that end up in court, most partial failures are never exposed because those involved don’t like talking about them, and that is why so few organizations appreciate the risks they are taking with these projects.
When an organization decides to purchase enterprise software, their needs are documented as business requirements, and inadequate requirements are the primary cause of new software failing to meet expectations and objectives. This article describes 16 different places where requirements are used in the software acquisition process and will help you understand why it is worth spending significant time and effort developing them.
Where requirements are used for software selection
1. Deciding what is important
How important a requirement is to an organization is expressed in the requirement’s weight which can range from “Showstopper” all the way down to “No interest.” The numerical values associated with the weights are used to calculate a “fit score,” which measures how well the software meets those requirements. The weight is also used by implementation consultants to focus their efforts on the most important requirements.
2. Developing user buy-in
When weighting a requirement, the organization captures who wants it, why they want it, and how important it is to them. When employees see their names written on the requirements, they feel the organization is listening to them, which builds user buy-in, so essential to the success of a major software purchase.
We were helping a client to select ERP software. One group of users reviewing requirements included Buddy, the person who managed the production inventory team. Buddy was a blue collar worker whose “office” was the production store. When Buddy saw his name written on the requirements and why he wanted them, his eyes lit up because he realized the company was taking his needs into account. From that meeting forward Buddy was a strong advocate for the new ERP system.
3. Controlling scope creep
Assuming you have developed a comprehensive list of requirements using techniques like reverse engineering, keeping users focused on that list rather than asking them to think up new requirements keeps the requirements scope under control. You avoid the distraction of dealing with questions like “Wouldn’t it be nice if the new software did…”
4. Improved vendor responses
When a vendor returns an RFI or RFP, they are responding to your requirements. When requirements are incomplete, ambiguous, or badly worded, vendors will interpret them in a way that is favorable to them rather than you. Also, no vendor can be held accountable for not meeting unstated requirements. Inaccurate RFI or RFP responses caused by poor or incomplete requirements can also result in the wrong software being selected and consequent failure of that software to meet expectations.
5. Gap analysis fit measurement
The gap analysis uses requirement weights and product appraisal scores to measure how well potential software products meet your requirements. The result of the gap analysis is expressed as a number called the fit score which is used to rank products. Fit scores are usually normalized so that, for example, 100% means that all requirements are fully met.
6. Project scope management
When selecting software, we like to see one or more products with a fit score of at least 90%. However, on some evaluations no product will score more than around 75%. When this happens, you are asking for more features than the market can supply. The scope of the project must be reduced if you want your expectations to be met.
We were helping a client in the life science industry. They wanted their new software to include document management that supported a particular FDA standard. While all vendors had basic document management, none of them supported this FDA standard. They suggested using a separate FDA compliant document management system and interfacing their software to that system.
When we reduced the scope of the client’s project by removing document management requirements, all product scores rose substantially. The client’s expectations were now more closely aligned with features that software on the market could deliver.
7. Software demo script
The gap analysis makes the software selection, and the demo confirms that decision. Typically the top three scoring products are selected for demos. Showstopper requirements are used to create the demo script.
8. RFP verification
Occasionally vendors are “over-optimistic” when responding to an RFI or RFP, and the function of an audit is to identify these inaccurate responses. A sample of showstopper requirements that the vendor claims are fully met is selected, and the vendor is asked for evidence that their software meets these requirements as claimed. If a vendor misrepresented their product, the audit would discover this, and you will avoid buying software that will not meet your needs.
In a recent ERP selection, a vendor claimed to meet 99.8% of close to 2000 requirements. So we asked the vendor what compensation they would provide if they claimed to meet a requirement, but during implementation it was discovered this requirement was not met. They answered that they did not warranty their response to the RFI. In other words, “Don’t believe what we claimed!” The entire audit was summed up in this one question which helped avoid the problem of buying software only to find out during implementation that it would not meet expectations.
9. Setting expectations
All major software purchases involve some degree of compromise and aligning expectations with what the selected software will deliver is an important part of a successful project. The gap analysis used to purchase a particular software product defines and documents those expectations down to how that software meets individual requirements. Knowing the compromises before the purchase keeps expectations aligned with reality and prevents buyer’s remorse.
A client of ours had made a major software purchase where the fit score was only 79%. (We prefer fit scores of around 90%) That low score meant that significant compromises were being made, but it was the software that best met their particular needs. During the implementation, Jeff, the IT director handling the project, said that whenever he was wondering why they had selected that particular software, he went back to the evaluation and saw that all the other contenders were even greater compromises.
10. Software purchase negotiations
The evaluation process measures how well potential products meet requirements, and products are ranked by fit score. Usually, the highest scoring product is the one selected, but sometimes several products have very close fit scores. When vendors know you have realistic alternatives to their product, they are more accommodating when negotiating.
11. Libraries of requirements
Requirements like usability, security, support, contractual, legal, and so on can be captured in libraries and reused for every major software purchase. Each new project is likely to result in some new requirements and enhancements to existing requirements, and a mature software selection process will use these to improve the libraries continuously.
Where requirements are used in the software implementation
One way to reduce the risks of implementation schedules slipping is to design the selection process to discover and collect information needed by the implementation team. Thus the requirements analysis should be thorough enough so that no significant new requirements are found during implementation, and that requirements are written to be implementable. If you can achieve this, the implementation project is more likely to be on time, within budget and to go live with minimal business disruption.
12. Implementation project planning
After the software purchase, the implementation project manager should have access to the evaluation, so the information collected can be used to plan and estimate the implementation project. If all significant requirements were captured and those requirements were written to be implementable, the project can be planned with greater accuracy and is more likely to finish on time. This information also reduces the amount of discovery work the implementation team needs to do at the start of the project.
13. Reduce implementation risks
No enterprise software is a perfect match for requirements, and even the best fit software has some areas of compromise. The evaluation identifies all areas where the selected product does not adequately meet requirements. The project manager then proactively allocates additional resources to prevent these areas from causing implementation delays.
14. Software implementation
Questions always come up during software implementations, and delays in getting answers are a significant factor in causing schedules to slip. When an implementation consultant has a question, knowing the reason for a requirement, the weight, and the desired business outcome of meeting that requirement may provide answers. If still more information is needed, knowing who wants that requirement allows consultants to reach the relevant people for answers quickly.
15. Acceptance testing
User acceptance testing is one of the final steps taken before software goes into production. Requirements should be documented so that tests can be developed to verify that the software meets those requirements. If projects go wrong, this can help avoid problems like lawsuits with software vendors and implementation consultants. Lawyers are the only winners in such lawsuits.
Marin County decided to implement SAP ERP, but after several years the project failed. They decided that SAP was not a good fit for their needs and needed replacing. Marin County then sued the implementation consultants for $30 million, but in a settlement agreed to accept $3.9 million which was less than Marin’s legal fees of $5 million. The legal action was a total loss and waste of time.
Had Marin County properly defined their requirements, they might have avoided this problem in the first place. Moreover, even if they did end up in court, an adequate requirements analysis would likely have won them a larger judgment. Interestingly enough, Marin replaced SAP with software from Tyler Technologies, and in October 2017 announced the HR and payroll go-live date had been postponed indefinitely. This repeated pattern of behavior strongly suggests that Marin still has not properly defined their requirements.
Where requirements are used in production
16. Maximize software value
After completing a major software implementation, everybody involved is ready to move onto new projects. Valuable software features can end up unimplemented. Having a comprehensive list of weighted requirements along with how well the software meets them can prevent functionality from being overlooked and underused. When those features are later implemented and used, the software value is maximized.
Wrapping up
Most people think that requirements are simply used to select software, but in reality, they are the foundation to maximizing the value returned by a major software purchase. Understanding where requirements are used can help drive the commitment needed to turn a difficult project into a success, and that can help you become a corporate hero.