The Project Delivery Group (PDG) here at Technology Evaluation Centers (TEC) works closely with our clients to assist and guide them through the process of evaluating and selecting their business software solutions. Over the years, this group has witnessed the multitude of issues and hurdles that can arise—oftentimes unexpectedly—during those selections and has become adept at helping its clients work through various scenarios. One of these issues relates to what happens when a company that is involved in a software selection process is suddenly mandated by upper management to purchase another software solution. The issue of an “imposed software decision” is the first topic in a series of reports prepared by TEC analysts in conjunction with TEC’s PDG to highlight current realities and present useful tips and practices for software selection projects.
Well, all seemed to be going according to plan with a recent software selection project—a typical project at that—with no foretelling that something would go amiss. The project was well organized overall. Following the best software selection practices, the company first appointed experts from each department to a group dedicated to selecting and implementing the software. The ultimate goal of this group was to review existing business processes, create an “as-is” company model, identify business processes gaps and overlaps, suggest improvements, select a suitable enterprise resource planning (ERP) system, and, finally, start implementing the chosen system. In fact, the group was well into achieving its goal. A large amount of work on creating the as-is model had been done, a long list of requirements for the ERP system had been compiled and priorities assigned, and a whole range of nonefficient processes had been identified, documented, and slated for improvement at subsequent implementation steps. The group was close to completing the selection process and examining a number of ERP software systems and creating a shortlist of four candidates to compare for best functional fit, related costs, and overall suitability to meet the company’s needs. Then, suddenly, the company was acquired by another company operating in totally different market.
Upon reviewing the ongoing ERP selection project, the new owners concluded that all this was all very good and extensive, but it was rather unnecessary, as they had already selected an ERP solution for the acquired company. The main rationale for this unexpected decision was that the mother company had purchased and implemented an ERP system a year ago and had access to leftover software licenses—which would lower the overall cost of system deployment. However, they had not factored in the software maintenance fees—which had increased significantly during this one-year period—annihilating the anticipated cost savings. Other important factors not accounted for were the current market conditions, the forced product’s nature and niches, its functional suitability for the acquired company’s needs, and other business realities. On other hand, some factors—which have nothing to do with the selection process—may have been given high priority, and could have been brought over with the mother company.
This type of situation happens more often than we’d like to think. We’ve all come across instances when top management, for their own reasons, mandated a specific solution, which wasn’t necessarily in line with the software selection results performed by a dedicated team using specialized methodologies and best practices. In some cases, a decision on the software selection was made before the selection project even began. The folks involved in the software implementation group may feel discouraged by the way the software decision was imposed upon them, and may not feel particularly optimistic about the subsequent steps of the system adoption. However, there are learnings the selection team and others can take away from this seemingly negative experience:
Therefore, regardless of the outcome, a properly performed software selection project—one that is well organized and follows best practices—can benefit a company in a number of ways. Establishing detailed software requirements that are in line with the company’s priorities, providing an in-depth description of the company’s business processes, and finding new means for improvements are all outcomes that bring real value to a company. And the findings from this process will certainly help in the implementation of any software system in the future. And, finally, there are cases when the selection and implementation teams were able to convince top management to forego a mandated software decision and sign a contract with a vendor that offered the best-fit product, as determined by the software selection process.
The article was well written - describing both the4 pluses and minus’ of going with ‘the selection’. Many times those involved with a product research become personally attached to the selection and there is a tendency to become overly disappointed if the recommendation is not selected.
The article covered this well.
I am not understand your mesege