Whether it is an enterprise resource planning (ERP), a customer relationship management (CRM), or any other system, acquisition and deployment of enterprise class software is usually a significant move for a company of any size and industry. It leads to disruption of the company’s business activities, so much so that hardly any employee is left unaffected during such a major project.
The good news is that software acquisition does not happen often, but the bad news is that this infrequency uncovers another hidden facet of this project. Employees and management of a company that do not purchase and implement a significant number of software applications on a regular basis are, in fact, amateurs that are mandated to deal with software vendors whose only order of business is to develop, promote, and sell their software, every day. And while these highly experienced professionals are usually aware of the potential client’s wishes and concerns, their goal first and foremost is to persuade their clients to purchase and deploy the software.
Being on unequal footing from the outset, you may find it difficult to pursue your company’s objectives and effectively manage the process for evaluating, selecting, and purchasing the right software for your company’s needs. Now let’s see why it’s so difficult to simply compare 3 or 4 software systems and choose one, and what is the difference between buying software and buying other assets?
Based on my experience with software vendors and working on end-user software selection projects here at Technology Evaluation Centers (TEC) for several years now, I think the biggest problems with buying software lie with the following three types of uncertainties:
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.
So, how can companies deal with all these issues? There is no single recipe that deals with all, but here are some suggestions that may help clarify and streamline your software purchasing process.
The success of software selection and implementation—an extremely complex and business-based project—depends to a large extent on how prepared you are when you speak with the software vendor. You need to know your business processes intricately, bring in individuals that will help you tackle the difficulties you will encounter throughout this project, and know the software functionality that you seek—so you can see beyond the sales hype and make the right choice for your company.
My experience has confirmed that asking the vendor to conduct demos based on pre-defined business scenarios and scripts by the client (usually through a requirements definition/business process consultant) as a very powerful approach. A study undertaken has shown that only about 40-50% of invited vendors show when the client seizes the initiative of what is expected of the demo - a fantastic way of improving success factor from the onset.