If you’re implementing a new CRM system and have been talking to potential vendors about how they would approach a project, I suspect the word ‘agile’ features strongly in their presentations.

Go back a few short years though and you would have been hard-pressed to hear the word ‘agile’ being used in many conversations about implementing CRM systems. Back then the waterfall methodology was king. Today it sometimes feels like heresy just to suggest there’s any viable alternative to agile.

But, does it matter? Does it matter that my implementation partner is planning on using an agile approach or a waterfall approach? The answer is ‘probably’, and a possibly ‘a lot’, and it really does pay to understand how each approach works because each has its strengths and weaknesses and ultimately you may find one works considerably better for you than the other.

First though let’s consider each methodology, what is it, and what are its strengths and weaknesses? I will start with what’s known as the waterfall methodology as this is probably the most traditional of approaches.

The Waterfall Approach

Waterfall is a sequential approach to implementing a system. It tends to follow a series of steps culminating in the delivery of the product. These steps typically include: requirements definition, design, development, testing, fixing and going live. The approach tends to be quite documentation hungry and is centred around the design phase where a detailed specification – which can often run to several hundred pages – defines what the developers will create. If what’s developed doesn’t quite meet the need, then this tends to be handled through a change control process.

Pro’s

The strengths of the waterfall approach include:

  • Deliverables are clear from early in the project
  • It’s relatively easy to estimate time-lines and budgets
  • It’s easy to swap people in an out of the project because of the level of documentation
  • The demands on the customer are relatively light
  • The overall design of the system of the system can be optimised because all deliverables are understood up front

Con’s

The weaknesses include:

  • Design specifications can be challenging and time-consuming to review and it’s often difficult for customers to envisage the end product, which means that what gets signed off isn’t always what was intended
  • If deliverables don’t match expectations, this is going to be discovered very late in the process which can lead to significant unforeseen additional costs and delays
  • If projects do come under time pressure, then, with testing the last activity, there can be a temptation to cut corners in this key area

The Agile Approach

In contrast to Waterfall’s linear step by step approach, the agile methodology starts with a more simplistic project design and seeks to break the project down into a series of deliverable modules which are built through a series of what’s often referred to as ‘sprints’. Each deliverable is tested and reviewed by the client, and that feedback is incorporated into the next sprint, which means the customer is an essential component of the development team.

Pro’s

The strengths of the agile approach include:

  • The customer gets to see and touch the software early in the project and can directly shape the development of the system
  • Customers are often only able to properly articulate their needs when working with the actual product
  • It’s easier to accommodate change if new business requirements crop up
  • It can be a very quick way of deploying

Con’s

The weaknesses include:

  • It relies on customer representatives who can make quick decisions on behalf of the business to be heavily available for the project, something that’s not practical for all organisations
  • It’s harder to manage budgets and timelines because the deliverables are less clear up front
  • Some vendors may exploit what is normally time and materials billing rather than fixed or firm costs in the case of waterfall
  • Losing key project team members can be very disruptive because this approach is typically light on documentation
  • The approach does need to be skilfully managed to avoid the risk of the project losing sight of the overarching business objectives

Having worked with both methodologies, in my view waterfall tends to suit situations where:

  • There is a need to have tight control of costs and timelines
  • Where the customer has a clear view of the requirements and deliverables
  • Where active day to day involvement from key customer decision-makers isn’t practical
  • Where there a complex development and integration requirements

And agile tends to suit:

  • Simpler projects
  • Situations where the customer doesn’t have a clear view of the end deliverables
  • Customers who are able to make the appropriate people available to the project
  • Where requirements may be subject to change
  • Where there’s a requirement to deploy fast

The reason for writing the post was to stress that the implementation approach is important. There is no ‘best’ methodology. The choice should depend on the individual circumstances of the project. Buyers of CRM technology should carefully consider what approach is likely to work best for them, or, at the very least, if there’s an approach isn’t going to work for them, and that should be a factor in selecting the implementation partner for the project. Not all partners are proficient in, or practice, both methodologies, so finding someone with a track record in your preferred approach is an important consideration.

ShareThis
[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]

{ 0 comments }

A guide to phasing a CRM project

by Richard Boardman on January 11, 2015

In my recent series on requirements gathering, I noted the need to document the phasing of a CRM implementation. I’ve come to the conclusion over the years that phasing is one of the most critical aspects of implementing a CRM system successfully, and so figured this might merit some further elaboration.

Perhaps the starting point is to explain what I mean by phasing. Phasing relates to how you go live with a project. Whether you go live with everything in one go – often known as a big bang approach – or whether you break the project down into a series of go-lives over time.

Generally projects are phased based on or a combination of: organisation structure – the Birmingham office will go live in March and the Manchester office in April; process area – we will go live initially with contact and sales pipeline management, then lead management; or functionality – the integration with the finance system to support customer management will be in phase two.

The timing between phases may be relatively brief, perhaps days or weeks, or there may be long gaps between the different stages of the project.

The reasons for phasing a project include the following:

Budgetary considerations – there’s not enough funding to implement all the defined requirements in the short term

To avoid disruption – to reduce the impact on business as usual activities

To road test – to test and refine a system with a smaller unit before it’s rolled out to all staff

To assist with change management – it takes a lot of time and resources to get users adopting a system in a consistent and structured way, and reducing the amount of change makes it easier to embrace new technology and avoids overwhelming internal resources

Some of the factors to consider when planning the phasing of a CRM project are:

Priority – this should generally be focused on the areas of greatest need. What are the main pain points? Where can technology make the biggest difference? Doing something meaningful in the first phases is key to garnering the commitment to a project over the long term.

How much change can users embrace? – there’s a big difference between replacing an existing system and staff using a CRM application for the first time. Understanding how quickly users can embrace a new system is a critical aspect of phasing.

Resourcing – realistically, how much can the people we have available support at one time? Given that user adoption can be surprisingly challenging, this may be less than you think.

Metrics – what metrics will we judge progress on? There’s no point moving to phase two if phase one hasn’t been successful. Defining how we determine ‘success’ is key. Project staff need to be carefully monitoring adoption to determine if staff are using the system, and if it’s producing the desired results. The roll out schedule needs to reflect what’s happening on the ground and be adapted if necessary.

Learning – One of the keys to speeding deployments up is to learn from every phase. Analysing each one and looking to improve how it’s deployed and supported can make a big difference to the time it takes to fully roll out a system.

Maintaining momentum – when a project is phased it’s critical to maintain the momentum across all phases. There’s a natural desire, having gone through the arduous process of gathering requirements, selecting a vendor, development, and testing, and getting the first users live, to want to rest up for a while. It’s easy however for momentum to be lost at this stage, so having a clearly understood plan as to what is happening, and when, is key to keeping things moving forward.

Most projects can and should be phased. Organisations commonly underestimate how long it can take and how much is involved in getting users to use the system consistently. Trying to do too much too soon invariably results in an investment in technology that does very little. The focus needs to be on ensuring the system achieves meaningful operational goals, not on ticking the box that the project is complete.

ShareThis
[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]

{ 0 comments }

How to document requirements for a CRM system – part 6

January 4, 2015

In a previous post in this series I set out my thoughts on the content and structure of a CRM requirements specification. In this post I want to cover how to go about gathering them. The starting point, if you’re not reasonably familiar with CRM technology, is to do some initial research. It’s very difficult [...]

Read the full article →

How to document requirements for a CRM system – part 5

December 13, 2014

Last time out I described what I’d expect to see in a decent CRM requirements specification. Putting this sort of document together isn’t a trivial exercise, but the payback from the time invested can be huge. Here are some of the key benefits of this sort of approach: Increased return on investment – the focus [...]

Read the full article →

How to document requirements for a CRM system – part 4

November 30, 2014

In the fourth of this series of posts about CRM requirements gathering, I wanted to cover content. So what needs to be included in a CRM requirements document? The following covers the main areas I’d hope to see: Approach This section sets out how the requirements were gathered, and, importantly, who was involved in the [...]

Read the full article →

How to document requirements for a CRM system – part 3

November 23, 2014

I promised in last week’s post that this week I’d set out my views on what should be included in a CRM requirements specification. However, I’m going to put that on hold for a week. I realised there were some points that merit some articulation first. So, to help set the scene, here are a [...]

Read the full article →

How to document requirements for a CRM system – part 2

November 16, 2014

In last week’s post I covered some of the common problems with specifying CRM requirements. In this post I want cover purpose. In other words what are we trying to achieve with a CRM specification. In this respect, I believe there are five key objectives: 1. Identify suitable technologies – by setting out the functional [...]

Read the full article →

How to document requirements for a CRM system – part 1

November 10, 2014

As an independent CRM consultant I get to read a lot of CRM requirements documents, and it seems to be an area that most would-be buyers of CRM technology struggle with – probably because there’s little guidance out there about how to approach the exercise successfully. This would be less of an issue if this [...]

Read the full article →

Last quarter’s CRM market news in 60 seconds…

July 19, 2014

In case you missed them, here’s my 60 second bullet point round-up of the main CRM software stories last quarter: April Salesforce.com take a cue from Amazon’s ‘Mayday’ customer support feature on the Kindle Fire to add a new SOS capability to its Service Cloud which enables customers to be connected to a support representative [...]

Read the full article →

Getting closer to the coal-face to get more out of CRM technology…

June 7, 2014

I’ve been having one of those ‘I’d long known it was important, but I’d forgotten just how important’ moments in recent weeks. One of our clients has recently gone live and, in the absence of a colleague who was away on honeymoon, I found myself providing go-live support which involved parking myself in the midst [...]

Read the full article →