Our company runs several islands of software applications. Our incomings are controlled by a set of COBOL programs. Our budget is controlled by Object Pascal applications. Our back-office runs Progress software. Our front-office uses VB + Oracle, and we have a lot of Excel spreadsheets here and there to provide features not covered by any of the previous.

Integration? Kind of. We have some processes in place to transfer data back and forth those software islands, but all of them require a certain level of manual intervention which opens a lot of opportunities for error insertion. Due to data duplication our databases grow like weed over our storage devices and synchronization is always an issue.

As if all that mess was not enough, our back-office package was also not well chosen. Our company focuses services (hospitality) and our back-office package is designed for manufacturing.

Solution? Sure. We could buy a single integrated package having all the features we cover with separated applications. There are several companies out there selling PMS (Property Management Systems), which are comprehensive software solutions especially designed for our kind of business. But how to decide which one best fits our needs? Well, there is a tool that can be used to deliver that answer, and it’s called RFP (or Request For Proposal, for those not familiar with the term).

The basic concept of an RFP is pretty simple: you write a document stating what you need, send it to a list of selected suppliers (which you know provide the product you want), evaluate their replies and make a choice.

But despite of that apparent simplicity, running an effective RFP may be a little tricky and time consuming. First of all you must know exactly what you want. You must be able to communicate well through paper (so to speak) in order to transmit the right message to the suppliers, and you have to know how to evaluate the answers you get. Of course, all of that depends a lot on the type of product or service you are trying to acquire. Here I'll try to show you how I did the RFP for that particular case of choosing a PMS, and why I did it that way.

Structure:

1) Cover Letter: The first part of my RFP consisted of a presentation letter. I wrote about our company's structure, our principles, goals and expectations.

2) Needs Description: The second part of my RFP consisted of a series of processes descriptions. I wrote about the workflow of each of our back-office departments and the things those departments reported as important features to be covered by the PMS product we were looking for.

3) Tech Stuff: The third part of my RFP consisted of a series of questions about the product documentation, tech support, underlying technology and required infrastructure (software and hardware).

4) Supplier's Showcase: The last part of my RFP consisted of a series of questions tailored to enable the suppliers to talk about their company, their size, their experience, their product, cases of success, and other things they could find important to communicate.

Meaning:

First of all, I wanted that each of the selected suppliers had a chance to know who they where dealing with, so the Cover Letter. I wanted to make them understand (or, at least, to have a good idea of) the representativeness of our company before its market. I wanted them to know that we had high level expectations and that we were going to be picky on every criteria of the process they were about to enroll.

With the Needs Description (followed by a question like: "Can this task be accomplished in your product as described here? If not, how do your product handles such task?") I wanted to gather data to measure the number of features we could count on and the number of customizations we would have to consider by making the choice for that particular product.

The same concept goes with the Tech Stuff. By gathering information about the product requirements I would be able to set up some metrics and check them against our current hardware + software infrastructure, so having a good idea of how many configuration changes we would have to perform in order to create an environment able to support it. Also, by asking about the product documentation, training programs, and tech support, I would be able to know how much dependency we would have on the supplier when trying to solve minor problems.

The last part, the Supplier's Showcase, was intended to give the competitors a chance to stand before the competition (which they actually didn't know much about; at least, not from us). Here I wanted to be surprised. I wanted to see them showing off. I wanted to hear from their mouth (so to speak) that they were up to the challenge.

Analysis:

I started my procurement process with six potential suppliers. One of them declined right after reading the RFP (because of a huge lack of back-office features on their product, I guess). The other were analysed based on the following key criteria: percent of needs totally covered, partially covered, not present; training programs and consulting services;  service level agreements, access channels and availability of tech support; software licensing, maintenance and upgrade policies; documentation, help system, web forums and user groups; underlying, embedded or implied technology; company size, representativeness, location (plants, offices or affiliates) and current clients.

Of course, each of those criteria had a reason, a meaning, and a weight. Over them I've also applied other two subjective criteria: understanding of the document (correct interpretation of our needs and questions), and quality of the answers.

Points were assigned to each answer, multiplied by the weight of the item, and then summed up to give an overall score. Based on that we selected three suppliers and asked them to send us a cost sheet (considering the project size and including the hour values for training, support, consulting, customization, and so on) over which we've made a ROI evaluation of each proposal.

After that, we already had a winner, but the process was not yet done. We contacted other companies that we knew were using the product and asked them for references. We selected one of those clients, the one having a structure similar to ours, and arranged a meeting with them so our managers could ask some questions about their satisfaction with the product (that one was kind of tough to set up), and only then we wrote our final report (about 50 pages long) and sent it to our board.

Result? Success! The board loved it and we're about to start the product implementation (January 2010). If you have read some of posts on the blog section of this site you may suspect already that this one was the first RFP ever done at the company. Yeap. That's true. But now it became a standard, at least for the IT department, and a model to be followed by others. This is so true that we're actually performing another one, this time for an Electronic Document Management System (EDMS).

Key Benefits of the RFP:

• It documents the procurement process pretty well;
• It gives you piles of data to work with;
• It leaves the theatrical side of a live presentation out of the equation;