Debunking club technology myths.

There are numerous myths that continue to linger around the effective selection and implementation of club technology. Some date back to the earliest days of club computer applications. Others were perpetuated by ill-qualified vendors seeking to make a fast buck at clubs' expense. But others, unfortunately, have arisen from a failure by club management to participate in the technology selection process. Too often, club managers are content to delegate automation decisions to the controller, accounting manager, or member services director.

Based on two decades of field study, six common club technology myths are exposed in this article and the truth behind each unknown is clarified. In addition, a comment about "best practice" is mentioned and a long-standing technology adage is added to counter each myth of automation.

Myth One: Procure Hardware Before Application Software

Assumption: Securing the hardware components of a system as a first step will assist the club by simplifying architectural, electrical, network, and related installation expenditures, thereby enabling more precise project cost estimations. Securing system hardware first also helps generate staff excitement and contributes to member interest.

Truth: Procuring system hardware before application software is a sure-fire path to disaster. It is difficult to search for preferred software after system components have been specified. In fact, club managers tend to complain more about seeking compatible software for installed hardware than nearly any other club technology problem. Inevitably, questions will surface relative to hardware support and/or operating system compatibility with application software. Club management must exercise care in this area and always shop for software first; hardware second.

This situation is likely to arise when searching for a new club system, but more often than not is encountered when management personnel change and the new staff desires to update club software without having to replace existing hardware. Imagine if you had hung on to your eight-track tape deck and turntable from the '70s and then wondered why all you could find recordings on were (incompatible) CDs. The same scenario is true when trying to run a Windows NT application on an antiquated PC platform.

Best Practice: Best practice dictates identifying application software first and compatible hardware second. As mentioned, a similar situation may arise when management strives to replace the currently installed club software system only to discover that later versions of the software are not compatible with the old hardware platform. At this point management has to consider the replacement of installed hardware. Such a search can be pain-staking and non-productive.

Myth Two: Rely on Low-Cost Criteria for System Selection

Assumption: Club system vendor representatives are compensated on a paid commission-basis and therefore will seek to oversell system components and features that may not be necessary. The belief being that in an effort to increase their own earnings, vendor salespersons are highly likely to propose more hardware components, software modules, and peripheral devices than the club really needs.

Truth: More often than not, club technology tends to be undersold, not oversold. When a system is undersold (i.e. fewer than necessary components, programs, or services are included) its bidding price will be comparatively lower, and hence the vendor may enjoy a competitive advantage when club management reviews system price quotes. While on the surface this may not appear to be a smart approach to system design, consider that once a system is installed, it is more logical to add-on to it than to remove the system. In other words, a low-bidding vendor is confident once the club selects and installs the undersold system that the club is not likely to displace the system when it eventually becomes obvious additional wares are appropriate.

Best Practice: Best practice dictates using a request for proposal (RFP) approach to the technology marketplace. An RFP requires that the club describe its operational processes, automation needs, and various parameters (number of members, transactions, employees, workstation locations, etc.) so that a qualified vendor can propose a solution to the club's information technology requirements. Through development of the RFP document, the club typically performs a self-assessment aimed at communicating comprehensive knowledge of club operations.

Through the RFP document, vendors are given specific instructions of response to guarantee that required functions are properly addressed and that costs of each are itemized. Club managers need to be familiar with the RFP process and inform candidate vendors that responses will be connected to an eventual system contract. In other words, whatever stipulations the vendor includes in response to the RFP, those stipulations will become part of the club's system contract. This procedure encourages vendor representatives to propose realistic, functional system designs while discouraging artificial underselling.

Myth Three: Trust The Vendor to Manage the Purchase Process

Assumption: Since club system vendors are more experienced with technology than the average club manager, it is best to select a vendor that can help guide the purchase process; the vendor will be expected to keep management informed as the process progresses and to develop a sound implementation plan.

Truth: Management needs to actively participate and control the purchase process. If the process is not controlled, then it should be considered out of control. While vendors can be excellent partners in technology implementation, the goals of the club and system provider tend to be different. When management delegates and/or loses control, many wasted hours and unnatural delays in system installation, training, and testing are likely to occur. Such results often arise out of confusion and distraction.

One effective technique for controlling the purchase process from the beginning is to adopt a 'scripted demo' approach. The basic concept of scripted demos is for management to provide candidate vendors with a set of specific transactions the potential application (or system) must be used to resolve during vendor demonstration. As the controlled vendor demonstration progresses, the club's management directs the vendor to illustrate the application's handling of the specified transactions. This technique forces the vendor to focus on features that are important to the club, as opposed to the features important to the vendor.

Best Practice: Best practice dictates using a scripted demo approach. During vendor product demonstrations, management must direct and control the sessions. Important points include:

* Require the vendor to use hardware components, application software, and peripheral devices referenced in the proposed system configuration during the product presentation;

* Emphasize to the vendor that the transaction scenarios are to be demonstrated one at a time, in a prescribed sequence (i.e. scenarios should not be modified or rearranged or re-organized in any manner);

* Advise the vendor that each vendor representative should be technically and operationally competent as scenarios will likely be changed on-the-fly during the demonstration session;

* Encourage each vendor to perform a site survey prior to product presentation to ensure familiarity with your club operations, since too often vendors view all clubs as being the same and fail to properly differentiate product presentations;

* Inform vendors that finalists who successfully pass the scripted demonstration stage will be invited back for a second product discussion in which the vendor may demonstrate any additional system features which the scenarios failed to illustrate.

Myth Four: Whatever Features Are Promised Will Be Delivered

Assumption: When an important club system feature is discussed with a vendor representative, that feature will be included in the hardware functionality or application software modules and be readily available for use with promised capabilities. Systems capabilities typically function as described during sales presentation sessions.

Truth: Often some system features that are important to club management (deal makers/deal breakers) somehow do not end up in the acquired product or system. The techno-term for this situation is "vaporware." When it comes time to deliver, the promised functionality has somehow vanished from the system toolbox.

Best Practice: Best practice dictates using a request for proposal (RFP) that forces the vendor to respond to capabilities within deliverable timeframes. The use of the three reply columns ("now," "six months," and "no guarantee") for vendor response for each proposed application software feature is very important.

Technology Adage: An old adage states, "Vaporware is the number one selling system product." Since vendor representatives tend to promise system capabilities before the engineering department has perfected them, club management is wise to force the vendor to qualify an RFP response to a time certain.

Myth Five: Being an Early Adopter Is Advantageous

Assumption: Installing a new product or application can provide cost savings and productivity enhancements, and therefore it is best to be among the first clubs to install the product or application. From a competitive advantage perspective, first appears to be best.

Truth: There are three standard technology rules of thumb: a.) never be the first user of any product or application software; b.) never be the largest user of any product or application; and c.) never be the last user of any product or application. For early adopters there simply is no benchmark upon which to judge an application's capabilities. In addition, as the club's management struggles to effectively direct the club, an unproven application can pose challenges that become dysfunctional to operations.

The reason clubs need to be hesitant when considering becoming the largest system user is due to the fact the club will constantly be testing system boundaries, file sizing, and other parameters of the system. Stretching such capacities can be harmful to the club's data processing should such limits be reached or exceeded and the system ceases to function correctly. It is best to identify an installed system at a club of similar membership size, staff size, and transaction volume than to be the biggest system user.

Best Practice: The club is wise to request a list of installed club users and comparative measurements of its membership, staff, and transaction volumes. Based on such a comparative analysis, an intelligent decision can be made.

Myth Six: Proprietary Systems Are Desirable

When seeking a complete system, several facets of negotiation, contracting, support services, and future developments are minimized when the system supplier is the sole source for hardware, software, firmware, and peripheral devices. Dealing with a single vendor is more advantageous from a system compatibility perspective.

Truth: Clubs should consider avoiding proprietary systems as they create unnatural dependencies between the club's management and the system vendor. By definition, a proprietary system is one where technical specifications of system components and core applications are not divulged. By contrast, an "open" system allows the use of hardware and software components from different vendors. With a proprietary system, the club is obligated to deal with a specific vendor, regardless of how strained the relationship.

Best Practice: Best practice dictates selecting a non-proprietary system. Open system architecture solves many system problems and provides club management with an array of component, software, and peripheral options. "Best-of-breed" is aimed at enabling the club to select and install the most appropriate hardware and software for each individual application area, regardless of source.