When developing requirements, ensure they are well written. If you can find them, existing lists of requirements from public RFPs or purchased lists can be big time savers although quality can be dubious. A critical step that captures unknown requirements is to reverse engineer features from potential products back into requirements. It is well worth the effort of front-loading requirements development. Unlike software development, when developing requirements for purchasing software you can identify all requirements before the project starts. Remember that every requirement missed at this stage will be discovered during implementation where it adds costs and delays.
The final step of this phase is to rate requirements for importance to the organization by interviewing the appropriate users. Typically, this takes the form of meetings with user teams where the requirements are presented. Here you capture how important each requirement is, to whom it is important, and why it is important to them. When users see their names and details being captured on the requirements, this continues to build buy-in.
More senior employees have a broader view of needs while those employees at lower levels are more narrowly focused. Both are important. Employees with recent experience at other companies often provide valuable input with different perspectives. If employees have been with the organization a long time, they can struggle to “look outside the box”, so you may want to consider using outside experts with experience in those areas.
Once all requirements have been rated for importance, you have a comprehensive requirements profile that adequately describes organizational needs. Potential software is evaluated against this unique standard.
Phase 2: Evaluation
Evaluating software is the step of objectively measuring how well the software meets the needs of the organization as articulated in the requirements profile. Usually, this is done by having the vendors respond to an RFI or RFP based on the requirements profile. In the evaluation phase, you are gathering information, so an RFI is better than an RFP. Take advantage of these techniques to maximize the value of RFIs or RFPs.
When the vendors return completed RFIs or RFPs, that information must be captured and then used to score the various products against your requirements profile. This step is the gap analysis, and the output is a fit score that measures how well each product meets the requirements profile.
Phase 3: Selection
Based on the gap analysis, rank the software by fit score and choose up to three finalists for demonstration. Using the showstopper requirements, create a demo script, and insist the vendors stick to it if they want the business. Make sure you collect feedback from demo attendees before they leave each demo.
Sign up for CIO Asia eNewsletters.