Piloting is Critical for Successful CRM Technology Implementation

2
385

Share on LinkedIn

I was talking to the sales director of a respected Campaign Management System (CMS) vendor a while back at their regional user group meeting. He was marveling at a Swiss bank client who had bought the full implementation of their CMS system for a cool EU€ 1,000,000 but who had not used the CMS a single time to run an actual marketing campaign! This may have been a peculiarity of the Swiss bank’s budgeting cycle, but it might just as easily have been the result of difficulties using the CMS to enable the bank’s daily marketing business. It reminded me of some of my own difficulties using the same CMS and with the vendor relationship at Toyota. Difficulties that eventually got the vendor and their CMS unceremoniously thrown out in favour of a simpler solution.

The Swiss Bank and my own experiences reminded me how critical it is to go through a robust piloting process when implementing new CRM technology. A well-designed, carefully run pilot often makes the difference between technology that creates value for the business and technology that just turns into an expensive white elephant.

There are five factors that drive success in the piloting of new CRM technology:

  1. View Pilots as Capability Buildout NOT as Technology Implementation – As has been widely pointed out, implementing new technology is never enough by itself (sorry vendors!). What also has to be developed is all the complementary things such as, processes, data flows, work routines, performance measures, etc, that together, and only together, deliver value for the business. Vendors often don’t like this focus on capabilities, as they see it as slowing down the technology implementation. Resist their pressure to concentrate on the technology at the expense of building out broader capabilities, it is your business not theirs. There is both extensive research in economics and extensive case studies in CRM, BPR, ERP and TQM demonstrating the validity of this approach.
  2. Base Pilots on Enabling Daily Business NOT on Technology Implementation – If new technology is to be successful, it must enable the work that staff needs to do. Daily business in other words. This sounds obvious, but it isn’t always put into practice. Far too many pilots are run too prove the technology can be implemented, not to enable actual work to be done. To overcome this problem, the technology selection and subsequent pilot should be based around a detailed understanding of the work that users must do each and every day, in particular, on the jobs that users are trying to do and the outcomes they are trying to achieve by doing them. This is a relatively new way to drive technology selection, but it is far more effective at selecting just the right technology to enable daily business to be done than the traditional requirements analysis, which tends to generate long non-value-adding requirements wishlists and fuels value-destroying technology feauturitis.
  3. Run Pilots as Internal Corporate Ventures NOT as IT Projects – Too many pilots are just run as light versions of full technology implementation. I have leant to run them as though they were internally-funded venture projects. That means a capability audit first to understand what capabilities the organisation has, what will need to be built and who is going to have to be involved in the pilot. Then a detailed paper pilot that looks at how the whole thing will work, step-by-step, and what will stop it being successful. Then an alpha test of the working kit and complementary stuff with most of the interfaces run manually. This allows you to learn how to make the kit and complementary stuff work before you automate it. There are always many teething problems, irrespective of how much you plan. Finally running a fully automated beta test with the kit, the complementary stuff and key operational staff all involved. All this typically takes 90-100 days. Then you are ready to expand to a fullimplementation.
  4. Balance Piloting Implementation with Learning and Early Value Delivery – It is all too easy to see pilots as just a step before full implementation. This is short-sighted. A pilot is much more than that. In particular, if they are designed properly, they are great opportunities to learn things that you don’t yet know and which are critical before embarking on a full implementation. Designing pilots explicitly to learn unknowns during each step of step of the piloting process, both reduces future implementation failure and provides valuable information to help you nail down how the full implementation will drive economic value creation. And let’s not forget that we should be using the pilot to actually create some of that early economic value too. Why pilot e.g. a campaign management system, if you can’t reduce operational costs, increae revenue generation and reduce customer value at risk in the process?
  5. View Pilots as Advanced Vendor Qualification – Vendors are very good at selling their technology. They have to be. But they are often rather conspicuous by their reluctance to provide the full range of suport you need to get the most value out of their technology once you have signed on the dotted line. Yet 99% of the value of implemented technology is delivered in the months and years after you have signed. The pilot is a great time to stress-test the relational qualities of the vendor before you commit to them over the longer term. You are committing to the vendor as much as, if not more than, you are to their kit. This is a lesson I learnt the hard way at Toyota.

It is amazing what you can do in a 90-day pilot if you plan explicitly to do so. Some vendors won’t like it, but they are probably not the vendors you should be working with over the long-term anyway! At the end of the day, CRM technology is an essential enabler of modern customer-driven business. But it is just one of many enablers. The pilot is your only way top prove that there really is value in it before you sign on the dotted line.

What do you think? Are you happy with your existing CRM technology implementations? Or are you using alreaedy pilots to extract the maximum of value from expensive CRM technology?

Post a comment or email me at graham(dot)hill(at)web(dot)de to get the conversation going.

Graham Hill
Customer-driven Innovator
Follow me on Twitter

Graham Hill (Dr G)
Business Troubleshooter | Questioning | Thoughtful | Industrious | Opinions my own | Connect with me on LinkedIn https://www.linkedin.com/in/grahamhill/

2 COMMENTS

  1. Several people have asked which CMS vendor was thrown out of Toyota and why.

    The vendor was Unica and its Affinium product. Unica’s Affinium was chosen to operate Toyota’s customer lifecycle programme. The reasons they were thrown out were threefold:

    1. Affinium was too complex for Toyota’s needs. It required a lot of expert programming and had a number of ‘bugs’ that made using it rather challenging, even for the expert programmers
    2. Unica’s follow-on pricing was too expensive for what was on offer and they were not accomodating to Toyota’s requests for value-based pricing
    3. Unica failed to provide the expected support for the marketing agency eventually tasked with running Toyota’s customer lifecycle management programme.

    Of the three factors, the one that Toyota refused to accept was Unica’s unwillingness to support Toyota’s chosen marketing agency. Toyota places a huge emphasis on creating mutual value together with its suppliers. Unica’s unwillingness to do this with Toyota was the straw that broke the camel’s back.

    This example just goes to show that selecting the right vendor is just as important as selecting the right tool. On this occasion, Unica was the wrong vendor for Toyota. Unica does work very successfully with many other large organisations. It’s a question of chemistry, flexibility and relational fit.

    Graham Hill
    Independent CRM Consultant
    Interim CRM Manager

  2. Hi Graham,

    I agree with your points completely – but from experience and if I really wanted to “defend” vendors (as I am on this side :)) – the point is some customers are not willing to see that the end result is marketing-oriented and not IT-oriented. How do you tackle this where the IT organization is quite powerful and they take the upper hand?

    Cheers,
    Raghav

ADD YOUR COMMENT

Please use comments to add value to the discussion. Maximum one link to an educational blog post or article. We will NOT PUBLISH brief comments like "good post," comments that mainly promote links, or comments with links to companies, products, or services.

Please enter your comment!
Please enter your name here