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.


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


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.


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


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.

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

6 thoughts on “Waterfall V Agile for CRM projects – why the choice of implementation approach matters”

  1. Thanks Richards, always enjoy your articles and thanks for shedding light on what these different implementation strategies mean. I had a vague understanding as I often here these terms thrown around at meetings (I’m new to the IT workforce); this article helped clear my understanding.

  2. Hi Richard, I’ve been using the agile Scrum methodology to implement CRM systems since 2008 and have presented on this topic at a number of CRM user group conferences. I’m not sure that it’s easy to estimate timelines and budgets with a traditional methodology — most government IT projects use PRINCE and aren’t exactly famous for on-time and on-budget delivery. I like Scrum’s lightweight framework, which can be transitioned into Kanban after the system is released. There’s no reason why agile projects should be undocumented, either as a story or as a ‘definition of done’ with every story.

    My main challenge with Scrum is trying to secure the availability of a product owner to provide their vision, elborate on stories, accept finished stories, groom the backlog and prioritize each sprint. It’s a significant time commitment, to be sure. Delegating some of these tasks can work, but can lead to rework when the real product owner has a different viewpoint than the delegate.

  3. I have found the same issue as Neil in Agile projects – as a BA, you naturally take up the role of Product Owner as the project progresses – but of course you’re still out there finding new User Stories, you have older Stories which need elaborating on, things getting pinged back to you for comment, UAT issues coming back to you, and as Product Owner / BA you’re best positioned to get a good, solid definition of issues from the business… you’re in UAT sessions, all kinds of meetings, all kinds of Stories to attend to in all kinds of states…!

    It can get a bit disorientating and chaotic. Especially if you’re running a hybrid waterfall / agile environment (which I prefer) where you’re doing fuller process analysis up front and then distilling that into Use Cases / User Stories.

    There’s probably a lesson about resourcing in there… I would personally have the BA / Product Owner role doubled up, with some time spent running through Stories together, pair-programming style. Otherwise it can easily become a bottleneck as the project progresses.

  4. As someone who has seem a past organization I worked for struggle heavily with both Waterfall and Agile, I highly recommend that Agile practices be left to only organized, talented teams that fully understand the concepts behind Agile. If you have senior management that wants a high degree of control over timelines, don’t sell them Agile.

Leave a Reply

Your email address will not be published. Required fields are marked *