Proposing The Best Solution

Tom Olivieri worked as a systems analyst in the banking industry for 13 years. During that time, he participated on many project teams that were assembled each time his bank planned to add a new computerized system. The ultimate goal of the team was always the same. The team had to produce a document that could be sent to potential solution providers (VARs, systems integrators, vendors, distributors). This is a document detailing what the bank expected from the new system and technology requirements involved in the solution. This document, or request for proposal (RFP), invited solution providers to submit bids for the project.

"In the banking industry, we felt a good RFP was a document that looked substantial when we dropped it on the boss' desk. We called this satisfying the 'plop test,'" states Olivieri. "However, thicker isn't necessarily better. You don't want to create a document that no one wants to read."

Olivieri left banking in 1993 and is now partner/managing director of Micro Network Systems (MNS). His company is located in Brentwood, NY, and recorded $1.5 million in gross sales in 1997. As a document imaging integrator, he now has to read the same type of RFPs he used to submit. Having been on both sides of the RFP, Olivieri recognizes a common problem project teams have. While teams may not be aware of it, RFPs are usually too long.

Creating an effective RFP is not a singular event in and of itself. Writing an RFP is the culmination of planning and researching by a company's project team. The process leading up to the actual writing of the RFP usually will dictate how good the document will ultimately be.

Does Your Project Require An RFP?
Not all new system purchases require an RFP. Whether an RFP is required is not always a factor of the size or scope of the project. If a new system will affect multiple departments within an organization, an RFP is probably necessary. Also, a company that develops an RFP is making a statement about itself, according to John O'Malley of Barcoded Management Systems (BMS).

"A company with a solid RFP is saying to the VAR, 'we are organized and serious about implementing a new system,'" states O'Malley, director of national accounts at BMS. His Dayton, OH-based company provides automatic identification and data collection (AIDC) technology and posted $5 million in gross sales in 1997. "An RFP demonstrates that a company is not just 'kicking tires.' It tells the VAR that there is probably money put aside for a new system."

James Coffelt notes that implementing a new computerized system in a POS environment does not always require writing a formal RFP. He is president of Business Data Systems (Akron, OH) which sells POS technology to restaurants and recorded $4 million in gross sales in 1997. He says that in his market, more than any other, RFPs are not necessarily expected of the end user. "Most VARs in the hospitality POS industry deal with independent restaurateurs. These end users rely on the VAR for recommendations and advice. Bigger chain restaurants will submit an RFP, but there are only a handful of chains compared to the large number of independent restaurateurs," explains Coffelt.

Employees Aid In Assessing The Current System
Typically, a project team is charged with identifying the shortcomings of a company's current system or business process. Rarely does one member of the team have intimate knowledge of every aspect of a company's business process. "A team should have members of the information technology (IT) staff, but also department employees who actually use the current system or would be affected by a new system. Many times the users have no input in the decision process and this is a critical mistake," says Olivieri.

Including input from system users is important in every market, says O'Malley of BMS. This was the case with an installation of AIDC technology in a warehouse. A supervisor from each department was placed on the project team. The team realized it did not know exactly how inventory was moved in the warehouse, so the team called in one of the forklift operators. "The company has to make time for an employee to attend the meeting. This is not always easy, but it is worth it," remarks O'Malley. The forklift operator told the team where bar code labels were located on inventory and how the labels were scanned. Moving the labels to accommodate a new system might make it impossible to scan the labels from the forklift - something the team did not consider.

For document imaging technology, Olivieri recommends talking to the employees who scan and index documents. In the POS marketplace, project teams should consider the suggestions from cashiers and servers.

Setting Goals For A New System
After clearly defining the problems with the current system, the team must decide what a new system needs to accomplish. O'Malley refers to this process as making a "wish list." "Project team members are not familiar with all of the technological terms, so this is a logical list of project goals in layman's terms," states O'Malley. "You want to include every concept you can think of, from user friendliness to connectivity issues. You can always go back and eliminate items later on." The wish list should also contain specific business processes that a company wants to employ. In a warehouse, that might be the ability to scan bar codes on items that are stacked two-pallets high. A restaurant end user may want employees to enter data through a touch screen at a POS terminal. After documents have been imaged, a document imaging end user may want the images stored on a jukebox and accessible over a network.

Get Help From A Solution Provider Or Consultant
When the wish list is done, this information needs to be refined before it can be included in an RFP. The project team needs to have outside input at this point to determine what technology is available and what it can accomplish. Consultants or solution providers can provide this information to the end user.

• Consultants - James Coffelt of Business Data Systems recently received an RFP from an end user that was developed by a consultant. He says the consultant specializes in the restaurant POS industry and knows the availability of technology for this market. After interviewing the end user, the consultant referred to his own database which contained all of the possible system features pertinent to the POS industry.

  "During the interview, the consultant ran through a list of all possible features and asked the end user which ones are important," states Coffelt. "The consultant then took this information and tailored a 40-page RFP which was sent to my company." The result was a very detailed RFP, but one that Coffelt believed was more lengthy than some competent providers would respond to. He says it took about 40 hours to respond to the RFP, which should be a concern to the end user. Many solution providers will not look at a document of this size, according to Coffelt.
  
  

• Solution Providers - "Make the solution providers do some work for you. Make them come in and put on their 'dog-and-pony show' (demonstration)," states Olivieri of MNS. "I do it everyday; it is part of my job." He suggests end users consult at least three providers and as many as six if necessary. The number may differ depending on the scope of the project and the number of providers near the company's location.

This is a good time for the end user to run through the wish list and determine what is feasible. For example, an end user may want to eliminate a manual time and attendance process. Automation might require the installation of a biometric time and attendance device, such as a fingerprint identification system. If every provider says this goal is possible, then this should be written into the RFP. Conversely, an end user should delete a wish list item if most solution providers say that the technology does not exist to accomplish it.

End users should also be asking for pricing estimates when meeting with solution providers. This is critical, because it may determine whether a project is financially possible. It can also help an end user choose a provider that is in its price range. "VARs should be able to give you a ballpark cost of the project. This is really a 'gut check' for the end user to see if the project will move forward," states John O'Malley of BMS. "If you are planning to spend $50,000 on a new system and five VARs price the system between $150,000 and $200,000, you are going to have some decisions to make. Either scale back what you want to be included in the system or reevaluate the project entirely."

Locating The Right Solution Provider
The obvious place to look for potential solution providers to help an end user with a solution is in trade magazines. End users should locate vendors in the magazines which sell the technology they are searching for. The vendor will then contact the end user directly or relay the information to VARs and systems integrators who can educate an end user.

Beyond trade publications, Olivieri of MNS says the Internet is another place for end users to locate potential solution providers. Most VARs have Web pages with information on products they carry and details of past installations. Web sites are also a good resource because end users do not have to talk to salespeople. Personal contact is initiated by the end user.

While the Internet can be a valuable search tool for the end user, Olivieri advises that end users should use due diligence. "You need to be careful using the Web. If an integrator is not on the first page of the search results, that does not mean the integrator is less qualified. End users should perform several searches, using multiple keywords for each," says Olivieri. For example, using the keywords "document imaging" may result in 40 pages worth of hits. End users should use keywords that are specific to the installation they are implementing. For example, end users might try using the keywords "document imaging for insurance forms processing."

Include Pertinent Information
RFPs will naturally be longer for larger projects, but all RFPs should contain much of the same information. End users need to include the software and hardware requirements of the new system and a list of system features. Technical support and customer service expectations should be included. An RFP will also address the life cycle costs of the system. This includes areas such as scheduled maintenance, software upgrades, and replacement parts.

Olivieri of MNS recommends that RFPs include a clear definition of the problems that exist with a current system. End users must then outline the goals of a new system. "The RFP should contain a consensus of information from the technical staff to the employees that will be affected by the system," says Olivieri.

The majority of an RFP should be dedicated to software issues, according to John O'Malley of BMS. "An end user will want to make sure that a new system is compatible with current system programs," says O'Malley. In the AIDC industry, he says end users should use the rule of 80-20. This means that 80% of the software for a new system is "off-the-shelf," while 20% will require custom integration.

Keep An RFP Concise
Finally, it is time to write an RFP. The challenge is to create a document that can be easily viewed by a VAR and still be thorough, according to James Coffelt of Business Data Systems. Qualified solution providers may not respond to RFPs that look daunting. Coffelt says that smaller VARs may be able to provide the best solution, but they are often scared away by RFPs that are too lengthy.

According to O'Malley, end users who do not write RFPs are not saving time. "If you write an RFP, you spend a great deal of time evaluating your options up front and then arrive at a solution. If you don't write an RFP, you will have to evaluate all of the vendor options at some point in the future," states O'Malley. The worst situation is making a hasty decision based on a bad RFP or none at all. You might have to live with a system problem for a long time."