Seven tips for phasing CRM projects...

‘Phase your CRM project’ is one of those frequently offered pieces of advice to would-be implementers of CRM technology, but what does this really mean in practice? So, seven quick tips for phasing CRM projects effectively:

Do the minimal amount that gets results – it’s easy to over-engineer CRM systems, but it’s generally better to implement something reasonably simple which generates quick results, and build on it. This approach reduces the risk of spending a lot of time and money creating capabilities that later prove to be white elephants.

The first phase must be value generating – whatever you do in phase one must create compelling value, otherwise you will struggle to get resources for later phases. I see a lot of vendors promoting the ‘suck it and see approach’, where customers are encouraged to buy some CRM software and then experiment. This might be good for short term software revenues, but rarely produces systems that clients want to continue to invest in.

Resources dictate phasing – getting users to use a system in a consistent and structured fashion is one of the key challenges of CRM deployment. User adoption requires people on the ground winning hearts and minds and this tends to be resource hungry, therefore one of the key determinants of phasing is the amount of resources available to do this. Try and do too much in one go and the implementation team can quickly become overwhelmed.

User micro-phasing to maximize adoption – there’s only so much change that users can embrace at one time so breaking down a phase into a series of micro-phases, for example by releasing capabilities over time, can be an effective way of addressing the user adoption bottle-neck.

Schedule subsequent phases in advance – if your CRM project is to be phased it generally makes sense to ensure that the timing, content, benefits and costs of future phases are broadly defined up front. This helps ensure resources are available when you need them and avoids the need to go through a lengthy capital allocation exercise for each subsequent phase.

Reporting must be phase one – for reasons that I explained here previously CRM vendors seem to discourage users from worrying too much about reporting in the early phases of a project. Since reports are the key way for the management team to ensure that the processes that the system supports are being followed, relegating them to the ‘manyana’ file virtually guarantees system obsolescence.

Manage ongoing system enhancement requests carefully – over time users will identify ways in which the system can be improved and enhanced. These requests need to be carefully assessed, managed and prioritized to ensure they will create genuine additional value. It’s easy to load up future phases with features that, while meeting the demands of a few vociferous users, fail to generate any return on investment.

Reflecting on CRM failure....

I was asked to speak on the topic of CRM failure this week. The following summarizes what I covered.

The occurrence of outright failure, where no system ever sees the light of day is exaggerated. I’m only aware of a few instances of outright failure and this normally occurs when the CRM system is being integrated into another system, and usually where there is a mismatch in expectations between client and vendor regarding the complexity of the integration.

The more common manifestation of CRM failure is what we might term ‘the lights are on but no-one’s there’. The system functions, but generates no meaningful value. There might, for example, be a database of sorts, but the data isn’t trusted as being up to date, the occasional salesperson might use it to add a note of schedule a call back, but there’s no meaningful management information.

In our experience about 80% or so of CRM systems fall in this category. Which is fine if that’s what users were expecting, but for most there was a grander vision when the project was started.

For those that get it right though CRM technology can facilitate very high returns on investment. The sales and marketing functions often operate with poorly defined processes with little support from technology. By re-engineering these processes and supporting them with an effective IT infrastructure companies can add substantial bottom line value.

In terms of avoiding CRM failure I picked out the following five themes:

Asking the right question – prospective users tend to ask the ‘what technology is right for me’ question. The question they should be asking is ‘how do I apply CRM technology to my organization in a way that generates results’. Technology selection is important but it’s just a part of what’s involved in successfully implementing a CRM system. Users often fail to appreciate that the technology won’t generate results ‘out of the box’ (however much some of the hosted vendors might like us to believe), and that how it can be beneficially deployed is often far from obvious, and even if the application is clear, there will generally be some measure of customization to support the client’s unique processes.

Finally, on this point there are users that recognize that implementing these systems is far from straightforward, but assume the CRM vendor will help them navigate the challenge. In our experience the good vendors understand the technology but not the front-line application of it. They are likely to adopt a ‘tell me what you want’ position rather than guide the user.

Create a compelling vision – many users of CRM enter a project with an expectation that good things will happen rather than having a clear understand of what problem they are trying to fix. However not only does the objective need to be clear, but it also needs to be compelling otherwise the project won’t acquire the resource and attention bandwidth required for success.

Design in detail up front – most clients purchasing CRM technology have only a high level understanding of what they are looking to achieve when they enter the vendor selection phase. As a result they purchase software at a point that vendors can only estimate implementation costs. This makes them vulnerable to vendors coming back with upwardly revised estimates once the implementation begins, and the lack of a clear understanding of functional needs increases the risk of purchasing a technology that doesn’t meet their real needs.

A better approach is to create a detailed specification of requirements up front which allows vendors to provide accurate pricing in a competitive environment. We would estimate this reduces purchase costs on average by 40%, and also reduces the risk of ‘scope-creep’ in the implementation phase.

The user adoption challenge – it doesn’t matter how well thought out your system, if you can’t get users to use it in a consistent and structured way then it won’t add value. The conventional industry approach to user adoption is primeval and is further evidence of my earlier contention that vendors are fine with technology, but not the application of it to a real world setting. My experience is that users invariably come back from training sessions with scant understanding of how to use the system and for most vendors a half day user training session forms the entirety of their user adoption strategy. While user adoption is a multi-faceted challenge, we would stress the need to carefully monitor and review the progress of each individual user, and provide a tailored programme of support recognizing existing habits are hard to break and new ones difficult to set.

A CRM project is not just for Christmas – which is a play on the advertising campaign that ‘pets are for life not just for Christmas’, the point being that since the value of CRM technology accrues over the life of the system, we shouldn’t treat CRM as a one off project, and recognize we need to support it for the long term. CRM systems are particularly vulnerable to change, for example changes in business strategy which aren’t accommodated, or the arrival of new executives unfamiliar with the system’s capabilities can quickly plunge a system into obsolescence. Maintaining a high performing system over time has cost and resource implications that companies need to budget for up front.

In summary, if we are to escape the 80% failure rate, then we need a business process oriented, rather than a technology focused approach. Successful CRM systems thrive in organizations that are able to adopt a process oriented approach. We need to be aware that that this rigorous approach is not in every organization’s DNA, and for many this structured use of CRM should be a series of small steps, or in some cases should not be undertaken at all – on the basis it’s better to ‘fail’ without trying than after the commitment of a lot of resource and energy in a situation that was never conducive to success. For those that are prepared to go for it, the rewards are there. In a world where it’s increasingly to differentiate on the products and services we offer, when out latest and greatest can be ‘me too-ed’ virtually overnight, the effective use of information technology (not just CRM) is still a rare enough phenomenon as to represent a huge un-mined seem of business efficiency and competitive advantage.

Independent CRM consultants and their role outside CRM software selection...

One of my training partners was telling me about one of his client’s purchase of a Microsoft CRM system, as we were out running this morning. As the story went the client had settled on MS CRM as the preferred technology and then went on to find an implementation partner. They solicited two bids. One came in a £60K and one at £250K. On the basis of price, not surprisingly they decided on the former.

I found it interesting that a user wouldn’t seek advice from a CRM consultant in this sort of situation given the wild disparity of pricing, but it didn’t altogether surprise me. This reluctance to engage outside help in these circumstances tends to stem from a number of false assumptions:

That selecting the right technology is the key challenge, and once you are settled on that everything else is straightforward. In reality while technology (and implementation partner selection) is very important, it is by no means the toughest challenge in applying CRM technology. The areas of strategy, process design, and user adoption are far more demanding.

That the quoted price in an accurate representation of what you will end up paying. Since most CRM vendor pricing is provided on indicative or estimated basis what the client ends up paying can be an order of magnitude different from the initial quoted price. The client either has to dumb down the requirements or accept the shift in budget.

That CRM vendors have the ability and inclination to deliver a system that significantly improves performance rather than a system helps them meet their sales targets. The two objectives rarely coincide in my experience.

While I don’t think these myths will be debunked overnight it will be interesting to see if independent CRM consultants do get more involved in situations where the technology for one reason or another is already selected. There are a number of, what strike me at least, as compelling reasons why we should, in that they help the client:

Achieve more - through using experience and understanding of how businesses operate to create the vision for a high pay-back system, and project management skills to make it happen.

At a lower price - primarily achieved by designing the system up front and letting vendors bid on a fixed specification which allows the comparison of like with like in a competitive environment, and reduces costs through effective negotiation.

With less risk - through experience and proven implementation methodologies.

With less internal disruption - by outsourcing what can be highly time consuming internal implementation activities.

I suspect that the role of the independent CRM consultant will change over time as people realize the technology question, while important, is just a part of a more demanding challenge – how do we apply CRM technology in a way that truly changes our business? When organizations start asking this question things are going to become very interesting.

The tyranny of the CRM change request...

Conspectus asked me to write an opinion piece for them on matters of my choosing pertaining to CRM technology. While I suspect they would have preferred something rather more topical regarding CRM and Twitter, or CRM and H1N1 for example, I warmed to the topic of the CRM vendor’s fixation with selling software as being responsible for most of the ills of the industry. I won’t detail the line of reasoning, suffice to say if and when the article gets published I’ll provide a link to it.

I’m deeply immersed in taking a couple of sites live at the moment, and was therefore reminded of another facet of CRM vendor behaviour that supports my ‘software sale fixation’ theory – the change request. As I outlined in a recent post on the CRM design hell, vendors generally require you to sign off a design which they will go away and build, and if that doesn’t happen to be what you wanted when it’s delivered, they will raise a change request for you to sign off which will generally entail you paying them money to go away and change it.

In principle this is a sensible policy since it’s designed to prevent the phenomenon of ‘scope-creep’ where the client keeps adding new requirements. In practice however CRM vendors – and I suspect software vendors generally – use it in a way that defies some of the basic practices of customer service fully accepted by virtually every other area of commercial endeavour – primarily the notion that if p*** off the customer they are unlikely to come back and do more business with you.

Imagine if you went to a restaurant and ordered the soup and what turned up was mere a teaspoon full of your selected starter, and when you remonstrated with your waiter, you were informed that they had indeed delivered ‘soup’ and if you wanted more then of course you could place another order. Predictably, unless you were on some radical diet, you might feel rather upset, and might well choose, amongst other lines of protest, not to visit the establishment again.

While the two vendors I’m working with at the moment have proved pretty good in their use of the change request, they are very much the exception. Over the years, time and time again, I’ve seen vendors bludgeon their clients into submission with the heavy handed use of the change request process, and it creates such bad feeling I find it difficult to fully fathom why they do it.

The focus of vendors seems to be on what is ‘signed off’ rather than what is right to help the client’s business. And as long as something is signed off the vendor is generally happy, regardless of whether that something is in the client’s interests or not. Thereafter the standard operating procedure seems to be to maximize the short-term profitability of the client by using the change request procedure to limit even inconsequential changes.

This practice reflects the following aspects of the CRM vendors’ world-view:

That their role is to sell technology NOT deliver business solutions – however much ‘solution’ may litter their marketing literature and sales presentations.

That a project is a ‘one-off’ spend with the vendor. That ongoing revenue is seen as a nice to have rather than a fundamental requirement that needs to be catered for.

If things are to change the vendors need to understand that they can implement genuine business enhancing solutions, and when they do they will have a client happy to invest in their technology over the long-term. If and when this world-view changes then the change request may finally revert to a sensible tool to manage projects.

On CRM and User Acceptance Testing...

Having sat through countless sales presentations over the years where vendors have rhapsodized about their carefully honed implementation methodology I can observe that the reality rarely measures up to promise of the pitch.

One manifestation is the quality of what gets delivered into the user acceptance testing (UAT) phase where the client assesses whether the development work undertaken by the vendor meets their requirements. It’s at this point that the vendor can, to use a sporting metaphor, throw their client a ‘hospital pass’.

In principle, and according to the fluently presented glossy implementation methodology, what the vendor should provide to the client is a rigorously tested system, which can practically be waved through UAT.

In practice however, the rigorous testing phase can quickly be dispensed with if the vendor finds them self under time or budget pressure, and the client effectively gets landed with the vendor’s testing responsibilities, or worse, gets to try and test something that’s effectively still in development – the equivalent of putting up the wallpaper while the plasterer is still at work. What might have been a relatively trivial piece of work is transformed into a death march as the bug count ratchets up and up.

Just to make this all slightly more pressurized, because UAT is pretty much the final step before live, most of the associated live activities are all now scheduled, and there’s relatively little scope to move dates out to reflect the unexpected influx of work, and so the test team ends up absorbing the workload the best way they can – generally dispensing with life’s luxuries such as sleep.

There are however a few things that can be done to help address this:

Have a detailed mutually agreed and understood design specification that gives you something to test against – this limits the scope for misunderstanding as to what should be delivered

Give yourself plenty of wiggle room in the project plan in order to absorb the unexpected developments that will inevitably occur.

Pay for implementation work on the basis of achieving defined milestones, and make sure one of those milestones is the delivery of a high quality system into UAT. I’m also wondering, though I’ve yet to try it, whether it’s worth offering vendors bonuses for hitting quality targets, just because of the potential downstream savings.

Make sure your vendor has scheduled for resources to be available to quickly fix the issues you identify, because if developers get allocated to other projects, you could be facing a long wait.

Assume the worst, because you’ll generally be proved right, and allow more time than you possibly think you’ll need.

In summary, while UAT is one of the final hurdles in the implementation process, it’s been responsible for more than its fair share of project delays, and has tempted many a project into the potentially fatal act of going live with a part-cooked system. As with many aspects of CRM implementation, it’s worth treating cautiously.

Did I call it wrong?

Back in October I made a very downbeat assessment of the state of the economy and its impact on the CRM industry. While I winced hugely when Joel Spolsky announced the end of the tech recession back in February, a straw poll of vendors suggests that while the last quarter of 2008 was pretty dire, the first quarter of 2009 has been largely business as usual. So, what are we seeing in the CRM market:

The project pipeline is much more volatile with a much great likelihood that ‘done deals’ can be postponed or cancelled, making it much more difficult for vendors to plan their businesses.

Vendors have been making staff redundant.

Some of those vendors seem to have made too many staff redundant in response to the Q4 lull, and are finding themselves under resourced after the Q1 up-tick.

There seems to be much more movement in terms of end users shifting support contracts between CRM resellers – presumably because of concerns over long term viability and because some resellers will have a reduced quality of service because of cost cutting.

What I haven’t seen is much evidence of CRM vendors or resellers going out of business or consolidating, but it’s still early days. However at this stage it seems the CRM market is substantially more robust than I was expecting, and with a few potential green shoots appearing in the economy in recent weeks perhaps my dark predictions were misplaced. This may be because companies recognize that even in recession winning and retaining customers is vital, however I also wonder if we’re seeing the fulfillment of projects which were initiated before the financial melt-down and that we may see a slow down later in the year.

Ultimately I’m still not sure I’m wrong, but I will concede there is the possibility, and in this respect at least I'd be delighted to be proved so.

Unlocking revenues through better b2b customer management...

A lot of companies underestimate how much value they have in their customer base, and this may never be more important than in the current climate. As independent CRM consultants we're currently doing a lot of work to help clients unlock that potential. A recent article of ours in CustomerThink explains some of the ways CRM technology can support this in a B2B environment - 'Cash in the Attic: Unlocking Customer Value with CRM Technology'

Why Bob got fired and why the conventional wisdom on CRM requirements gathering doesn't work...part three

The final major flaw with the functionality led approach to CRM requirements gathering is the Rumsfeldian notion of the unknown unknowns. Users, who invariably haven’t used CRM technology before, are expected to articulate a complete vision of what they want from a system, and invariably are only able to produce a handful of bullet points.

Even those who have been exposed to CRM technology before, generally because the system they used wasn’t well set up, and/or the deterioration of memory over time, and/or their exposure to a limited sub-set of functionality, tend to struggle to produce meaningful requirements.

On the other extreme, this approach does occasionally produce users who can create a very detailed but ultimately Frankenstein-esque vision of a system out of all context with what’s deliverable from conventional CRM technology.

The implications of the above are that:

The stated requirements are so limited that most packages in the market can meet them, and so the meaningful comparison is nigh on impossible.

Key functional requirements are missed which increases the risk of purchasing a CRM package that doesn’t meet the ‘real’ needs. For example I’ve seen a lot of organisations with very sensitive data security needs fail to document any data security related requirements.

Or in the ‘Frankenstein-esque’ situation the stated requirements are so ‘unusual’ that vendors are discouraged from bidding, and those that are received have huge price tags. I know of several expensive CRM tendering exercises that produced no responses at all, with all invited vendors deciding to ‘no bid’.

Anyway, that rounds out why the functionality led approach to requirements gathering doesn’t work, next time I’ll try and articulate a better way…

And now also Tweeting....

Had I been a venture capitalist a few years back, and, had I entertained a pitch from the folks looking to develop Twitter, then here’s what I would have said (choking back tears of laughter): ‘OK, so let me get this straight, you want to develop this site right, and it’s like a blog right, but your big thing, your really, really killer differentiator, is that your going to limit the blogger to – what was it again? Oh yeah 140 characters!?!?!......’

I didn’t get Twitter. Like I didn’t get why someone might not be satisfied with their standard mobile ringtone – still don’t for that matter. In the end, and solely because a friend twisted my arm with sufficient violence, I signed up for Twitter and started to ‘Tweet’.

A couple of months on I probably still don’t fully get it, but I’m finding it oddly addictive. I’m not sure from a marketing or promotional standpoint whether it can or can’t add value (and that’s not really why I do it anyway), but as a means of accessing a torrent of information from the people you choose to follow (mine include Lance Armstrong and Guy Kawasaki), it’s unrivalled.

My own Tweets are an eclectic mix – the last 48 hours or so have included Coventry City FC, the M25, Port of Spain, and a bit of CRM, and are probably best branded work in progress. Should you already be tweeting and want to follow, you can find me here.

Six tips to surviving CRM design hell...

Having spent the past six weeks in CRM design hell, I thought I’d share some tips on surviving the process while it was freshly seared on my memory. Trust me, CRM design work, rather like a prolonged course of dental treatment, isn’t the most fun way to spend your time. For those of you who haven’t been through CRM design before, it’s probably appropriate to first explain what it is: CRM design is where, having selected the CRM technology you wish to implement, you sit with your chosen vendor, and work out how your CRM requirements will be delivered in the new software.

On the surface this might not seem exactly onerous, but what you agree at this stage is what the vendor will go off and create, and if what they create doesn’t turn out to be quite what you wanted, then the vendor is likely to point out that, since you signed your name in blood that this was indeed what you wanted, they’ll now have to start all over again – and of course charge you for the privilege - so the project ends up taking a lot longer and costing a lot more than you intended.

In reality the design phase can be pretty straightforward, assuming the requirements are pretty close to the out of the box software. If however you require much in the way of customization or integration, the design phase will normally incorporate the dreaded design specification which you will be tasked with reviewing and swearing the requisite blood oath on the life your first born by way of confirmation of its accuracy.

Reviewing design documentation is to say the least challenging, so my six tips for surviving the experience:

Start with a good set of requirements – I won’t dwell on this as it’s a frequent theme in this blog, but suffice to say if you have a detailed well thought out set of CRM requirements - apart from saving you lots of money – it gives a ready means of checking off that everything you previously said you wanted is indeed what your vendor is planning to give you (vendors having tendency to slightly selective memories when it comes to things they feel might be awkward/expensive to develop).

Do not expect it to be in a language you understand – Design specifications are written for two audiences: you, as the client to sign off, and the vendor development team so they know what they’re meant to be developing, but actually mostly the vendor development team, who are generally extremely technical, which you may or may not be, and work with the selected software day in day out, which you probably don’t. So it’s a bit like being asked to sign a contract which is written in, say Greek, when English is your first language. So allow a lot of time (even a straightforward design document can take several days of work), and stock up on coffee and paracetamol.

Make sure you understand every word – Even innocuous phrases can have deep meaning, so these documents don’t suit a quick skim. The greatest mistakes I’ve made on projects have been where I’ve figured something’s been too arcane for me to take the time to fully understand, so my advice is no matter how dumb you feel the questions may be, keep asking them until you are 100% certain you understand what’s being said.

Expect trouble – You might be wholly convinced that your selected vendor are a pretty switched on bunch, and they might well be, but they will still make mistakes and omissions, and a lot of them, so don’t get lulled into thinking that you can trust them, and avoid the necessary investment in coffee and paracetamol. Even on a modest requirement I figure the vendor has done a pretty good job if I find less than a hundred issues on the first pass.

Finished reviewing? – the journey just begins – While you might feel a sense of a job well done having completed your review of the design, there’s normally plenty more to do. Curiously, many design specs have more mistakes in their second iteration than the first – a phenomenon for which I’m unable to offer any logical explanation. Half a dozen iterations isn’t that unusual for a moderate amount of customization, so budget for coffee and paracetamol accordingly.

Make sure the vendors have the resources available to action your input – You’d figure it wouldn’t surprise vendors that clients actually reviewed their specs, but it seems to. Once you’ve completed your review you would hope the vendor would be able to process your input in a timely manner, but if the relevent staff member has been allocated onto another project this isn’t going to happen, so it’s always wise to make sure that resource is available to quickly process the necessary changes, otherwise very lengthy project delays can ensue.

While this post is slightly tongue in cheek, the design phase might seem innocuous, but it really does catch a lot of organizations out. Very substantial overruns can easily result, so it’s really worth the considerable investment of time and energy required to get it right. There aren’t unfortunately any short-cuts, but coffee and paracetamol really do help.

Why Bob got fired and why the conventional wisdom on CRM requirements specification doesn't work...part two

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. This is odd for a number of reasons:

Assuming our objective for the system is to be more than a play thing for the sales team to dip in and out of as they feel inclined, the only way for a CRM system to deliver the objectives we talked about in episode two of this series, is to use it in a consistent repeatable way in order to achieve our desired outcomes i.e. it needs to incorporate a set of business processes. So unless you get the processes right you don’t get the benefits.

Because the way you run your business is pretty much unique in at least some respects, CRM technology isn’t going to work for you straight out of the box. Therefore even if the technology you select has a standard way of doing things (i.e. its own business processes) these will not map precisely to how you do business. They may require a little change or they may require a lot, but somewhere along the line you’ll need to figure out how you want the system to support the way you do business and adapt it.

Let’s say you wanted to cook lasagna. You’ve never cooked lasagna before so your first step is to go to the supermarket to buy some ingredients. It would be pretty difficult to do this without reading the recipe first. You’re wandering around thinking ‘mmm, now when I had it before there was definitely some mince, and oh yes, cheese, not sure which type though, and herbs, yeah, there were definitely some of those….’. Chances are that while you’re going to get some ingredients right, you’re getting to get some wrong, and plain miss others.

CRM requirements gathering isn’t much different; until you fully understand the processes (recipe) it’s very difficult to work out the supporting functional requirements (ingredients). And, to torture the analogy some more, without the recipe it’s difficult to guess the time involved to prepare and cook your lasagna, and so with CRM, without understanding the detail of the processes, it’s very difficult to estimate how much work (and hence cost) will be involved in adapting the system to meet your needs. In other words it’s only with a detailed understanding of the desired business processes that you can flush out the functionality you need and the cost of customization.

Finally, business process definition can be surprisingly time-consuming. You may have robust existing processes which can be quickly mapped into a CRM system. You may not. I’ve seen managers reduced to near gibbering wrecks when I’ve walked them through how their existing processes actually work on the front-line. The implementation of CRM technology is often the trigger for existing processes to be re-evaluated and engineered, and entirely new processes introduced. While process development isn’t necessarily immensely time consuming, it generally is.

The functionality led approach to CRM requirements gathering pays little attention to the above considerations and therefore creates a number of the problems the likes of which led to Bob being fired:

The functionality led approach fosters a belief that all we need do is purchase the right CRM software throw it on a server and we’re ready to go, which is the equivalent of spreading the lasagna ingredients on the table and saying we’ve got a lovely home-cooked meal. Technology is a tool. It won’t produce results on its own. It requires business processes or it doesn’t generate results.

The full functional needs fail to get flushed out and so the risk increases of getting landed with an inappropriate technology.

Without a full understand of how much the out of the box system will need to be customized to support the yet to be specified business processes, vendor pricing proposals can only be estimates. This has several implications:

1. We can’t easily compare pricing estimates because one vendor may estimate cautiously another may game the system by putting in a low ball estimate, therefore we can’t compare apples with apples.

2. It’s virtually impossible to negotiate on a substantial part of the system purchase costs because they aren’t known at the time of purchase.

3. We won’t know the full extent of the requirements and costs until after we’re committed to a vendor. The fox now has the run of the hen house, and we can expect to pay on average around 50% more for the implementation.

Finally, because process development can be time-consuming, when this isn’t undertaken until after the vendor has been selected, there can be a big gap between initial outlay on software and services. This isn’t great from a cash flow perspective, but also fosters situations in which managers can make rash decisions to speed up a necessarily lengthy process, such as cutting back on user acceptance testing.

Next time around on why the functionality led approach to requirements gathering is fundamentally flawed, I’ll cover the problem of the unknown, unknowns.

An open letter to CRM software start-ups...

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 impatiently trying to fill out the customer satisfaction survey I mentioned yesterday.

This isn’t because I think all CRM vendors are rogues. I do - though some are more loveable ones than others. It’s because if you’re promoting new CRM software to someone who’s been who’s been around the market for a while, they know the life expectancy of a new entrant to the market, and they know – because they’ve helped companies go through it - the expense and pain of replacing a product because the vendor hasn’t got the resources or inclination to develop it anymore, or files for bankruptcy as Entellium did in December. So we – or maybe it’s just me – as a risk averse group of battle-scarred veterans, who see one of their basic roles as managing risk for clients, just aren’t going to be pointing clients to products fresh out of beta.

But OK, let’s say the product’s been around a little while; the initial bugs have been ironed out, you’ve started to build a client base, would we work with you then? Well maybe, and really this is the reason for the post – when would we work with a new on the block vendor? It comes down to one simple question: ‘what do you do better than established vendors?’ because all things being equal I’m going to stay with the tried and trusted. Why? Because I see my role as delivering a game-changing CRM system, a system that can really enhance the client’s business, but with minimum risk. I don’t see my role as implementing the hottest, new technology.

Which brings me to my main concern (and the reason for writing this post) - when I put this question to new vendors the response is generally on the lines of it being easy to use, and at that point my heart sinks. While I understand where this originates from – vendors recognize that there are big issues with user adoption of CRM systems and see technology ease of use as the answer (wrongly I would argue, but let’s leave that for another day) – the problem is that virtually every vendor entering the market in the last 10 years has been ploughing the ease of use furrow, and so even if your product is genuinely, ground-breakingly, earth-shatteringly easy to use I see it as extremely difficult for a new entrant to get traction when everyone is yelling the same thing. (Please see ‘Positioning; The Battle for Your Mind’ by Trout and Reis for a more thorough examination of why.)

So how does a new vendor get traction? I think it comes down to basic strategy: focus on the needs of one sector of the market as Interaction did with the legal market, or differentiate (but not on ease of use) as Salesforce.com did with their ‘no software’ positioning, or be the cheapest as Sugar have looked to do through their ‘commercial open source’ approach.

But whatever you do, to gain our attention at least, it has to offer something overwhelmingly different than the things on offer from the established ‘lower risk’ options, and the ease of use thing isn’t going to cut it; super aggressive pricing, functionality not available elsewhere, a laser focus on the needs of an underserved market, well maybe. Which is not to say that just because this is what we look for, you won’t be successful selling your software, it’s just to explain why we might not bubble over with enthusiasm when presented with something brand new.

Can't get no satisfaction...

‘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 when I first called, I mean really helpful. The local branch were OK, but absolutely insisted on doing the replacement on Boxing Day, and then the operative didn’t actually turn up, and no-one called me to re-arrange, but actually the lady at the call centre did a great job of sorting things out, then the local centre called and weren’t sure the guy they were sending out was really qualified to do the job, but then the chap who did turn up was really friendly and did a great job, other than remarking my car was a little dirty, but hey it was sparkling clean on Boxing Day when I got up early – feeling a little under the weather it should be noted - to wash it when I thought someone was going to turn up’ – I said helpfully.

‘So how would you rate the service you received on a scale of one to five, five being highly satisfied and one be highly dissatisfied’ the lady conducting a satisfaction survey on behalf of the company who had recently replaced my windscreen said testily.

‘Mmm, well a three I guess…..but…’

‘Question two’ the lady interrupted with increasing irritation.

And so it went on. Rather inconveniently my experience didn’t fit very well with the satisfaction survey. I suspect the outcome was that the operative who didn’t turn up probably got a bonus, and the call centre team got taken to task. But it raises the question why bother do a survey if you don’t actually want any feedback? It seems the ultimate irony if the customer satisfaction survey itself becomes a source of dissatisfaction. I mean try it for yourself, wander over to the nearest person, ask them an interesting question, and when they start to answer, put your fingers in your ears, and start yelling ‘la, la, la, la, la, I can’t hear you, la, la, la…….’

Anyway, I wasn’t the only one thinking along these lines – very nice post on the topic from Seth Godin.

The employee experience has never been so important too...

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 not prove immune to the state of the economy, but it struck me reading the coverage how social networking is going to impact the coverage that these changes receive. Once upon a time, unless it was a star CEO, staff members were anonymous. We knew little about them and even less about how they felt about moving on. Now they may well have visible history – they’re in LinkedIn and Facebook – and they may have a voice – through Twitter or a blog. I’ve touched on the need for companies to better manage the customer experience, but the employee experience has never been more important too, because current and former employees have never before been so well positioned to get their opinions heard.