There are five traps of software evaluation that often catch people when seeking to purchase new software for their teams or organisation. These come with a significant impact on productivity, compliance and profitability for the next five to ten years. Making the wrong decision can cost millions of dollars in critical failures, workarounds, rollbacks and lost opportunity.
The good news is that all of these common traps of software evaluation and procurement can be avoided.
Sponsor engagement and understanding
The sponsor is the senior executive or manager who is ultimately responsible for signing off on the software procurement and implementation. Typically this is the person who controls the money. Due to their control over the budget, this individual can drive project success or completely run the project off the rails.
Sponsors can easily fall into the traps of software evaluation when they are inexperienced or their perspective is based on advice that is not aligned with the current state solution and available future-state options. This leads to decisions that require project teams to act in ways that ultimately undermine the effectiveness and workability of the solution.
The project sponsor must understand the role of the software within the broader information pipeline in which it serves its purpose. These key players must take a genuine interest in the problem and projects they are responsible for. They should be open to advice from team members and take a proactive approach to identifying risks, dealing with issues and resolving barriers.
An engaged and self-aware project sponsor is a critical factor in any digital transformation initiative.
Being too specific or inaccurate with your requirements
Software evaluation and procurement means purchasing commercial off-the-shelf (COTS) software. Your ability to influence the feature set of COTS software is very limited, if at all. While it is critically important to understand your business needs, it is not necessary to describe your requirements to the nth degree. A high-level description of your business needs and requirements is all you need.
While your requirements need not be too specific, they do need to be an accurate reflection of the current and future state within which the new software product will operate. Being inaccurate in your requirements specification will likely lead to issues in the implementation phases that are costly in both time and money.
In this trap of software evaluation, requirements are gathered from people as the only type of source. In the worst cases, requirements are defined solely by the loudest or highest-ranking stakeholder in the room. This is avoided by taking the time to create an accurate and validated requirements specification. When doing this work, it is very important to have healthy criticism of the opinions of people, no matter who they are. This is achieved by validating what people say with evidence from the platform and process aspects of the overall information pipeline.
An accurate requirement will be validated by at least one source from each of the people, process and platform aspects relevant to the scope of the solution.
- People source = a person such as a user, subject matter expert or manager.
- Process source = documentation, such as standard operating procedure, policy or process map.
- Platform source = the requirement is derived from the information architecture, system specification, or data of the information pipeline in the scope of the project.
The requirements specification is the shopping list that you will use to identify and assess the software solution. If your requirements are inaccurate or too specific, your evaluation is likely to be at risk of missing critical functionality, costing more, and limiting the benefits achieved.
Too many cooks in the requirements kitchen
Everyone wants to have their say when it comes to the selection of a software product that a team will use in their daily work. Listening to the thoughts and opinions of as many people as possible is important to ensure the full range of requirements is identified.
When it comes to questions of accuracy and priority, achieving consensus among all stakeholders can be difficult. Even within a small team, people can have very different perspectives. This can delay software procurement efforts by months and waste tens of thousands of dollars.
This trap of software evaluation is overcome by setting up a clear decision pathway at the beginning of the initiative. This should describe the key roles of the project team and its stakeholders. It will describe the scope of decisions that can be made by each manager in the decision tree ending with the project sponsor who has the final say.
Seeking one system that does everything
The unicorn of business software is ‘one system that does everything we need’. This desire comes from a place of wanting to simplify the information technology architecture and reduce costs. While the desire is real, the solution is a unicorn, it doesn’t exist.
Do not seek one system that does everything. Instead, seek the system that aligns with the specific task that you need to manage your information. This is how you build effective, efficient and reliable information pipelines in your organisation. It is a core aspect of being successful in digital transformation.
Any given software solution will provide a useful functionality for a specific purpose. These are defined not by you, but by the software vendor. If a new product is to simplify your business operations then it must fit into your existing and future information architecture. Like the plumbing in a bathroom renovation, your new software must have functionality that is compatible with the other information systems in your business. Understanding this and selecting software accordingly is key to creating and maintaining streamlined and reliable business information systems that can stand the test of time.
Confusion over procurement processes
Buying software is different from purchasing other business services like stationary, tradespeople or consulting. Acquiring new software for your business occurs once every five to ten years. In between, both your business and the software will change. Agreements with software vendors should be set up with flexibility and continuity in mind. They should allow for inevitable adjustments to the scope of work and deliverables during the implementation project. For the long-term, user licencing and service agreements will need to flex as your business matures.
The information in your organisation is managed with software. If the software stops working, then so do you. This is why software contracts should not have a fixed end date but rather allow for annual continuation in perpetuity. Yet, too often organisations discover this trap of software evaluation when their business is at risk of shutting down because of a long forgotten contract end date. This creates issues and costs that can and should be avoided through supply contracts that are fit-for-purpose for information technology.
You can avoid the traps of software evaluation
Software evaluation and procurement is a critically important decision for any organisation. Unfortunately, professionals who are experienced in both procurement and implementation of information technology are rare. Procurement teams are not familiar with these five traps of software evaluation and likewise, technology teams are not familiar with the maze of procurement and financial processes. As a result, many organisations repeat the same avoidable mistakes every time they need to bring in new software to their business.
An experienced and independent professional who can close the gap between the procurement and technology teams can make all the difference.
I have been helping organisations make software decisions for over 20 years. I can help you make the right choice for software in your business.
