Evaluating and picking a new software can be a daunting process. If you work in a small business, it’s usually a bit less complicated. Being agile and being able to try out new things is a competitive advantage for any small business. Sadly, as your business gets larger you can’t just install something and be done. There are established procedures and interfaces that you need to understand and take care of. These changes take time and that’s why software evaluation and implementation for medium and large businesses is crucial. It could be new ticketing system for the helpdesk or a new CRM program for your sales team. Regardless, if you avoid these 10 mishaps, this will help to make your project a success. So here are ten things you shouldn’t do when buying or evaluating new software.
1. Ignore Stakeholders
What is a stakeholder? It is anyone using the software or who is affected by it. It is probably the most important aspect of your project to identify them early and to make them part of the evaluation process. You may be tempted to take shortcuts and to not include some departments for the sake of expediency. However, this will come back to kick you in the backside later. Let’s say, you’re evaluating a new helpdesk software and your company has support departments around the world. If you only talk to the helpdesk people at headquarters then, you will alienate the other departments and they make become a roadblock to success when you’re trying to rollout the new program. Also there are features such as multi-language support that can only be identified if you talk to the right people.

2. Missing Requirements
Don’t invite software vendors to showcase their application before you have an actual requirements list. If you do that, you’re wasting not only your own time but also the vendors time. Have a clear and weighted list of requirements and know what you’re trying to achieve before setting up meetings with vendors or demos. Only then will you be able to make an assessment what the software can achieve.
3. Mission creep
So the new accounting software can also do software deployment or the new CAD program can host a music database. Who cares? This may be a great sales argument in talks with the CEO but it has no bearing on your mission to find the right application. Don’t try to find the „Swiss Army Knife“ but instead focus on your actual requirements. Killing more than one bird with the same stone is a recipe for failure.
4. The Highlander Principle
From the start you should assign clear responsibilites. Who is in charge? If multiple teams or departments are working on the same project, you need to put a stop to that right away. Vendors will notice and it will make a chaotic and unprofessional impression both inside and outside the company. Unclear assignments can quickly become a show-stopper as the different teams begin to block each others progress.

5. Check and double-check
One thing you’ll notice as you put your requirements out to the vendors, is that for each ‚must‘ requirements they will always answer ‚Yes‘ or ‚Yes, but…‘. Rarely will you receive a ‚No‘. That is because vendors know that if they fail to meet the requirements, they may be kicked out of the evaluation process. Let’s say you ask for the program to have multi-tenat capability. What does that mean? The vendor may say ‚Yes‘ only to reveal that you need to install a new server for each tenant and buy additional licenses. It’s important to have the same understanding about any requirement you define. If in doubt, call it out.
6. Form over Function
Let’s say you’re evaluating a new backup software and you have found an application that has all the bells and whistles. On paper, at least. However, when you try to use the software it’s so complicated and has such a terrrible user interface that you start pulling out your hair. Another software may have a brilliant and easy to use GUI and may require far less in training hours for your staff. Would you rather buy a software that is made up of several parts that don’t fit together or something that has been developed from the group up to fit the task?
7. Cost is King
In any software evaluation, price is a factor but it shouldn’t be the most important one. Look at the service and support organisation because there might be hidden costs, that you are not immediately aware of. Does the price include training hours for your staff or do you have to pay extra? Can you get the support you need in the right languages and what are the business hours?
8. Missing References
Ask for references and talk to other companies that are using the application. Do they have the same business structure as your company? Let them show you the main features and also ask for negative feedback. Talk to people that haven’t been recommended by the vendor and discuss critical points before making a purchase decision.

9. Suppress Criticism
In some cases, you may already know an application from a previous project or employer. However, just because the software worked once, it doesn’t have to be like that every time. Listen to other voices and don’t fall for information bias. Always remember that you’ll have to be part of the implementation after the purchase decision and you need everyone on-board. Programs and people can change over time and even if the application was good once, it may no longer be the best fit.
10. No Transparency
Publish and distribute your processes and decision criteria as openly as possible. What was the decision process? Who was involved? Why was vendor x not included? If you try to be secretive about your purchasing decision, that will only give rise to gossip and rumours. Fight rumours early on, by addressing them and by being as transparent and open as possible. Do not endanger the success of the project by allowing rumours to spread.
Final Thoughts
This post is part of the ’10 things‘ series but as I’m writing these words, I can think of at least two more points that can go wrong. As with every project, there is the human factor. Working togehter and communicating with others can not be put in a checklist but if I needed to summarize then I would say this: Always choose a good project lead, who has experience in these matters and knows the pitfalls of software evaluation: 11. Don’t try to cut corners by not having a good project lead. 12. Provide enough time and resources to project members, so that they can take part in project meetings etc….
Here’s a reminder of ways you can interact with us:
- ‚Hammertime‘ – Send uns your ideas and let us know what you think
- Get the ‚T-Shirt‘ – Impress friends and family while supporting our site.




















