Experience has taught many of us that selecting a piece of enterprise-wide software is more of an art form than a science. In software selection, “2 + 2” may equal “4”—if the software selection process is successful and the right software, in all aspects, is selected. Or, “2 + 2” could equal “3” if it is partially successful in that the software meets many of the company’s needs but places a technological burden on the infrastructure. Or, the result could be “0” if the selected software totally fails to meet the company’s needs or organizational temperament.
Trying to read through the vendor marketing hype; ensuring that consultants are operating at an arm’s length from software vendors; and calming the doubts of users concerned about whether their interests are being impartially represented are just some of the project potholes that need to be avoided. Even if you can artfully sidestep these and other potholes, a selection project could appear to end successfully but without the clear and unbiased rationale to support the software decision. Without this rationale, user doubts may continue and the “I-told-you-so’s” may later crawl out the woodwork.
It has indeed become a difficult task for corporate IT buyers to discern the true capabilities, strengths and weaknesses, and degree of fit when selecting a given enterprise application suite for their business environment. Unfortunately, software solutions are not readily available from a local “Enterprise Applications ‘R’ Us” outlet; the “one size fits all” mentality does not play well in the corporate sandbox; and the propaganda that pervades vendors’ endeavors to differentiate themselves only serve to further confuse matters.
When making strategic IT acquisitions, project teams can be confronted with an abundance of product, technology, and hardware combinations and choices. Accordingly, they have a difficult time translating the glitzy marketing brochures and grandstanding presentations and demos into deliverable product capabilities. There is a need to move the software selection process closer to the realm of a science, with expected outcomes based on specified inputs, rigidity, and a definition of process.
Existing Selection Methods
There are two prevailing approaches for selecting enterprise-wide software. First, there is the traditional analysis of a company’s needs versus the functions and features of the software and identifying the vendor’s software with the best fit or least gaps. Second is selecting software with the best practices and processes to meet, satisfy, and improve the business-critical aspects of a company. The tagline that typically accompanies this second method is “Why worry about accounting? Worry about the production line, where money is made and lost.” It is hard to argue with this logic. As you might expect, the first approach provides the company with greater assurance that the majority of users will be satisfied, whereas the second approach is the predominant favorite of software vendors. Is there a third or hybrid approach that takes of the best aspects of these two approaches?
To understand the selection process, this article first looks at issues that confront the company buying the software and the issues of the vendor selling the software. By understanding the issues confronting each side, this article will consider what value can be gained by combining the best of the functions and features approach with a business processes approach.
For the purpose of this discussion, it is assumed that the analysis of functions and features can, and possibly should, be accomplished through the use of a selection services. For an overview of this service, see the TEC article entitled, Ways of Finding Software Vendors: The Pros and Cons.
Finally, this article will draw on some of the information contained in the article Evaluating Enterprise Software—Business Process– or Feature/Function-based Approach? All the Above, Perhaps?
However, the intent here is to concentrate on the formulation of a hybrid approach that addresses the concerns of both buyers and sellers.
Prospective customers typically struggle with many issues when selecting enterprise-wide software and technologies. For reasons that are typical of human nature, users often have a difficult time documenting what they do. This reluctance delays the selection process and the eventual benefits to be derived from the software.
Unfortunately, this delay occurs at the early stages in a selection process, just when you are trying to break the inertia and gain momentum. Trying to break through this logjam requires a series of interviews, white board sessions, and flowcharting. While you could argue that these activities provide a good learning experience, when time is of the essence, finding effective shortcuts can save the project and preserve the team’s morale. A selection service can help break through this logjam by providing or suggesting features for each functional area, as shown in figure 1. Then it is a simple matter of filling out a worksheet to specify the features desired. The theory is that this “laundry list” of features will remind users of what they need in their functional area. If not, reason stands that they must already know what they do need or want.
Figure 1: Features by functional area worksheet
The software selection project team often has no effective way to define and document its business requirements, and thereby identify and prioritize the critical criteria necessary to successfully support the evaluation process. This is further hampered by the user reluctance described above. Since the scope of an enterprise-wide application is extensive, data collection and analysis can be a time-consuming process. Changing user priorities can only make matters worse.
One possible option might be to hire outside, experienced consultants. Consultants would deftly navigate the project team through review sessions and workshops to determine its requirements, which were theretofore uncharted waters. However, you could make better use of this valuable resource by providing a basis from which to start. Accordingly, it may be more reasonable to begin with an existing request for proposal (RFP)—again, a typical output of a selection service that could be tweaked to a company’s unique requirements. When an RFP’s criteria and a consultant’s expertise are combined with a software tool that can measure the degree of fit with vendors’ specifications, efficiency can be achieved without sacrificing objectivity and thoroughness.
Without such an objective tool, final priorities are often more the result of internal political agendas than the true needs and requirements of the company. Without having a valid statistical tool to keep these priorities in check and to conduct simulations of results after changing priorities, it is likely that some departments’ needs, say accounting or IT, may have an unreasonably high influence in the total decision. The concern is whether this influence is commensurate with the department’s direct contribution to the company’s bottom line. To understand the degree to which this phenomenon may be occurring (and it does), a tool can analyze the weight of criteria by functional or departmental area. At least you will be able to determine whether some shifting influence may be appropriate.
Also, project teams may lack access to objective, independent, and current data on available vendors’ products. Unfortunately, this lack of access may preclude project teams from separating the facts from a vendor’s hype. This is particularly true when a vendor’s strategic technology is touted to be either the first of its kind or the first in an extended period within the company making the selection.
Even after the first pass of the criteria and vendor selection, changes in priorities and requirements are likely. Considering that this is an iterative process, responding to these changes without the benefit of a software tool can be a daunting task, further prolonging an already lengthy process.
As a result of these and other issues, it is not surprising that a vast majority of enterprise software evaluations run over time and over budget. Furthermore, once the software is selected, a large majority of the implementations fail to meet functional, return on investment (ROI), and total cost of ownership (TOC) expectations.
This concludes part one of a two-part note. Software Selection: A Third Alternative Part Two: Seller's Perspective and the Third Alternative discusses the seller’s perspective and presents the third alternative.
The number of companies that are able to substantiate or provide the rationale of the decisions to go with one product over another is slim. Unfortunately, a much higher number of companies rely solely on unsubstantiated justifications, like their “gut-feeling," an executive mandate, advice from a friend in the business, or tiresome spreadsheet compilations—none of which may discern the best solution. Reviewing the objective and logical path that was followed to arrive at a preferred vendor can disarm even the harshest dissenter of the selection process, particularly if his or her choice was not selected.
Accordingly, the buyer is interested in ensuring that critical functional requirements are identified and a reasonable number of appropriate vendors are considered. Furthermore, the methodology must be able to easily accommodate changes in priorities and provide an audit trail that supports the ultimate software decision. While a traditional, manual selection process can satisfy some of these objectives, a selection service, together with its accompanying automated software evaluation tool, can satisfy all of them in the least amount of time and, typically, with the least amount of money.
About the Author
|Joseph J. Strub has extensive experience as a senior project manager and consultant for the planning and execution of ERP projects for manufacturing and distribution systems, and for small to medium size companies in the retail, food and beverage, chemical, and consumer packaged goods (CPG) process industries. He has developed marketing and communication programs for IT organizations, and consulted on offshore, outsourcing opportunities for multinational companies. Additionally, Strub was a consultant and information systems auditor with PricewaterhouseCoopers, and an applications development and support manager for several Fortune 100 companies. Currently, Strub is an independent consultant. He can be contacted at JoeStrub@WriteTechnologyPlus.com.