Software for Business: When Not to Buy

There are some things we all wish we had never purchased. That Yugo. The HD DVD player. That house in Florida.

I'm also betting that Joe, a client of mine, will one day wish he never bought the software I just sold him.

True story: Earlier this month we sold one of our customer relationship management (CRM) applications to someone I'll call Joe, who owns a 20-person company that makes specialty equipment parts.

Joe's software purchase will cost him about $10,000. He'll probably spend another $5,000-$10,000 with my firm for services, including installation, training, and making sure it works with his existing systems. That's a lot of money for a small business owner. But Joe's convinced it'll be a good investment.

I've been around long enough to know two things for certain: Paris Hilton's My New BFF will never win an Emmy. And Joe's new CRM system will fail miserably.

Joe bought the software for all the right reasons. He wants to track customer data and activity. He wants to make sure leads are followed up. He wants to have ongoing marketing campaigns to generate more work both from customers and prospects. But he's also got all the wrong things in place. His is destined to join the ranks of the nearly 30% of companies that, according to AMR Research, fail at CRM implementation. Vendors of CRM software, including (CRM), Oracle (ORCL), and SAP (SAP), might want to take note.

companies need a "super user"

Joe's company, for instance, doesn't have the right people in place. Specifically, he doesn't have that individual who should be responsible for the system's success. I've written about this person before: the super user, the sponsor, the project manager, the administrator, the champion. Joe hasn't budgeted for the fact that one unlucky person in his company needs to be told to "own" the system. Without someone who's ultimately responsible, then the minute something goes wrong everyone will be pointing fingers at each other (and at my firm).

And because of this, Joe's significantly underestimating his budget. He thinks that just buying the software and getting some training is all he needs. In reality he should be allowing for time spent by someone as the main person in charge of the system. That person may be spending two or three days a week getting up to speed, and then maybe another half a day a week doing ongoing work on the system. Without that person in place, Joe's going to fail. Like Jon and Kate. Only instead of the screaming kids there'll be screaming employees. Same thing.

You may be wondering why I don't try to stop Joe from this ill-conceived purchase. Believe me, I have. I've been repeating this speech to him over and over. It's even in our contracts. But busy business owners like Joe only seem to hear what they want to hear. And though I'm doubtful he's going to succeed, I still plunge forward. Like the sales rep who sells that piece of equipment to the customer knowing that he'll probably never use it. The difference between him and me? I'm so bad at figuring people out that Joe may just surprise me and get a lot of benefit from the software!

make sure hardware is up to speed

But it's not likely. Joe's just not selfish enough. His employees sometimes dominate his decision-making. He wants to make everyone happy. That may be fine if you're the President and you're creating a trillion dollar health-care plan. But not when you're purchasing a critical business application. Sure, getting input from users is important. But after getting feedback he then needs to choose what's important ultimately for the business. He then should politely tell [employees] to put their heads down, learn what they need to do to get data in the system, and keep their little pet peeves to themselves. My clients who get the most out of the technology they buy do so because they—not their employees—dictate what they need from their systems to run their businesses.

Joe is also putting too much stock in his machines' ability to run the software. He actually believes the software manufacturer's "minimum hardware requirements," such as how much hard drive space, memory capacity, and processor speed their computers should have. This is like believing there's nutritional value in a bottle of Propel water, or that baked chips actually taste as good as regular chips.

There's a difference between the software working on a server and the software working fast on a server. Software vendors keep these minimum requirements insanely low so they can reduce any potential barriers to purchase. But we all know that to really get the most productivity out of a software application you need to be running it on the fastest, most recent hardware available.

Joe doesn't have that. He's got computers dating back to the Bush era—the first Bush era. He has no internal computer guy. He's running outdated versions of Microsoft (MSFT) Windows, both on his server and workstations. Joe's looking at a potential mess the moment the software gets installed. There'll be compatibility issues, performance issues, database issues. And he'll try to fix them with Band-Aids. Until he ultimately throws up his hands and replaces his existing hardware.

Another thing: Joe and I never agreed on specific milestones that need to be reached in order for Joe to deem his project completed and successful.

He's got some idea in his mind what this system will do for him but we haven't actually discussed this—much less come to terms for it. I'm going to go off on a limb here and predict that what we ultimately deliver will differ as much from what he's expecting as The Godfather: Part III differed from the previous two Godfathers. Yes, that bad.

Sadly, Joe's project is going to fail. Miserably. He should be holding off on this software purchase. He's really not ready. But he's determined to do it. And I'm going to try and help him.

Before it's here, it's on the Bloomberg Terminal.