August 27, 2018September 9, 2018 Richard Boardman

How to speed up a CRM project

As a CRM consultant, I get into a lot of conversations with clients about how long projects are going to take, and, invariably, our guidance on average project duration is longer than they were expecting. Which, in turn, normally elicits a question along the lines of ‘can this be sped up?’, and the answer is generally ‘yes’.

So, in this post I’m going to cover some of the ways of speeding up a CRM project:

Truncate the fuzzy front end – I love the description of the ‘fuzzy front end’ which I think I picked up from Steve McConnell’s book ‘Rapid Development’. This refers to the time that organisations are thinking about a project, rather than actually progressing it. Projects can languish in this pre-commitment phase for a considerable period of time, often much longer than the main project itself. So, one of the simplest ways to significantly speed up a CRM project, therefore is to move more quickly from initial need to project kick off.

Detailed business and functional requirements done up front – Regular, or, frankly, even very occasional readers of this blog will know my fixation with detailed requirements being done up front. [There’s an ebook here for anyone wants to know why, what, how etc.].

There are a number of reasons specifying detailed requirements up front speeds things up: firstly, without detailed requirements potential suppliers can only provide ballpark estimates. These will need to be firmed up once the supplier starts work on the project. However, the supplier, now contracted, and no longer in competition with other suppliers, has less incentive to provide competitive costs, and, worse, may elect to exploit the situation, and final estimates can often prove substantially higher than the initial ballpark. Which means the poor system-buyer can either swallow the, potentially, ballooning costs, or, begin the process all over again with a new supplier. I’ve seen organisations spend, very literally, years repeating this cycle with different suppliers.

Secondly, it lessens the likelihood of ‘scope-creep’ where the project is delayed by the need to accommodate ‘unforeseen’ requirements being discovered during the implementation phase. And, finally, a detailed system model up front, will reduce the work that needs to be done downstream.

Free up resources and/or contract in – For most organisations the biggest impediment to moving at speed through a CRM project is ‘business as usual’. In other words, people still have their day jobs to contend with, which can severely limit their available time. The more you can free people up from the day job to focus on the project the quicker things will move. Alternatively, or, better, in addition, contracting in resources who can focus on the project can also make a big difference. Perhaps one of the key roles to fill is that of the project manager. The more experienced, capable, and available the CRM project manager the quicker things are likely to move.

Speed up procurement – Some organisations are mandated to go through a structured procurement process which might involve a multi-week/month invitation to tender process, but others have a lot more freedom. Procurement can be a big slice of the overall CRM project, and it’s possible to cut out a lot of time here. Making use of independent CRM consultants to help identify the most appropriate CRM technologies and reliable implementers can speed things up, as can dropping complex tendering processes for something lighter and quicker. The other area to watch out for in procurement is the legal side of things. If you need lawyers to vet contracts, it’s best to start this as early as possible in the process, otherwise it can extend procurement significantly.

Select a good implementer – While speeding up procurement can save time, it’s important that it results in a reliable implementer. Nothing slows a project down quite as much as an incompetent supplier, particularly if it’s a complex project. In my experience there are a lot of good CRM implementers out the, but there are even more bad ones, so leaving things to chance isn’t a great plan. Taking the trouble to ensure that you’re engaging with a capable supplier will pay big dividends in the speed of deployment.

Phase it – You will get live quicker if you don’t try and do everything at once. The pareto principle often comes into play here – 20% of the capabilities may give 80% of the benefits. If you can strip out, or postpone, unnecessary, or less critical, frills and complexities, you can often reduce deployment times significantly.

Plan it – The earlier you can get things in people’s diaries the better. Projects get delayed because of the need to potentially schedule multiple diaries for key activities such as design workshops, system play-backs, testing, training, and milestone sign-offs etc. Getting things in diaries early helps avoid delays coordinating diaries. The supplier-side project manager should be a helpful guide in this respect, though it should be noted their planning is likely to be more focused on their own activities rather than yours. As I mentioned previously, having your own experienced project manager can make a big difference in this respect.

Keep it agile (sort of) – I’m not going to go into the pro’s and con’s of agile versus waterfall implementation methodologies (I did it here though), but suffice to say it’s wise for it to be sufficiently agile to ensure that you’re not in a situation where, at the end of the development phase, you’re reviewing something that looks nothing like what you’re expecting. Getting visibility of development as it progresses, avoids nasty surprises downstream and heads off issues before they create delay.

Keep tight control of UAT – I will probably write more about user acceptance testing (UAT) in a later post, but this is one of those phases that can really extend if things aren’t properly controlled. The first thing is to ensure that what gets delivered into test is of high quality. This helps reduce the rounds of testing you need to go through before you can sign off. This is partly a function of finding a quality implementer, which we discussed earlier, but also a case of ensuring the supplier capably performs their own testing programme before they release to UAT.

The other key is to ensure there is resource scheduled to fix the inevitable issues that do arise, something that often seems to get forgotten, with projects held up as you try and schedule the original developers back on to the project to get issues remedied.

In summary, the methods outlined above can help dramatically reduce project times, often by 50% or more. And the sooner you go live the sooner you start to realise a return on your investment in the system. Well sort of. In truth the ROI occurs once you get people using the software – consistently and systematically. In the next post (which can be found here) I will cover how to reduce the time between go-live and comprehensive user adoption.