Home
 > Research and Reports > TEC Blog > Software Selection: A Third Alternative Part Two: Seller'...

Software Selection: A Third Alternative Part Two: Seller's Perspective and the Third Alternative

Written By: Joseph J. Strub
Published On: May 16 2005

Introduction

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 any given enterprise application suite for their business environment. 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 the 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 definition of process.

To understand the selection process, this article first looks at issues that confront the company buying the software and the vendor selling the software. Understanding the issues confronting each side, the article considers what value can be gained by combining the best of the functions and features approach with a business processes approach.

This is Part Two of a two-part note.

Part One looked at the buyer's perspective.

Seller's Perspective

The vendor's approach to software selection has its merits although the methodology may have a built in bias. Vendors are obviously interested in their software and want to get to the decision, good or bad, in the fastest route possible. On the vendor side, however, there can be detours. These detours include the unduly long and costly sales cycle to educate potential clients of software offerings, painstaking and numerous responses to questionnaires, and the possibility of pursuing a mismatched opportunity. All of these can cause a project to go terribly awry, increasing the time and money vendors must expend in the pre-sales cycle. Some may argue that this is just the cost of doing business and it is built into the software prices. While this suspicion may true, it is only built into your software price if you make the decision to buy. As a result, you may also be paying for the costs and time invested in sales cycles for unsuccessful clients.

Vendors will argue that by implementing their software with little or no modifications, the client can take advantage of the best practices embedded in the software. Furthermore, according to software vendors, buyers should concentrate on the business-critical processes. Vendors will argue that you should not waste your time on minor functions and features, RFPs, and analysis of checklists. However, unless the client has the discipline and commitment to embrace these practices, havoc and dissention may prevail. Typically, clients do not foresee the impact of best practices in terms of the changes in their organization or they underestimate the degree of internal resistance. Consequently, departments balk at using the software unless it works and feels like the old software. Can you spell "enhancements?"

Vendors are also confronted by an emotional issue when they persist in their approach of selling business processes or solutions. This approach is not your typical business model whereby the buyer of software and services must conform to the methodology of the seller. Buyers prefer to present their requirements in a format that they are comfortable with. Furthermore, they are more comfortable with defining what they need and letting the vendors document how they can satisfy these needs. In so doing, the buyer always has the excuse that the vendor did not disclose certain issues. To counter, the vendor blames the buyer for not doing its due diligence. Let the finger pointing begin.

If buyers and sellers proceed down the business process and solution path, there may be another issue waiting for them during the implementation. Having inadequate information to assess the software's ability to fill gaps can result in software failing to meet intended expectations that were never investigated. Fear and loathing will be followed by the dreadful "scope creep" to make up for perceived lost functionality. Furthermore, this type of situation, where little documentation is available, makes it difficult for even the most experienced consultants to step in, save the day, and constructively assist the client in making proper software and technology decision.

Failed projects do not bode well for the vendor. Their sales cycle costs can only rise even more and their reputation can suffer or, at least, become suspect. Surely, the consequences can be much more severe for the client where an incorrect software selection can lead to business losses. Accordingly, it is in everyone's best interest to select the right enterprise software and do it economically but with confidence.

Combing the Best of Both Approaches—The Third Alternative

The buyer wants comfort, coverage, and adequacy so that their needs will be satisfied. The seller wants speed, efficiency, and satisfaction when selecting their out-of-the-box solutions. It's the classic "men are from Mars, women are from Venus" confrontation. The dilemma is that both approaches have merits and objectives that you want to preserve. How can we combine the best of both worlds?

The proposed combination is a two-step process. First, use a software selection service to develop your short list of two or three vendors. Then, let the vendors conduct orchestrated demos to ensure that your business critical processes can be accommodated.

The selection service will provide the user with the comfort and confidence that their needs are considered. After going through the function and features checklist and using an automated software tool to match these requirements against vendor capabilities, users should be assured that their needs have been adequately addressed. This does not mean that users have to take the vendors' abilities on blind faith. Hopefully, however, the number of questions and "show me" requests can be limited to a critical few as opposed to an inconsequential many.

With the short list of vendors, you can proceed with a degree of confidence into the vendor demos and presentations. These demos would concentrate on the processes critical to how your company does business and what makes it unique. While users would provide the scenarios and data, vendors "strut their stuff" and prove their statements and claims of functionality. This is not to say that you cannot address other uncertainties within the user community, but this can be kept to a minimum and of course, users will have the opportunity to talk to their counterparts when checking references.

Consultants familiar with the class of software being selected can assist in developing the scenarios. Furthermore, consultants can be useful in organizing and running the demo, allowing your company to devote its full attention to the demo results.

While attempting to combine the best aspects of the two approaches, the third alternative also can assist your company in completing the process effectively while requiring less of your company's time and money. Shown in figure 2 is a comparison of the steps for the third alternative and the more traditional approach. It takes many more steps in the traditional approach to get to the same place in the third alternative, namely the short list of vendors.


Figure 2: Comparison of Approaches

More importantly, in using the traditional approach, it could take more than two months to arrive at the short list of vendors. This assumes that you have everyone's cooperation and their schedules can accommodate the project. Using the third alternative, you could realistically identify the short list of vendors in two weeks, even allowing for some adjustment of priorities.

Summary

Prior to Y2K many software applications had suffered from years of neglect. Software processes had been held together with band-aids patches. Y2K changed this paradigm into a replace, not rewrite, mentality. Accordingly, evaluating and selecting software has become a more common occurrence for IT and user departments. The common focus that both buyers and sellers share in this process, is to do it as confidently and efficiently as possible.

The third alternative for selecting software, as discussed in this article, attempts to provide assurances needed by the buyer and the efficiency desired by the vendor. Use a selection service to quickly arrive at your short list of vendors who can meet the majority of functional requirements of your user departments. Then, let these vendors demonstrate their solutions with your business-critical processes and confirm them through reference checking.

A software selection service can save you time and money. It does not, nor should it, select a vendor at the push of a button. One-on-one time with the vendors is still needed.

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.

 
comments powered by Disqus

Recent Searches
Others A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

©2014 Technology Evaluation Centers Inc. All rights reserved.