There is no shame in that statement--at least there shouldn't be. We all have to learn new things at one time or another. But the appropriate time is not in the middle of a procurement that will change the infrastructure of the enterprise and the day-to-day lives of your customers.

We congratulate ourselves at how low prices for hardware and software have fallen, while we overlook the fact that vendors can no longer cater to every whim. Every vendor, no matter how large or small, needs a business scenario that makes economic sense when doing anything for a cust omer--no matter how much potential for future business exists out there. Most salespeople will promise you that they can bring unlimited resources to the table at a moments' notice, but the proof is in the results, not the promise.

If a vendor doesn't have a clear working relationship with you, along with a good grip on the problem at hand, and a belief that it has better-than-even-odds at winning your business, chances are you're going to get an RFP full of boilerplate and sales fluff. Is this because the vendor is stupid and lacks the vision to see how wonderful it would be to sell you something? No. It's because the sales team can't convince management that your project is worth the time. You'll get an answer to your RFP, but it'll be off the mark, and if you're using the RFP as a way to get smart, you won't even realize it.

Example Two: Unrealistic Expectations for Remote Users On a separate but equally frustrating note, it's unrealistic to insist that every disconnected laptop out there ha ve complete off-line functionality. It's fine for Microsoft and Lotus to build replication into every little part of every application--they can afford it. But some folks believe that developing replicated applications (moving data down to the desktop) is something you get for nothing as long as you have the right middleware.

For the average or above-average front-office application, replicating is a big pain and costs more than it's worth--despite what you hear from the folks behind the Jet database engine, Oracle Lite and SQL Anywhere. Users simply will not use it. When given the alternative between dialing-in to get 100 percent accurate and timely data versus working off-line, they'll choose to connect every time.

"But what if I'm in front of a customer?" you hear salespeople say. "I can't dial into our network if I'm in a meeting at a customer's site." Hell, I can't even tie my shoes in front of a customer, let alone play around with an application. I don't think that there are that many people who will actually be able to use applications, other than presentation software, in a meeting situation.

Crunching numbers and checking an order's status are done during a working session, not during valuable face-to-face time with the customer. When it's just you and your laptop, there's plenty of time to connect, fire up the application or the browser and get to work. The alternative is to build transaction queues, duplicate schemas of data, replication and message enabling. If you think this seems like a lot to go out on every laptop with an already-bloated client, you're right.

Sure, there are middleware pieces to make replication easy and transparent, but it seems transparent to everyone except the user, the poor programmer who had to code it and the network manager who won't hear about it until it starts to drive up the need for bandwidth. You have more dependency on dial-up--so what?

Reasonable Expectations, Not Pipe Dreams What are the answers? Invest the time in writing the RFP and ins tead of describing the problem, describe the solution you need. Do the requirements analysis, market review and possibly a prototype before the RFP. Sure, it's a lot tougher, and on top of that, you'll disqualify or terminally annoy a few vendors that won't even participate. However, management at the remaining vendors will commit to the process because they'll see a viable chance at winning the business. And if they can win the business, they'll dedicate resources to creating a superior RFP.

Corporate IS has spent the past decade concentrating on the production side of the business. Now corporations are concentrating on developing customer assets. This is what motivated us to move beyond the infrastructure with the RFP and instead target the front office. While sales and marketing support is nothing new, sales productivity has become a favorite target application for intranets. These remote road warriors are laptop retentive, loathing the effort to get online and fearing lack of information at a critical moment--they want everything maintained on their laptop at all times. They also are experts in pitching compelling arguments as to why they always need it all. Don't fall for it. The traditional browser-server link is just fine. Reliance on dial-up is not your problem. Dial-up works. However, your replicated application may not work and the local phone companies have plenty of cash to buy new switches. In the end, it beats maintaining modem banks in your site. User connections and support are the Internet service provider's problem anyway.

But all of this is moot since I just know you've already effectively outsourced all of your dial-up to that great virtual cloud called the Internet, right?

Brian Walsh is the founder of bwalsh.com, a networking technology consulting firm in Portland, Ore., specializing in Internet and client/server product strategies, development and testing. He can be reached at bwalsh.com.