18 ways to speed up a CRM project – part two

In my last post I set out nine of eighteen ways to speed up a CRM project, focusing principally on pre-implementation activities. This post outlines ways to speed up a project once the implementation begins:

Don’t do too much in phase one – there’s only so much change an organisation can absorb at any one moment anyway, so one way to get things moving faster is to limit the objectives of the first phase of deployment. That said phase one must achieve something meaningful otherwise you will struggle to get the attention and resources the project needs to progress any further. Don’t get suckered into the ‘run with it out of the box and see how you get on’ approach that some vendors seem to promote. While this may increase vendor software revenues, it won’t create a system of value.

Be ruthless with customisation – the more customisation you have, the more development and testing time. In most CRM deployments there are ‘frills’ – pieces of customisation that get created but don’t add any value. These are capabilities that people feel they need during requirements specification, but prove to be white elephants once the software is deployed. If you can be ruthless in trimming the frills and culling the white elephants you can often slash deployment times. Limit customisations to areas that clearly will generate value. If there’s any question, deploy without them, and add them later if required.

Find a great vendor and get their best people – there’s a huge difference in productivity between a great implementation consultant and a mediocre one. If you can find a competent vendor and secure their best people, you can get a lot more done a lot more quickly, and considerably reduce the amount of time involved in fixing issues uncovered in user acceptance testing (UAT).

Find an approach to system design that works for you – in my surviving CRM design hell post I pointed out that most vendor design documents are impenetrable tomes that take a long time to read and comprehend, and invariably result in users signing off something they didn’t intend, which then has to be resolved through the change request process, adding significant delay (and cost). I will set out my thoughts on fixing the design process in a future post, but if you want to avoid delays make sure your selected vendor has an approach to design that you are comfortable with. This should include making sure design documentation is clear, concise, and that potentially problematic or controversial areas are highlighted.

Get visibility of the development work as it progresses – no matter how clearly the design is documented there’s generally some mismatch between what you expect and what is delivered at the end of the development process. If you can pick these issues up early by having sight of the development work as it progresses, you can save a lot of time in the UAT phase.

Make sure vendor resources are pre-allocated – as I mentioned in the last post, if a project is to move fast, it’s important that the vendor has quality resources available to start the project as early as possible. It’s equally important to ensure that resources are in place to help you through other key milestones such as the design sign off or user acceptance testing. From my own experience a lot of projects get delayed because vendor resources aren’t available when you need them. So, for example, at the end of the testing phase you can suddenly find the lead developer is away on holiday or has been sent off to another project. It’s important, if you want to move rapidly therefore, to ensure up front the vendor has the right staff allocated and available to cover all aspects of the project. And when I say ‘right’ staff I mean the same experienced personnel that have been used throughout the project. Trying to roster other people in who happen to be available, but have no previous knowledge of the project, and therefore invariably no sense of ownership, generally produces more issues than it fixes. It should be noted, for this pre-allocation of resources to work, you will need to be working with a clearly defined and achievable project plan.

Insist on quality delivery – one of the biggest determinants of project duration is the number of bugs that come out of user acceptance testing and the number of cycles of development and testing required to resolve them. The number of bugs in turn is determined by the quality of development resources and the rigour of internal testing prior to release into UAT. If the vendor wishes to cut corners they can cut back on the internal testing which increases the bug count in the UAT stage. Therefore motivating the vendor with an appropriate combination of carrots and sticks to deliver high quality product into testing can have a big impact on reducing project time-lines.

Speed up milestone sign-offs – the sign-off of any project milestone has the potential to cause delay. Making sure that the internal resources are available to quickly sign-off stages such as design, testing and pilots, is essential to making rapid progress. Again, as mentioned earlier, this is significantly helped by defining an achievable project plan and sticking to it. The other aspect of sign-offs that can be sped up is the communication with the vendor. It’s often a lot quicker to facilitate direct communication with the vendor to hash out issues rather than rounds of emailed documentation. Getting everyone in a room and locking the doors until agreement has been reached can be a very effective means of avoiding undue delay.

Identify and manage the risk areas – there are certain aspects of a CRM project that are particularly vulnerable to overruns. Data and add-on modules (third party products that fill gaps a vendor’s out of the box offering) are two examples. Understanding where the main vulnerabilities lie and effective contingency planning are key to keeping things on track.

As I noted in my ‘How long does CRM really take post’, CRM projects, strategic, value enhancing ones at least, take a lot longer than people expect. That said, the points set out above can go a long way to speeding things up, or at worst avoiding things taking any longer.