Waterfall V Agile for CRM projects – why the choice of implementation approach matters

March 2, 2015 Richard Boardman

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.