The role of the CRM consultant in requirements gathering...
While it’s a significant proportion of the project work we undertake it’s not always obvious why we get involved in the requirements definition phase of a CRM implementation. Before I address that point it’s probably worth summarizing why effective requirements definition as an activity is so important to a project’s ultimate success. In essence trying to implement a revenue generating CRM system without a detailed set of requirements is like undertaking a major construction project without a set of architects plans – ultimately you might pull it off but it’s going to take longer, cost more, and the finished product might not actually be what you want.
The requirements document fulfills a number of key functions:
· It facilitates effective vendor selection
· It facilitates negotiation of pricing and terms against a firm specification
· It provides a blueprint of what will be built
With respect to the first two points the timing of the requirements gathering exercise is all important. The temptation is often to undertake the technology selection first and then work with the selected vendor to produce the detailed set of requirements. The trouble with this approach is that once you get to the detail you may actually find the product that you’re now committed to doesn’t actually fit the newly discovered requirement.
Perhaps more importantly this is the implementation equivalent of publishing your email address and expecting not to get spammed. The job of any self respecting vendor project manager will be to optimize the vendor’s commercial position by expanding the value of the project (or if the implementation budget is set, dumbing down what they will deliver for the money). The customer’s ability to resist the vendor enhancing their commercial position is extremely limited once they get locked in. As a guide I’d estimate that companies pay 50% more for the projects when they define detailed requirements after vendor selection rather than before.
Even when companies commit to producing requirements documentation it invariably falls down in a number of different respects, including:
· Failure to define the business objectives
· Failure to define requirements in terms of business processes
· Failure to define requirements in sufficient detail
· Specification of requirements that can’t be economically met by available technologies
I suspect these issues emanate from one or a combination of the following three factors:
· That the person compiling the requirements has a weak understanding of CRM technology and how it can be beneficially applied.
· That the person compiling the requirements has a poor understanding of the operation of the business, perhaps coming from an IT background for example.
· That the person compiling the requirements is time poor.
In order to be effective at requirements gathering the analyst needs to combine a detailed understanding of the functional capabilities of CRM technology, a great understanding of how businesses work, and a depth of experience of applying CRM technology beneficially. The analyst’s job is to look carefully at the business and identify how the capabilities of the technology can be beneficially applied. The effective analyst works like a doctor, asking the appropriate diagnostic questions, using their knowledge to arrive at a diagnosis, and determining a cure.
The analyst hampered by a lack of technology or business understanding will tend to ask users to ‘self-diagnose’ and simply ask what they want from the system. They don’t have the knowledge to define requirements that the potential user may struggle to articulate or identify issues and needs that the user might not even be aware exist. They are like a doctor who demands the patient diagnoses their own medical condition.
As with many of the things the CRM consultant does, requirements definition may not be the first area you might associate us with. However when you consider that effective requirements definition probably goes 80% of the way to achieving a successful project, (where performed prior to vendor selection) will lower purchase costs by about 50%, but requires considerably more time and knowledge than people often appreciate, it’s perhaps no surprise that this seemingly innocuous activity is where we spend a considerable of our project time.
The requirements document fulfills a number of key functions:
· It facilitates effective vendor selection
· It facilitates negotiation of pricing and terms against a firm specification
· It provides a blueprint of what will be built
With respect to the first two points the timing of the requirements gathering exercise is all important. The temptation is often to undertake the technology selection first and then work with the selected vendor to produce the detailed set of requirements. The trouble with this approach is that once you get to the detail you may actually find the product that you’re now committed to doesn’t actually fit the newly discovered requirement.
Perhaps more importantly this is the implementation equivalent of publishing your email address and expecting not to get spammed. The job of any self respecting vendor project manager will be to optimize the vendor’s commercial position by expanding the value of the project (or if the implementation budget is set, dumbing down what they will deliver for the money). The customer’s ability to resist the vendor enhancing their commercial position is extremely limited once they get locked in. As a guide I’d estimate that companies pay 50% more for the projects when they define detailed requirements after vendor selection rather than before.
Even when companies commit to producing requirements documentation it invariably falls down in a number of different respects, including:
· Failure to define the business objectives
· Failure to define requirements in terms of business processes
· Failure to define requirements in sufficient detail
· Specification of requirements that can’t be economically met by available technologies
I suspect these issues emanate from one or a combination of the following three factors:
· That the person compiling the requirements has a weak understanding of CRM technology and how it can be beneficially applied.
· That the person compiling the requirements has a poor understanding of the operation of the business, perhaps coming from an IT background for example.
· That the person compiling the requirements is time poor.
In order to be effective at requirements gathering the analyst needs to combine a detailed understanding of the functional capabilities of CRM technology, a great understanding of how businesses work, and a depth of experience of applying CRM technology beneficially. The analyst’s job is to look carefully at the business and identify how the capabilities of the technology can be beneficially applied. The effective analyst works like a doctor, asking the appropriate diagnostic questions, using their knowledge to arrive at a diagnosis, and determining a cure.
The analyst hampered by a lack of technology or business understanding will tend to ask users to ‘self-diagnose’ and simply ask what they want from the system. They don’t have the knowledge to define requirements that the potential user may struggle to articulate or identify issues and needs that the user might not even be aware exist. They are like a doctor who demands the patient diagnoses their own medical condition.
As with many of the things the CRM consultant does, requirements definition may not be the first area you might associate us with. However when you consider that effective requirements definition probably goes 80% of the way to achieving a successful project, (where performed prior to vendor selection) will lower purchase costs by about 50%, but requires considerably more time and knowledge than people often appreciate, it’s perhaps no surprise that this seemingly innocuous activity is where we spend a considerable of our project time.
posted by Richard Boardman at 6:42 pm
<< Home