This post is an excerpt from A straightforward approach to navigating the software selection maze. Download your copy to get even more expert advice on navigating the many twists and turns of software selection.

Missed Part 1? Catch up here.

You’ve chosen your new enterprise software application – now what?

You should issue a request for proposal (RFP) to the chosen vendor. This document asks them to answer if and how they meet each of the software requirements listed and provide an estimate of costs. It’s essential the specifications are written with as much detail as possible, because you may not get the response you need if you don’t take the time to state the requirements clearly. Next, it is time for implementation and rollout.

You need to negotiate the contract before you let the vendor know they have been selected. Otherwise, you lose your negotiating power. Use the information gathered during the evaluation process to your financial advantage. After all, switching software applications, as explained in Part 1, is often driven by the need to save on costs. This is your chance to realize that.

Tips for enterprise software implementation and rollout

 
More than 90% of enterprise software purchases take longer to implement and costs more than was budgeted. Often, implementation issues arise when:

• New requirements are discovered during rollout that should have been recognized during analysis.
• An inadequate requirements analysis meant that the wrong product was chosen.
  

So that software goes live on time, within budget and with a minimum of business disruption, you should:

• Install the new software in a sandbox environment (where possible) and perform thorough testing 
  
  
• Define the ideal state of the new software – by capturing the business steps in workflows 
  
  
• Train users on how to use those business workflows with the new software 
  
  
• Put contingency plans in place to minimize the amount of business disruption 
  
  
• Know how you’re going to sell the new software to users and senior leadership 
  
  
• Expect productivity to drop substantially as users become comfortable using the new software 
  
  
• Take advantage of browser-based applications, where possible, as they cause the least disruption since there is nothing to install on local machines 
  
  
• Don’t think the job is done once implementation is complete – training for new features (product) or workflows (in the business) should continue long after the rollout is finished 
   

Summary

 
Don’t let the path of choosing new software lead to a dead end. Follow these steps to ensure things change for the better:

Reverse engineer the product you need by understanding the features that differentiate the products on the market. Focus on the details, rather than what the software does at a high level and rewrite the useful features of each as requirements for your new solution.

Value is in the eye of the beholder, so be sure to phrase technical features in terms of business requirements. If you can speak to what users need to do their job and get down to the right level of detail in this requirements stage, you have a much better chance of finding the right solution.

Document your requirements in detail in a spreadsheet and measure each software option against them. This will help you choose which product to change to.

Don’t rely on product reviews. While reviews may be a good place to start, don’t treat them as gospel. Reviews assume everybody has the same needs for a product, which is not the case.

Consider vendor support because you will rely on it during the pilot and deployment stages. Make an anonymous phone call to tech support to see what it’s like.