3 lessons when buying software

"The likelihood of failure is proportionate with the amount of customization."

— My Boss, 2001

We were talking about a CRM implementation for the company, we were months past schedule, millions over budget, and the eventual roll-out was a disaster

There were 3 goals:

1. Have a single, centralized source of truth for all customer data

2. Give our contact center agents a single system to work out of (no more "swivel chair" issues)

3. Modernize on a Java stack, unifying all development languages moving forward

The vendor had lots of experience in the space with some other great tools we wanted to run, but they didn't have a CRM

So they went out and bought one

But it was a .NET platform, so they started a port, and then promised a timeline

The company had purchased vaporware

A promise that this CRM would do what we needed

And a promise that it would be ready in time for us

Lesson #1 - don't buy vaporware, buy what exists today not a vision for tomorrow

When the CRM went live productivity crashed

Nobody could figure out what was wrong - obviously there was an issue with the servers/network

My team didn't sleep for days digging through every database, application server, web server, network switch, load balancer, firewall, etc... looking for clues

We couldn't find anything wrong, performance was fine, load was low, there wasn't an issue to be found

The company hired an expensive consultant to help us

First thing she did was interview everyone: executives, developers, dbas, system engineers, call center supervisors and agents

After about a week she delivered a report with her findings

Turns out at no point during the development did anyone think to include the actual users of the systems being replaced to design the new one

Things that could be done in a single screen now took multi-page forms

Forced validation of data that wasn't necessary required garbage entries before advancing

It was like reading a horror story

Lesson #2 - start with your users, then your processes when looking at tools

We ended up going back to the old systems for a few more weeks while the workflows were redesigned and updated

The 2nd launch wasn't great, but it wasn't a disaster so it stayed in place

This was all done for "modernization" and standardizing onto a single language Java

Why was this important? Because it's what the CTO and CIO sold the Board when they were hired

Successfully rolling out Java based platforms became key components to their MBO and bonuses - it didn't matter if it was right or not, it was the decision

"Show me the incentive and I'll show you the outcome"

— Charlie Munger

Lesson #3 - Is it right for the company, or right for the people? Have you aligned both in your planning?

This happened 21 years ago and I still think about it

Why?

Because I still see it happening every day

Before you jump to a new system because it's popular, trendy, or makes a promise stop and think about your users and your processes - does the new system align?

Before you start customizing, go back to your processes - it's easier to change yourself than the tool