Conventional wisdom on CRM requirements doesn't work
The final major flaw with the functionality led approach to CRM requirements gathering is the Rumsfeldian notion of the unknown unknowns. Users, who invariably haven’t used CRM technology before, are expected to articulate a complete vision of what they want from a system, and invariably are only able to produce a handful of bullet points.
Even those who have been exposed to CRM technology before, generally because the system they used wasn’t well set up, and/or the deterioration of memory over time, and/or their exposure to a limited sub-set of functionality, tend to struggle to produce meaningful requirements.
On the other extreme, this approach does occasionally produce users who can create a very detailed but ultimately Frankenstein-esque vision of a system out of all context with what’s deliverable from conventional CRM technology.
The implications of the above are that:
The stated requirements are so limited that most packages in the market can meet them, and so the meaningful comparison is nigh on impossible.
Key functional requirements are missed which increases the risk of purchasing a CRM package that doesn’t meet the ‘real’ needs. For example I’ve seen a lot of organisations with very sensitive data security needs fail to document any data security related requirements.
Or in the ‘Frankenstein-esque’ situation the stated requirements are so ‘unusual’ that vendors are discouraged from bidding, and those that are received have huge price tags. I know of several expensive CRM tendering exercises that produced no responses at all, with all invited vendors deciding to ‘no bid’.
Anyway, that rounds out why the functionality led approach to requirements gathering doesn’t work, next time I’ll try and articulate a better way…
Even those who have been exposed to CRM technology before, generally because the system they used wasn’t well set up, and/or the deterioration of memory over time, and/or their exposure to a limited sub-set of functionality, tend to struggle to produce meaningful requirements.
On the other extreme, this approach does occasionally produce users who can create a very detailed but ultimately Frankenstein-esque vision of a system out of all context with what’s deliverable from conventional CRM technology.
The implications of the above are that:
The stated requirements are so limited that most packages in the market can meet them, and so the meaningful comparison is nigh on impossible.
Key functional requirements are missed which increases the risk of purchasing a CRM package that doesn’t meet the ‘real’ needs. For example I’ve seen a lot of organisations with very sensitive data security needs fail to document any data security related requirements.
Or in the ‘Frankenstein-esque’ situation the stated requirements are so ‘unusual’ that vendors are discouraged from bidding, and those that are received have huge price tags. I know of several expensive CRM tendering exercises that produced no responses at all, with all invited vendors deciding to ‘no bid’.
Anyway, that rounds out why the functionality led approach to requirements gathering doesn’t work, next time I’ll try and articulate a better way…
Related VisualForce Articles
Office 2.0 - Have Fun and Be More Productive?
First is the theme: Enterprise Adoption. Using online tools to "get things done" is a topic that all of us at Appirio have always been passionate about personally-- we run our day-to-day lives on Salesforce and Google Apps, and most of cringe every...
Read more about Office 2.0 - Have Fun and Be More Productive?...
Build your very own seat at the strategy table
Everybody seems to be clamoring for a seat at the strategy table. It came up at the IxDA-SF talk on the Worth of Design, it’s covered in an engaging post by Josh Porter of Bokardo, and the world according to Google says that 143,000 folks are...
Read more about Build your very own seat at the strategy table...