The short answer is…nothing.

So, here’s my question back to you. Why do most organizations have more of a methodology for buying their office supplies than they do for procuring business software?…which has a profound impact on their bottom line and ability to compete in the market.

I’ll answer my own question.

The reason is that most companies simply don’t know how to evaluate software…and many don’t want to invest the time and money to learn how to do it.

A not untypical scenario would entail the IT manager being summoned by the president of an organization and told to find a new software package for the company. And that’s what he does; he goes out and finds a package on his own. He puts on a show and uses his dad’s barn. It’s a hasty, quick, impromptu activity that does nothing to move the organization forward. It’s probably not the right vendor or the right functionality—but it is a package. And it is one that most people in his firm have heard of. Low risk for him, and it didn’t take much time or effort to sign the contract with the software vendor.

The problems occur once you start planning the implementation and conversion from your existing systems. Functional items that the IT manager assumed would be in the new package aren’t there because he didn’t ask and he didn’t plan.

Remember the Fram oil filter commercials from the 1970s, “You can pay me now, or you can pay me later”? That logic is the same for software evaluation and implementation. If you don’t do the proper planning, then you may hit a point where you may have to abandon the implementation and revisit the entire software selection effort.

Think about it.

Request for Proposal. Those three words put shivers through the spines of project teams and software vendors across the country. The only thing worse than the three words is the three letters—RFP. They conjure up images of documents the size of phone books that are unanswerable and require an Arnold Schwarzenegger body to carry.

What is an RFP? It is an invitation for providers of a product or service to bid on the right to supply that product or service to the individual or entity that issued the RFP.

Let me let you in on a secret. Do you have to create an RFP? Answer: No.

If you do decide to create an RFP, does it have to be an enormous document? Answer: No.

Are there any definitive rules for creating an RFP (assuming we are working in the private sector and your company does not have established guidelines concerning the use of RFPs)? Answer: No.

Do we need to create a written document that:

1. specifies exactly what we require in a software package?
2. documents for the vendor relevant background information on our organization?
3. asks relevant questions regarding the vendor organization?
4. requests pricing information from the vendor based on our background and requirements?

Answer: You bet!

Can we call this document anything we want? Yep.

My point is obvious. Don’t get caught up in calling it a RFP—and let go of any negative baggage that you may carry with regard to RFPs. What’s important is the document, not what it is called.

Within the real estate industry, where I have done the lion’s share of my work, there is a vendor I have busted twice with this little bit of trickery.

As more and more technology has become Internet based, it is not unusual for software vendor salespersons to request Internet connections to be made available during the demonstrations. This particular vendor made a big deal about having the connection; processing over the Internet was a large consideration for this particular client.

The demonstration started, and very quickly we began to go through the scripts. The software vendor salesperson was talking about the speed of the processing. I looked up at the screen and noticed that the whole demonstration was running on c:\localhost, which for the technically challenged means that the entire demonstration was running locally on the vendor’s laptop. In other words, the entire Internet connection “hook-in” was a sham. I held my tongue to see if the representative would correct his misdirection. He didn’t. He proceeded through the whole day talking about the speed of the vendor’s internet product. When I held the debriefing that night, I asked the team about the Internet speed. They were very impressed. I then asked how many of them knew that the entire demonstration was local, processed on the software vendor salesperson’s laptop. The IT director raised his hand. The other people in the room were shocked—and then they were angry. We had a long discussion about product and company—good product, bad company.

The really interesting turn on this story was that three weeks later I was going through demonstrations with another client with this same vendor. The same thing happened again. It was an entirely different sales team; in fact, these were senior sales people. I held my tongue and then did the same thing at night: revealed what had been done to the project team. Same result, same anger.

All of this was avoidable. All the sales representative had to do was disclose upfront that he was going to do the bulk of the demonstration locally in the interest of speed and timing. That’s what everybody else does. But they were insecure about the functionality of their Internet offering that they misled.