Missed Part 1? Catch up here.

The real sticking point with software is not the high-level features; it’s the details. To start your evaluation process, you need first to pick the features that differentiate your top two or three potential applications. Then, you rewrite them as business requirements. This is reverse engineering. You won’t need to reverse engineer each product you’re evaluating – just the differentiating features.

Evaluating software will open your eyes to features you didn’t know existed – especially if you have been with the organization for many years. Some people may struggle to see software outside the framework of their current job, and how they’re used to working.

Often, this is the kind of person who will buy new software and try to replicate the old product, so they don’t have to make significant changes to their processes. But this defeats the purpose of buying new software – to improve and streamline current processes.

Imagine you’re watching a property show on TV, and the buyers come on, and they say, “We want X, Y and Z,” and they look at two or three houses, and they buy something totally different from what they said. What’s happening there is they don’t know what they want. They think they do, but when they actually see it, it turns out that they were wrong.

Don’t rely on reviews to choose enterprise software 

Once you have your detailed business requirements and metrics for evaluating the software written down, that can help you choose which products to try. You have to determine what is valuable to you and your company, and that’s different for nearly everyone, which is why you can’t rely on reviews. They are written assuming everybody has the same needs.

At this stage of the evaluation process, you will hopefully have selected two or three applications to try. Now, it’s time for the people who will eventually use it to test it out, which nurtures user buy-in. Without that buy-in, users will be much less willing to try something new, and your project will have less chance of success.

When is the right time to request a product demo?

You should demo at least two products, so you can compare them. You don't want to demo more than three, however, because that will overload the users who have to balance it with their usual workload. Requesting a demo from the technology provider sooner in the selection process could result in several negative consequences, including:

• Time is wasted when there are too many demos
• Feedback isn’t properly captured because the process may be rushed
• Users are too confused by multiple demos to provide useful feedback.

The demo should work to confirm what you already know of the product and its features, not surprise you with lots of new information.