If you don't know where you are going...
One of the things that has struck me over the years is how few organisations spend any great time defining and documenting their requirements for a CRM system before plunging into the frenzy of vendor selection. I don’t think it’s a coincidence that the same organisations have struggled to realise high returns from their software investment. To my mind effective requirements definition is the foundation of successful projects and long term high return systems, and here’s a few reasons why –
Firstly, it’s nigh on impossible to select appropriate software if you are unclear what it is you are trying to achieve, and what functionality is required to achieve it. As Lewis Carroll noted - ‘if you don’t know where you are going, any road will take you there’. Which is why, all too often, CRM technology will get purchased for fairly superficial reasons, like ‘the software looked easy to use’, rather than a reasoned assessment of functional fit. Which, in turn, is why a lot of organisations realise, post having made a hefty investment in technology, and now finally having worked out their requirements, that it doesn’t actually do what they want it to.
Second, it’s nigh on impossible to make a pricing comparison when your needs are vague because the vendor is only able to ‘estimate’ the service element of a project, so you never get to a situation of being able to compare apples with apples, and leave yourself completely open to a vendor proposing a low ball price knowing full well, that once in receipt of your order, their more ‘considered’ review of your requirements will double their estimate.
Thirdly, if you wait until you’ve raised the purchase order before defining requirements, you are likely to find that the accumulated list of ‘must have’ features and functions does not sit well with the limitations of the budget – which leaves the potentially painful options of chopping back requirements (often, in my experience, to the point that the project is effectively emasculated), or a visit to the board for more money.
Fourthly – It’s a lot cheaper to get the requirements well defined up front, then start implementation, rather than the other way round. The clearer the requirements are, the less time (and money) the vendor has to spend defining them, and the less time they have to spend on re-work of functionality which they imagined you would want in the absence of a detailed specification.
Fifthly (and finally) – It’s better to go through the time-consuming activities of effective requirements analysis before you’ve paid out for the software, then after, which of course is when everyone is pushing for a rapid live date, and the pressure’s on to cut corners to deliver quick results.
It may not be the glamorous part of a CRM project, but effective requirements gathering is to my mind what separates the high from the non-performing projects.
Firstly, it’s nigh on impossible to select appropriate software if you are unclear what it is you are trying to achieve, and what functionality is required to achieve it. As Lewis Carroll noted - ‘if you don’t know where you are going, any road will take you there’. Which is why, all too often, CRM technology will get purchased for fairly superficial reasons, like ‘the software looked easy to use’, rather than a reasoned assessment of functional fit. Which, in turn, is why a lot of organisations realise, post having made a hefty investment in technology, and now finally having worked out their requirements, that it doesn’t actually do what they want it to.
Second, it’s nigh on impossible to make a pricing comparison when your needs are vague because the vendor is only able to ‘estimate’ the service element of a project, so you never get to a situation of being able to compare apples with apples, and leave yourself completely open to a vendor proposing a low ball price knowing full well, that once in receipt of your order, their more ‘considered’ review of your requirements will double their estimate.
Thirdly, if you wait until you’ve raised the purchase order before defining requirements, you are likely to find that the accumulated list of ‘must have’ features and functions does not sit well with the limitations of the budget – which leaves the potentially painful options of chopping back requirements (often, in my experience, to the point that the project is effectively emasculated), or a visit to the board for more money.
Fourthly – It’s a lot cheaper to get the requirements well defined up front, then start implementation, rather than the other way round. The clearer the requirements are, the less time (and money) the vendor has to spend defining them, and the less time they have to spend on re-work of functionality which they imagined you would want in the absence of a detailed specification.
Fifthly (and finally) – It’s better to go through the time-consuming activities of effective requirements analysis before you’ve paid out for the software, then after, which of course is when everyone is pushing for a rapid live date, and the pressure’s on to cut corners to deliver quick results.
It may not be the glamorous part of a CRM project, but effective requirements gathering is to my mind what separates the high from the non-performing projects.
posted by Richard Boardman at 3:40 pm
<< Home