Earlier in the year I wrote a series of posts entitled ‘Why Bob got fired’ which was meant to culminate in a piece about how to write a business and functional requirements specification for a CRM system – something I’ve seen people consistently struggle with over the years. Anyway somewhere along the line I got distracted and didn’t finish the series, so I thought I’d revisit CRM requirements specification and try and set out in as simple and clear a way as I possibly can my thoughts on the best way of approaching it.
Perhaps the best starting point is to give some definition to what I mean by CRM requirements documentation. I will cover this in more detail in the coming weeks, but in short a requirements specification does three things: it sets out the problems we are trying to fix or the desirable outcomes we are looking to achieve, it defines how those problems will be solved or outcomes achieved, and identifies the required supporting functionality.
I will also add that in my view a CRM requirements specification is a detailed piece of work more in line with a set of architect’s plans, rather than the high level list of functional bullet points that are often produced. It is created before technology is purchased rather than after, and by the user of the CRM system, not the CRM vendor.
I will talk more about how you might approach requirements gathering and best way to document them in later posts, but today I just wanted to set out why getting a good set of requirements is important, and that comes down to the following reasons:
- It helps ensure the project receives the funding, resources, and management attention necessary for success because there is clarity about how the system will benefit the organisation. A lot of CRM projects fail to be adequately resourced because no sufficiently compelling outcomes are defined.
To my mind effective requirements gathering is the foundation of a successful project, and alongside defining a well thought out user adoption strategy, is one of the key activities which determines success or failure. If you can get it right, every other part of the project flows more easily, and, as an added bonus, it allows you to achieve more, at less cost, and with less risk.
Having set out why it’s important, next week I’ll set out my thoughts on what makes for a successful CRM requirements gathering approach.
Richard
I look forward to reading your upcoming posts. This is a great start. Thanks very much.
Francis Buttle, PhD
The Customer Champion
http://www.buttleassociates.com