Case in Point

A query request from the marketing department required several complex SQL joins (see Chapter 5 for the definition of SQL and join). Marketing asked for a list of customers who had purchased product A within the last two years, but had never purchased product B. My developer ran the query and sent the list of selected customers directly to the requester. The requester called me almost immediately and said, “There are too many names on this list!” After discussing how she knew that the list was too long, we determined a criterion that had not been included in the original request. “Of course I only want customers who are in the United States!” indicated to me that the requester had made an assumption that the developer had not.

Projects to Align Business Processes

Commercial off-the-shelf (COTS) software packages are used by many organizations to support business activities which are well defined and standardized. Rarely will you find a company developing its own accounts payable or receivable system. It would be a waste of corporate resources to “recreate the wheel” for these types of applications. These applications are well understood and performed fairly consistently by organizations in many industries. Other examples of well-defined business activities are human resource management and payroll systems, general ledger and bookkeeping systems, customer relationship management, sales force automation, and contact management. Since these applications are fairly consistent from organization to organization, many vendor packages are available to support this work.

When a project has been initiated to select and implement a COTS solution, your first questions should be: “Is this a well-defined business activity that we perform consistently with industry standards?” “Is there something unique about the way that we perform this work that will make it difficult to find an appropriate solution?” Be sure to think about whether or not this business area represents a competitive advantage to your organization because of the way that it is performed or structured. For areas that are unique and represent a competitive advantage, a COTS solution may not be appropriate.

Most organizations find that COTS solutions require some customization, development of interfaces with other systems, and significant maintenance resources.

COTS solution selection is analysis work that is similar to the analysis work performed on a software development project, but it differs in that the focus is on finding a solution that most closely fits the organization needs rather than designing an application that supports the business exactly. No COTS solution will fit perfectly into your organization. You are searching for the “best fit.” There are three common techniques or requests used to aid in the selection process: Request for Information, Request for Quotation, and Request for Proposal. These requests are prepared by the organization interested in purchasing or licensing a COTS system. They are sent to vendors that offer systems in the application area needed. Each request is a formal petition asking vendors to respond.

These formal requests are used to make sure that all vendors are given an equal opportunity in the bidding process. This procurement process of sending a formal request and receiving formal replies was first used by U.S. government agencies and private companies that were concerned about employees showing favoritism to a particular vendor and wanted to have a well-documented explanation and justification for the selection process. It is not uncommon for vendors that are not selected to question the fairness of the selection, raising questions about discrimination. To avoid these accusations and possible legal action, most large organizations follow a structured process and have rules that strive to make the process as objective as possible (e.g., employees are not allowed to accept gifts from vendors over a small dollar amount, employees are not allowed to talk with vendors during the proposal process, and all vendor inquires and answers are written and published to other vendors).

A Request for Information (RFI) is a brief document that outlines the business problem or opportunity that a company is trying to solve and asks vendors to provide initial, general information about product offerings. Vendors typically respond by sending brochures, catalogs, and product descriptions. The RFI may be sent to many vendors, giving as many as possible a chance to participate in the bidding process. Often, some vendors will choose not to reply because their products do not meet the need or they do not think that they can support the customer on an ongoing basis.

The second type of request is a Request for Quotation (RFQ). This is a brief document asking vendors to provide a formal price quotation. This request is rarely used for COTS purchases and was created for bids on products that are standard from one vendor to another (i.e., equipment, supplies).

The third and most frequently used type of request is the Request of Proposal (RFP). This is usually a longer document that describes, in detail, the needs of the company. It asks vendors to specifically describe how their product will match the needs of the organization. An RFP is effectively a requirements package (see Chapter 7) that describes the needs of the business area. Creating an RFP and reviewing vendor responses for COTS systems are primarily business analysis work. An RFP may also contain requirements related to the contract (written by the legal department) or the procurement process (written by procurement), but typically a BA or PM is responsible for writing and assembling an RFP. An RFP includes a request for pricing of the system along with support costs. Support costs may include items like customization of features, training for software users, consulting on implementation/rollout plans, development of interfaces to other applications, ongoing maintenance changes, etc. An RFQ and its replies are used to formally compare the costs of various solution options and are used when contracts are developed between a vendor and a company.