CRM design trap - revisited...

The following paragraph in Joel Spolsky’s recent post caught my eye:

‘Custom development is that murky world where a customer tells you what to build, and you say, "are you sure?" and they say yes, and you make an absolutely beautiful spec, and say, "is this what you want?" and they say yes, and you make them sign the spec in indelible ink, nay, blood, and they do, and then you build that thing they signed off on, promptly, precisely and exactly, and they see it and they are horrified and shocked, and you spend the rest of the week reading up on whether your E&O insurance is going to cover the legal fees for the lawsuit you've gotten yourself into or merely the settlement cost. Or, if you're really lucky, the customer will smile wanly and put your code in a drawer and never use it again and never call you back.’

While the article is about the challenges of prioritizing development work in respect of shrink-wrap software, his observations on the challenges of custom development resonated with my comments from earlier in the week regarding the design process, and it prompted a couple of additional thoughts. It strikes me there are three main reasons that organizations sign off design specifications then recoil in horror when the customizations are finally unveiled:

One. A point I made on Monday – the quality of design documentation is often poor. Either because it is plain badly written, or because it is written for the needs of the development team rather than the customer. Either way, it’s nigh on impossible for the customer to comprehend what customizations the implementer is intending.

Two. They get signed off without being read. Reading design documents, particularly badly written ones is painful. It demands high levels of concentration. It’s time consuming. There’s a compelling urge just to skim through it. Where there is group sign off a dynamic kicks in that leads people to believe someone else is sweating through the detail, so a light skim is all that’s required. And….

…..three, we have complete faith in our implementer. They do this for a living right? OK, they haven’t had to do too much on this project so far, but they seem to know what they are doing - let’s leave it to the experts.

And of course sometimes that faith pays off and the implementer delivers a perfectly designed system. But when they don’t, it can be a very painful place to be. For fear of sounding like a stuck record, and with the promise I won’t return to the theme of design for a post or two, take your time here, and don’t sign off until you are 100% satisfied that you both understand what is being developed, and that you are convinced it’s going to work for you.

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.