Key issues in CRM software failures

I attended a town hall meeting today on IT failures specifically targeting CRM. The key items mentioned about the failures all related to not It and non-software issues. Some of the key items that I took away included:

• Software comes with the vendors version of best practices. This may not be your company's view of best practices. Converting to their best practice could hurt your results.
• For CRM in particular, attempting to get information on what your best salespeople do is a problem. If you ask them what they do, so that you can copy it, then watch them, you will find that they don't practice what they say. This is true of other professions, but it may not have the same impact. Most of what people do is done subconsciously. That's why what they say and what they do is different.
• Many IT projects fail because they try to do too many things for too many people. This increases complexity and increases opportunity for failure.
• Because of the defined complexity, the application becomes difficult to navigate and decreases productivity and sales. It's better to make it simple.
• There is too much emphasis on training vs. education. Training tells you how to do it. Education helps you understand why you should do it and how that will help to improve performance. There was another question related to how much training should be provided vs. making the software intuitive. Would anybody play games if they required you to attend a full day training session?

Those were my key takeaways. You can check for more on Twitter at #ITfail.

Software Procrastination

Procrastination is something we all fall into, at least from time to time. Why do we procrastinate? Does it matter?

A recent experience with a client provided me with answers to these questions.

The client was a small organization that had acquired software from a related organization many years ago. They didn't have a lot of sophisticated needs, so they stayed with it. Over time the related organization replaced the software, but still had one person on staff with the experience to support it.

Problems developed on a regular basis. Some of them were described as quirks that required a person who had experienced all of the quirks to prevent them. Support was expensive. They had to fly someone in from the US to fix problems.

They knew that they needed to replace the software, but had no one on staff with experience and didn't know what they needed to do. They researched alternatives, but that only served to confuse them. They continued to defer.

Finally, a few months ago, they had a major problem. While one of their staff was on vacation, they encountered one of the quirks. It caused a major problem that required 3 months worth of cleanup at year end to recover.

That created the incentive to take action. In one planning session, we were able to develop a high level plan, provide a basis for justifying replacement, and give them some level of comfort about moving forward.

That raised a few questions for me:

• Why do we procrastinate? Is it because we don't know what to do next?
• How much time are we wasting when we procrastinate? We think about it often, but unless we are taking action, the thinking is wasted and stressful.
• Why does reseach not help? If we know nothing about a specific area, do we actually waste time by doing research?
• Why are we afraid to ask for help from a specialist? Is it because we need to feel in control and are afraid of it costing too much money? Perhaps spending a little with a specialist who helps us plan, without requiring a long term commitment from us would provide value.
• Are the specialists the problem? Do they expect a long term commitment and are they not willing to help put us in control?

All I know is that a lot of time (and time is money) is wasted in procrastination. I, for one, will have to look at my own procrastination differently in future.