Search Content

WhitePapers


Sales Force Automation Comparison Guide

Businesses of all sizes can benefit by automating all aspects of their sales processes with an SFA (Sales Force Automation) solution. But due to the sheer number of features that most SFA solutions...Read More


How to Buy a Phone System

Considering a new phone system for your business? The Phone System Buyer's Guide from VoIP-News provides you with all of the information you need to make a more informed decision. The Guide helps you...Read More


Oracle Magazine

Oracle Magazine contains technology strategy articles, sample code, tips, Oracle and partner news, how to articles for developers and DBAs, and more. Oracle (NASDAQ: ORCL) is the world's largest...Read More


Which CMS Is Right For Me?

If you're wondering which CMS is the right one for your organization, this comprehensive guide will take you through the various options available, detailing the pros and cons of each. Download...Read More




View All Whitepapers

Why conventional CRM requirements gathering is flawed...

The conventional wisdom has it that that CRM requirements gathering consists of assimilating lists of functional requirements and then prioritizing and ranking them. On the surface this all seems very logical, but in practical terms it doesnt work. Since this is the approach that most organizations take, I thought Id take a few posts to explain why this approach is fundamentally flawed, and to outline a significantly better alternative. Before I get too far into solutions Id like to use this post to illustrate the sorts of things that happen when people adopt the functionality first approach and it goes something like this:


ABC Widgets Ltd decides a CRM system is a very good idea. Bob in IT is given the task of visiting users to discuss what they might require from the system. Over the course of a few weeks Bobs builds up a surprisingly short list of functional needs. Unfortunately most of the interviewees have not used CRM technology previously, and arent able to provide much in the way of feedback. Bob conducts some research on the internet and finds half a dozen potential CRM suppliers and invites them to review the requirements and provide a pricing proposal based on their offerings.

The proposals that are received all seem to meet the published requirements, but come in at a wide range of price points. ABC invites three of the vendors to come and demonstrate their products to the project team. One of the vendors stands out; the salesperson is smartly dressed, professional, and the team really take a shine to her. Their proposal is also one of the cheapest and ticks all the boxes on the required list of functionality. The order is placed and the implementation begins.

The chosen vendor embarks on some initial scoping work. After a few weeks the vendor reports back that the requirement is actually significantly more involved than they had understood from the requirements. ABC are far from happy with the extra costs, and consider their options carefully, but conclude as theyve already paid for the software and the initial scoping, they dont have much choice but to carry on.

A month or two passes, and it becomes clear that things arent going to plan. Several new requirements have arisen as staff become exposed to the technology and start to realize the potential of it. Theres also a problem with the security functionality on the selected product. The security requirements were not defined in the original specification list, and its clear the out of the box functionality exposes ABC to too much risk. To bypass this ABC have to authorize custom development work to add new security capabilities.

The implementation work being undertaken by the vendor is now way outside the original proposal figure and the project appears out of control. The ABC Managing Director, now somewhat alarmed at the spiraling costs, finds herself increasingly involved in the project and has a series of crisis calls with the MD of the CRM vendor. Under the threat of the technology being thrown out the CRM vendor agrees to cap the price of further development work. The CRM vendor mitigates the risk of having to perform substantial free of charge work, by dumbing-down the requirement, so that, while broadly meeting the specification, many of the functions require more mouse clicks than was originally envisaged, and are far from intuitive.

The project is now very late. The XZY MD had promised the system would be live months ago. In order to try and get things back on track she orders the project team to cut back the user acceptance testing phase, and begin user training. Unfortunately, in a bid to reduce costs, the CRM vendor has also cut back on its in-house testing programme. There are a consequently a lot of bugs in the system and these are not even close to being resolved when user training begins.

The users exposed to a system that plainly isnt working immediately lose interest in the new system. Its several months before all the bugs are ironed out, and by the time the system goes properly live most users have long forgotten the original training. Six months on, few people are using the system, and its unclear what value the system has added. The company asks Bob to leave, and the MD is having huge difficulty getting the board to sanction a major investment in e-commerce technology that the company desperately needs to remain competitive. The failed project has plainly damaged staff morale and there has been higher staff turnover than normal, including a couple of the companys star salespeople

Anyway you get the picture. While this may all seem like a rather far fetched perfect storm, the story is based on real world events that I see played out every day. Most CRM projects suffer some or all of the issues highlighted in my fictional story. Much of the fault lies is in the functionality led approach to requirements gathering. Ill explain why in the next post.


Related Salesforce Mobile Articles

Kickering Myself


When I first started at Adaptive Path, one of the many striking things about how different Adaptive Path is from most other companies was explained to me by then-CEO Janice Fraser. When we set up Adaptive Path, she said, We wanted the company and...

Read more about Kickering Myself...

Preparation is the key


Preparation is the key to a successful employee performance review. Reviews are not something you can just pop into and "winging it" if you want to get the best results from the...

Read more about Preparation is the key...