1. Defining requirements. A company should clearly realize why it is purchasing a particular type of software. In other words, employees and management must be well aware of their internal business issues and how the new software is supposed to resolve them.
I am surprised to see that a large number of companies still do not have full understanding of their business processes and, therefore, the exact pain points that drive a decision to buy or replace an existing system. They certainly know that, for instance, manufacturing planning in general should be enforced—but don’t know why exactly and what is needed.
As a result of not being aware of their relevant business processes, they are unable to translate them into the functional requirements of the desired software. So if they don’t know what software functionality they need in order to address their business process concerns, the software selection process becomes ambiguous and imprecise. It also leaves much room for software vendors to sell their clients what they do not really need, or vice versa, not to offer what the company urgently needs.
2. Defining the scope of the agreement. The full nature and scope of the contract, is, strictly speaking, unknown to both the client and the software vendor at the time of the deal. This owes partly to the nature of the product. There are a few reasons for this.
First, the exact number of users, and, therefore, required licenses is an approximation at the start of the project and will be defined fully only during the implementation phase. And the complexity of license pricing structure can play into the hands of the vendor, particularly tier one vendors.
Second, traditional maintenance and service fees depend on the number of licenses and the volume of work to be performed, which again, cannot be precisely calculated at an early stage and goes into the contract as an approximation.
Third, the extent and details of the functionality required cannot be fully defined at signing, mostly because companies don’t know about the software’s functionality until they have had formal training and can start testing the system. Until then, they can only rely on the claims of the software vendor on the available functionality.
For the sake of fairness, it must be noted that the on-demand software purchasing model makes the purchasing process more transparent and less confusing for the customer with regard to payment structure simplification and absence of software maintenance. But business-related uncertainties remain the same. In addition, the on-demand delivery method has its own issues, related to data ownership, security measures, ability to modify the software, and some others.
3. Defining success. The success of the entire project cannot be fully defined—much less guaranteed—at the time of purchase. Software acquisition in this regard is different from purchasing, say, massive manufacturing equipment—that either works or doesn’t after it has been installed.
For large software systems, this may be a point of contention, and can even result in a lawsuit—as the software provider and its client may have differing opinions on the quality and quantity of product and/or services received. Such grievances are seen to be the sole responsibility and culpability of the vendor, but the end result of a software selection project also largely depends on the contribution and involvement of the client’s employees, along with many other variables (changing business environment, economic or political situation, ongoing company acquisition, etc). There are some software vendors that offer a significant or sometimes even complete refund in the case of unsuccessful project overall, but those are the exception rather than the rule.