Missed Part 1? Catch up here.

As the saying goes, when you fail to plan, you plan to fail. Follow this six-step process to determine what the new software should look like and you will be sure to end up in the right place.

1. Define the business strategy

What are the business goals of changing applications, and how does senior management expect the new system to support them?

2. Future proof

Define the ideal future state of the software in terms of business processes. Describe what the software will do in all the areas where the new system will be used. For the different business scenarios you imagine, document the processes down to the step level (a high-level list in a spreadsheet is adequate; no need to spend time on detailed branching workflows). Capture the value drivers for each scenario - the "why" it is worth doing that step.

3. Estimate the value of the new system to the business

Since the system is likely to be used for five years or more, estimate the value of the system to the organization over that time. Look at the primary value drivers for the software. For example, consider the risk of data breaches, and the cost of those breaches over five years. Remember that value is created by achieving business goals.

4. Define your business requirements

Because they are not software specialists, your colleagues may struggle to capture their requirements. However, when they see a written requirement, they can always tell you how important it is to them. This is one reason why you need to create a comprehensive list.

• Capture the business requirements for the steps you identify in step two. Look to the future state of the system and what the software must do. Do this down to a level where user acceptance tests can be written for each requirement. Link all the software requirements back to process steps or business scenarios. 
  
  
• Look at the differentiating features of competing products and rewrite these as requirements. This is called reverse engineering and is the best way to find requirements users don't know they need.
  
  

5. Weight requirements 

For each requirement, capture who wants it, why they want it, and how important it is to them. For example, requirements can be weighted as:

• Showstopper
• Critical
• Important
• Nice to have
• No interest 
  
  

If several people have different weights, e.g., one person says “important” while another says “showstopper,” take the highest weighted. Don't forget to identify who will test each requirement is met before the new software goes live.

6. Evaluate, select, and purchase

A hasty or half-hearted evaluation and selection process might save time and effort in the short term, but over time it will increase costs, including:

• Software selection and implementation costs – if the chosen replacement doesn’t work out and you’re forced to restart the process, the software selection, and implementation costs will be two-fold. E.g., selection costs can be around 20% of the software license cost, while implementation costs can be 100-300% of the license cost.
  
  
• Replacement costs – the cost to replace new software with another product could include early termination penalties if multi-year contracts were signed.
  
  
• Dual systems costs – sometimes, legacy software must be maintained while problems with its replacement are resolved. This means double the cost and, often, double the work to keep both systems synchronized. The longer they run in parallel, the higher the costs.

Tips for purchasing new enterprise software

 

• People do not like talking about their failures, which is why you do not hear about many of them. However, if you ask, people will often open up and tell you about their frustrations with the existing software.
  
  
• A significant software purchase will be a substantial financial investment for an organization or will have a significant fiscal impact on that organization.
  
  
• Software purchasing success is meeting or exceeding the expectations of users and others involved with the purchase.