Software Selection Primer

Too many major software purchases look like this! Our aim is to ensure the software you purchase meets expectations. We offer a comprehensive selection service, but if you want to do a project yourself follow this 4-Phase process to minimize risks.

 

Phase 1: Requirements Analysis

1.1 Before you start

  • Realize that 50% to 80% of the work in selecting software is in the requirements phase. This phase will take a long time.
  • Decide on the tool you will be using to gather and manage requirements.
    • Spreadsheets are OK for gathering requirements before the project starts. However, even relatively small software selection projects can run into hundreds of requirements. As the number grows, they begin to get difficult to manage, especially when you are comparing multiple products.
    • Request a free account on our Software Evaluation App, which automatically does the gap analysis and ranks the products by Fit Score.

1.2 Comprehensive Requirements List

Just as constructing a building needs plans, a software selection project needs a thorough requirements analysis.

1.2.1 Project Kick-Off Meeting

  • Start with a kick-off meeting to let your organization know the project has begun.
  • Invite as many of the people who will use the software as possible.
  • Use this meeting to inform people why new software is being selected, and how you are undertaking the project. This is your first opportunity to create and nurture employee buy-in.

1.2.2 Gather Requirements From Users

  • Arrange individual meetings with key employees to gather requirements or particular software they want to be considered. Most employees only know their pain points, so don't expect too much.
  • The primary purpose of these meetings is to build rapport with key users. This is your second opportunity to nurture employee buy-in.

1.2.3 Product Research

  • Research the market for potential products that could satisfy your needs. You can use sites like G2 Crowd, Captera and TrustRadius.
  • Remember that just because a software product is rated highly on these sites does not mean it is a good match for your requirements. The whole purpose of an evaluation is to discover your requirements and then measure how well products meet those requirements.

1.2.4 Develop Requirements

  • Add any requirements you already have to the list. For example, from other evaluations you have done, you may already have lists of requirements common to many products covering areas like usability, security, support etc.
  • Scour the web for RFPs for software similar to what you are using. Public Agencies that publish RFPs can be a very useful resource.
  • Consider purchasing lists of requirements if you can find them.
  • Use the technique of reverse engineering requirements from the features of potential products. This is how you discover unknown requirements. Any requirements missed at this stage will be discovered during implementation, where they cause delays and schedule overruns.

1.2.5 Implementation Vendor Research

  • If the implementation vendor will be different from the software vendor, develop due diligence requirements for them.

1.3 Weight requirements for Importance

  • Schedule meetings with the appropriate employee teams to weight requirements for importance to your organization.
  • Capture who wants each requirement, why they want it, and how important it is to them. Ensure employees see their details written on the requirements.
  • This is the third opportunity to build employee buy-in, and the most critical.

The output of this phase is the Requirements Profile, a comprehensive list of requirements that have been rated for importance to your organization. This is your unique standard against which potential software products are evaluated.

 

Phase 2: Evaluation

2.1 Create the RFI

  • Create the RFI from the Requirements Profile. You don't need an RFP because you are still in the information-gathering phase of the project.
  • If you are using the Wayferry app, there is an option to export an RFI as a spreadsheet.
  • Send these RFIs to vendors who met the due diligence requirements.

2.2 Gap Analysis & Software Ranking

  • Capture the data returned from the vendors.
    • If you are using Wayferry’s Software Evaluation App, it will automatically do the gap analysis and rank software products by Fit Score.
    • If you are using a spreadsheet, design a scoring system so that if a software product fully meets all requirements it scores 100%. That makes it much easier to compare products.

2.3 Requirements Scope Check

  • Verify that one or more products have a Fit Score of at least 80%.
  • If no products have a high enough Fit Score, your requirements scope is too broad. You want more than the market can deliver. Either:
    • Adjust your requirements to better match what the market delivers (i.e. reduce your expectations)
    • Consider other products that offer a better match with your requirements.

 

Phase 3: Selection

3.1 Software Demonstrations

Remember that your analysis makes your purchasing decision, and the demos only confirm that decision.

  • Select no more than three software products for demonstration.
  • Create a demo script from your showstopper requirements. Give this to the vendors well before the demo, so that they have time to prepare.
  • Schedule the demos.
  • To maximize the value of the demos, collect and summarize employee feedback at the end of each demo; do not let people wait even until the next day.

3.2 Provisional Product Selection

  • Make a provisional software product selection based on the gap analysis and a summary of the demonstration feedback.

3.3 Audit & Validate

  • To eliminate "over-optimistic" vendors, audit and validate the provisionally selected product to ensure the software truly meets your Requirements Profile.

3.4 Check References

  • Interview reference customers supplied by the vendor.
  • To research other customers not supplied by the vendor you can use LinkedIn. Search for people who have the product name on their LinkedIn profiles. However, this only works for larger software vendors.

3.5 Purchase Software

  • If the provisionally selected product passes the audit and reference checks, the software selection decision is confirmed. You purchase the software knowing exactly how well it will meet your particular needs.

 

Phase 4: Post-Purchase

One of the biggest causes of implementation delays and unexpected costs are "new" requirements that should have been discovered during the analysis. Too many "new" requirements lead to project delays, business disruption, unhappy users, and unrealized expectations. The goal of an adequate requirements analysis is to ensure no significant new requirements are found during implementation. That is why the reverse engineering technique in 1.2.4 above is so important.

4.1 Implementation Handover

  • All relevant information discovered and collected during the software selection is handed over to the implementation project manager, who uses this to develop comprehensive and accurate project estimates.
  • Questions always arise during implementation. Many requirements have the reason why that requirement is wanted and how important it is. If questions remain, the requirement has the names of the people who want it, so implementation consultants know whom to contact.

Following the above process results in an implementation that is within budget and completed as planned. Once in production, the new software meet or even exceed expectations.