Software Selection: A Third Alternative Part One: The Buyer's Perspective

Introduction

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.

This is Part One of a two-part note.

Part Two will discuss the seller's perspective and the third alternative.

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.

Buyer's Perspective

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 worst.

One possible option might be to hire outside, experienced consultants. Consultants would deftly navigate the project team through review sessions and workshops to determine your 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 department's 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, the 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 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.

The number of companies, which 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.

This concludes Part One of a two-part note.

Part Two will discuss the seller's perspective and presents the third alternative.

About the Author

Joseph J. Strub has extensive experience as a manager and senior consultant in planning and executing ERP projects for manufacturing and distribution systems for large to medium-size companies in the retail, food and beverage, chemical, and CPG process industries. Additionally, Strub was a consultant and Information Systems Auditor with PricewaterhouseCoopers and an applications development and support manager for Fortune 100 companies.

He can be reached at JoeStrub@writecompanyplus.com.