One of the most difficult tasks for a company is choosing a new software or SaaS application. Especially when that software is mission critical to the business. It becomes that much harder when you have more than one person involved in the selection process.

This endeavor usually includes a bunch of software demos, many spreadsheets tracking the features and benefits, and sales collateral from all the vendors all over your desk. Very quickly the whole process can become a blur with each software package resembling one another. Opinions come from all sources… family, vendors, and even your close competitors will offer their two cents on the subject.  But do their suggestions even fall inline with your need?

Internally everyone picks a favorite and fights for that software. No one wants to make a mistake and a bad decision would have to be lived with for years. For the person leading the software search it can even mean their job. Weeks become months and the need for the upgrade becomes stronger for the business.

Does this seem familiar? I like to call this stage “Analysis Paralysis”. Action becomes inaction and the whole company suffers. Often a company can linger in this stage for weeks or even months without coming any closer to a decision.  Worse vendors are always releasing new versions and updates which can cause more confusion and delay selection.

So what can you do?

One of the easiest things to do is look to the outside for some help.  Get that Software Sherpa!  This individual is a consultant that can guide you through the selection process and help you choose the correct solution.  He or she will keep you on track throughout the selection journey.

So what should a Software Sherpa do for you?

The Sherpa should act as the head coach for the project and help your team get to the correct application decision. The Sherpa should set a clear selection plan with target and milestone dates for each task. This journey should look something like this.
  1. Define Requirements: The Software Sherpa will meet with each of your key stakeholders and help you define what you need in a new software of SaaS package.  After the initial discovery the Sherpa will then develop an overall requirements document and share with your team.  Requirements can include features and functions, reporting, support hours or price.
  2. Finalize Requirements: During this phase the requirements draft can be reviewed by the team and feedback and discussion should take place.  Any changes that need to be made need to be done in this phase need to occur now. It has to be done before the specs hit the street. These changes are gathered by the Software Sherpa and added to the final requirements document.
  3. Define Acceptance Criteria: No software will meet 100% of the requirements you define.  It is important to determine which requirements are “must have” features.  Those critical requirements must be present in any software evaluated or immediately disqualified. This will remove any outliers during the selection phase. Next, the Software Sherpa create a scoring matrix for each requirement to aid in final selection.
  4. Vendor Demonstrations: During this phase the vendors should demonstrate their software or SaaS solution and show you how it will meet each of your critical “must haves”, once that is complete, allow the vendor to then share their unique features and present how they are different from their competitors.  By having the vendor present the “must haves” first you can confirm the software meets your requirements before falling in love with the “cool stuff”.
  5. Take a Test Drive: Whenever possible trial the software.  This will let you use the software and see if it meets your usability requirements and let you get a feel for how it will perform for you.  This may not be an option with some of the Enterprise software packages, but should be fairly easy to obtain from a SaaS vendor.   The Software Sherpa will then gather feedback on each users experience and evaluate where a package may come up short.
  6. Test support: This is critical and if you don’t think so read my earlier blog on the subject.  Effective support is as, if not more, important than the software functionality.  The Software Sherpa can confirm support stories with other users of a software package and quickly help you rule out sub-par support suppliers.  Additionally, in cases where a trial is included the Sherpa can test support by starting multiple service requests during the trial to test response, escalation, and time to close.
  7. Narrow the list: The Software Sherpa will then create a short list to make a final choice.  This should be limited to two, but no more than three options to keep the final decision making process as short as possible.  Any software not meeting 100% of the “must haves” should be discarded.
  8. Mediate the Selection Process: This is likely the most important role the Sherpa provides to the team during the project.  Here the Sherpa should set clear expectations on when the decision will be made, refer back to the agreed upon requirements to keep all parties focused on making a decision.  The decision should almost be clinical at this stage with the scoring dictating final selection.  Any debate should be limited to cases where two software’s packages are almost exact in features and benefits. You should remove emotion from the decision making.
  9. Commit: The team makes the selection and final negotiations and contracting can occur.
  10. Implementation: The Software Sherpa will then work with the vendor in setting clear implementation goals and in some cases, remain on as the project manager.
  11. Adoption: The Sherpa should then help the team in creating the roll out and adoption plan to the end user community.  This plan should include a follow up schedule to ensure the software is being used throughout the organization. Additionally, user feedback should be tracked to confirm the software is meeting expectations.  Where user adoption falls short of the goal the Sherpa will work to make changes to increase usability.

A Software Sherpa can help you eliminate a lot of the noise commonly found in a selection process and reduce emotional buy-in.  The result should be the new software going to production in a significantly shorter time period than if you had made the decision on your own.  The software will have been tested and support proven bringing a higher level of confidence to the project.

Let us know if you have used a consultant to help guide your selection process? Was it a success? Do you have a software selection horror story?  Let us know in the comments section below.