Why conventional CRM requirements gathering is fundamentally 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 doesn’t work. Since this is the approach that most organizations take, I thought I’d 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 I’d 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 aren’t 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 they’ve already paid for the software and the initial scoping, they don’t have much choice but to carry on.
A month or two passes, and it becomes clear that things aren’t going to plan. Several new requirements have arisen as staff become exposed to the technology and start to realize the potential of it. There’s also a problem with the security functionality on the selected product. The security requirements were not defined in the original specification list, and it’s 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 isn’t working immediately lose interest in the new system. It’s 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 it’s 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 company’s 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. I’ll explain why in the next post.
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 aren’t 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 they’ve already paid for the software and the initial scoping, they don’t have much choice but to carry on.
A month or two passes, and it becomes clear that things aren’t going to plan. Several new requirements have arisen as staff become exposed to the technology and start to realize the potential of it. There’s also a problem with the security functionality on the selected product. The security requirements were not defined in the original specification list, and it’s 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 isn’t working immediately lose interest in the new system. It’s 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 it’s 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 company’s 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. I’ll explain why in the next post.
posted by Richard Boardman at 12:07 pm
<< Home