The CRM design trap...
There are plenty of points in a CRM project where things can go astray, but one of the key ones is the design phase. To give this some context, let’s quickly cover what happens in a project leading up to the design phase. At the start of the project we will ideally have a clear set of requirements. We will understand what it is within the organisation we are trying to improve. So, as an example, we may have determined that the business needs better visibility and tracking of incoming leads. We wish to provide better feedback to marketing so that they can see their return on investment by marketing campaign. This will let them better tune their marketing expenditure to give increased returns. Sales management will use improved lead visibility to ensure all leads are actioned appropriately, which will in turn allow them to facilitate an increase in lead to sale conversion rates.
In our example above, we will also have identified in detail the information we will be looking to track for each lead, and we will have mapped out broadly how the new lead tracking process will work. We’ve gone through the technology selection process in which we used our documented requirements to help us select which products best matched our new business processes. Having made our selection we recognise that, while it largely meets our needs out of the box, the software requires customisation.
For example in our case we have decided to make the lead capture process quicker and more accurate by integrating post office address information, allowing us to automatically populate the address detail from the post-code. We also want a utility that alerts us if there is a possibility that the record already exists on the database, so that we reduce the number of duplicates that are added. We also want to customise the existing lead capture form because it doesn’t fully reflect the information sales and marketing management are keen to capture.
The design phase is the part of the project where the vendor maps how our requirements are going to be delivered by the application. Where the application requires customisation, the vendor will typically document the details and ideally create mock ups of the customisations. The goal is that the customer is in a position to agree the vendor has accurately reflected their requirements, and coding can begin.
This section of a project is fraught with potential issues. In extreme instances, vendors will skip the design phase altogether and just start coding, with the inherent likelihood that what’s delivered isn’t going to meet the need, and the project gets plunged into lengthy and potentially expensive re-development cycles. More commonly there will be some level of design documentation, but this can vary enormously in terms of the level of detail, and particularly how easy it is for the customer to understand. It’s very important the customer does understand the design document because in general, once you sign off, that’s going to determine what you get. And, if what you get subsequently turns out not to be what you want, the vendor (who has a design document with your signature on it) is likely to view any changes you want as ‘change requests’ – which means you either live with something that doesn’t meet your needs, or cough up additional money to get it re-engineered.
In addition, there’s the issue of ‘artistic interpretation’ during this phase. A design can deliver the requirements, but not necessarily in a way that is ergonomic or user-friendly, so the customer needs to be very attentive to the specifics of the user interface. In particular vendors tend to prefer to re-use existing application functionality when designing customisations. This may hedge against some of the risks of the development process, but if the result is too contrived for easy user comprehension, or requires excessive amounts of mouse clicks/key strokes to make it happen, then user adoption will suffer.
In summary it’s important that the CRM project team are heavily engaged in the design phase, and don’t simply trust the judgement of the vendor implementation team. In our example it’s important that our lead capture process is quick and intuitive. If it isn’t, the likelihood is that end-users won’t take the trouble to log leads, and one the principle goals of the project won’t be realised. The design document will to a large degree determine the success of failure of the project as a whole and should be viewed as a key crunch point. Attention to detail at this stage will pay dividends – lack of attention on the other hand can lead to a lot of pain downstream.
In our example above, we will also have identified in detail the information we will be looking to track for each lead, and we will have mapped out broadly how the new lead tracking process will work. We’ve gone through the technology selection process in which we used our documented requirements to help us select which products best matched our new business processes. Having made our selection we recognise that, while it largely meets our needs out of the box, the software requires customisation.
For example in our case we have decided to make the lead capture process quicker and more accurate by integrating post office address information, allowing us to automatically populate the address detail from the post-code. We also want a utility that alerts us if there is a possibility that the record already exists on the database, so that we reduce the number of duplicates that are added. We also want to customise the existing lead capture form because it doesn’t fully reflect the information sales and marketing management are keen to capture.
The design phase is the part of the project where the vendor maps how our requirements are going to be delivered by the application. Where the application requires customisation, the vendor will typically document the details and ideally create mock ups of the customisations. The goal is that the customer is in a position to agree the vendor has accurately reflected their requirements, and coding can begin.
This section of a project is fraught with potential issues. In extreme instances, vendors will skip the design phase altogether and just start coding, with the inherent likelihood that what’s delivered isn’t going to meet the need, and the project gets plunged into lengthy and potentially expensive re-development cycles. More commonly there will be some level of design documentation, but this can vary enormously in terms of the level of detail, and particularly how easy it is for the customer to understand. It’s very important the customer does understand the design document because in general, once you sign off, that’s going to determine what you get. And, if what you get subsequently turns out not to be what you want, the vendor (who has a design document with your signature on it) is likely to view any changes you want as ‘change requests’ – which means you either live with something that doesn’t meet your needs, or cough up additional money to get it re-engineered.
In addition, there’s the issue of ‘artistic interpretation’ during this phase. A design can deliver the requirements, but not necessarily in a way that is ergonomic or user-friendly, so the customer needs to be very attentive to the specifics of the user interface. In particular vendors tend to prefer to re-use existing application functionality when designing customisations. This may hedge against some of the risks of the development process, but if the result is too contrived for easy user comprehension, or requires excessive amounts of mouse clicks/key strokes to make it happen, then user adoption will suffer.
In summary it’s important that the CRM project team are heavily engaged in the design phase, and don’t simply trust the judgement of the vendor implementation team. In our example it’s important that our lead capture process is quick and intuitive. If it isn’t, the likelihood is that end-users won’t take the trouble to log leads, and one the principle goals of the project won’t be realised. The design document will to a large degree determine the success of failure of the project as a whole and should be viewed as a key crunch point. Attention to detail at this stage will pay dividends – lack of attention on the other hand can lead to a lot of pain downstream.
posted by Richard Boardman at 1:42 pm
<< Home