Month: February 2009

Once upon a time in my career any sentence containing the word ‘business process’ would reduce me to a near catatonic state. I assume many others feel the same way, because the concept of business processes virtually never features in the many CRM business requirements documents I get to read. Continue Reading

Curiously, I had three companies contact me this week about CRM software they were launching. One part of me wants to applaud anyone who has the gumption to invest their time and money in developing software, the other, my independent CRM consultant side, is about as receptive as the lady Continue Reading

‘So how would you rate the service you received on a scale of one to five, five being highly satisfied and one being highly dissatisfied’ said the lady conducting a satisfaction survey on behalf of the company who’d recently replaced my windscreen. ‘Well that depends, the call centre were great Continue Reading

Heavily mired in CRM system design work over the last few weeks I initially missed the post from InsideCRM regarding Salesforce.com losing three executives, which in turn draws on a post from DestinationCRM. I mention this not because it might be early evidence my suggestion that the CRM market may Continue Reading

Okay, so last week Bob got fired. The conventional wisdom on how to gather CRM requirements resulted in a substantial project overrun, a system that added no value, a board squeamish about further investment in IT, and Bob becoming a convenient scapegoat. But why doesn’t the conventional functionality led approach Continue Reading

The conventional wisdom has it that that CRM requirements gathering consists of assimilating lists of functional requirements and then prioritizing and ranking them. On the surface this all seems very logical, but in practical terms it doesn’t work. Since this is the approach that most organizations take, I thought I’d Continue Reading