Agile versus Waterfall for CRM Implementation Success


Share on LinkedIn

Comparing Agile and Waterfall CRM Implementation Methods

Waterfall implementation methodologies have been the norm for over two decades of CRM deployments. These approaches are often visually depicted in cascading or linear diagrams and follow a progressive sequence of phases (for example, Requirements to Design to Development to Testing to Deployment). A significant risk with this deployment approach is that it can be unforgiving as success or failure is realized in largest part at the end of the project – thereby severely limiting remediation measures if outcomes don’t match objectives.

Agile methods such as Scrum are an alternative to predictive methods such as waterfall. An agile approach defines the business goals and success criteria in smaller increments, delivers continuous subsets of high-value features and puts them in the hands of users as fast as possible. This provides the development team with faster product verification so they may continue to deliver iterations which align with user expectations or adapt their output to counter for missed or changing expectations.

Agile and Waterfall for CRM

Agile versus Waterfall

CRM software implementation projects place heavy emphasis on the factors of Requirements, Resources and Time. Waterfall methods presume Requirements to be fixed and Time and Resources to be projected.

As illustrated in the below diagram, agile methods flip these factors. Agile presumes Resources to be fixed by capacity and Time to be constrained by time-boxes. This leaves Requirements (aka features) to be flexible and derived from available Resources and Time. The team’s productivity (measured as velocity) will determine the volume of requirements satisfied in a given time-box.

Agile versus Waterfall for CRM

Waterfall CRM Implementations

A waterfall approach begins with clearly defined business requirements which determine the project scope and generate a full life cycle project plan. Work then proceeds and the requirements ultimately get realized as originally specified. This defined or predictive approach may work well when business requirements are clear and business objectives are fixed.

However, if requirements are incomplete, inaccurate or faulty, or the requirements change during the course of the project, the project will march to a mistaken destination. The larger the project, the longer the duration and the more likely the original slated point in time objectives will change or become obsolete during the course of the project. This will cause extra time for change order processes and incur wasted efforts.

Agile CRM Implementations

Agile for CRM is best targeted to large or complex implementations with unclear, incomplete or fluid requirements.

Agile implementations break deployment tasks into short increments with minimal planning and without concrete long-term planning. Each iteration generally lasts between 2 and 4 weeks and is driven by a self-organizing and cross-functional team. Near the end of the iteration the team delivers a working solution that is verified by the user or customer. Each subsequent iteration builds upon the prior for a cumulative effect. This process demonstrates value earlier and continuously, increases project visibility and forecasting, and reduces risk as deviations are recognized more quickly. .

By dividing the CRM implementation into smaller and more manageable increments, development teams can more quickly adapt to incomplete or changing requirements. This reduces waste, rework and project administration while also providing earlier assurance that development delivery meets user expectations.

Below are illustrative diagrams showing how agile and waterfall projects differ in the areas of project visibility, project risk and value.

Agile Visibility Agile Risk Agile Value
With frequent deliveries, inspections and user verification, agile provides continuous visibility of project progress and outcomes. Agile testing is continuous. Delays, defects or missed value are evident with each sprint. Early recognition of these risks permits earlier invention measures. Agile projects deliver and demonstrate increments of value throughout the project. The highest value functions are normally delivered first.
Due to value being delivered at the end of the project, waterfall projects have limited visibility until the end. Waterfall delivery of features and value is held until project completion. Delays or lack of value generally aren’t recognized until it’s too late. Waterfall projects deliver all value at the end of the project. If objectives don’t match outcomes the project will incur waste and rework.

Agile or Waterfall?

While agile methods offer some unique merits it’s important to recognize there is no one size fits all CRM implementation methodology. Below are some of the primary differences that may influence which method is right for any given CRM implementation.



Understood and proven CRM implementation methodology Proven software development methodology; newer to CRM software deployments
Long term planning horizon Short term planning scale
Defined, predictive and sequential planning Adaptive and iterative
More of a top down or hierarchical approach More of a self-governing or lateral team approach
Lots of roles on the project team Few roles (only 3 roles in Scrum)
Roles have varying levels of responsibility Roles share equal responsibility
User interaction concentrated at beginning (requirements gathering) and end (testing) User interaction is continuous throughout project
Better defines requirements up front Requirements evolve and are defined just in time
Less dependent on users during the middle phases Highly dependent on users throughout the project
More process oriented More people oriented
Process steps are strictly followed Low value processes often bypassed
Testing and quality control largely at the end Testing and QA are continuous throughout the project
Disciplined change control process discourages changes Changes are accepted and welcome
Less responsive to change Continually responding to change
Team meets weekly to review project progress Team meets daily to review project progress
Interim project progress measurement is difficult and notoriously inaccurate Frequent deliveries of customer verified features provide sound basis for project progress measurement
Delivery is big bang event at end Each sprint delivers incremental working solutions
Value delivered at end Continuous flow of value
Success is the result of conformance to the requirements Success is the result of business value delivered to the customer

Why the Rise in Agile?

The pace of business change is an overarching influence driving increased acceptance of agile methods.

Agile provides supporting principals and frameworks to organizations incurring increased change. Agile methods will continue to see increased adoption as market forces, industry trends and technology advancements continue to accelerate and require compensating changes to business strategies in shorter cycles. End

Republished with author's permission from original post.

Chuck Schaeffer
Chuck is the North America Go-to-Market Leader for IBM's CRM and ERP consulting practice. He is also enjoys contributing to his blog at


  1. I enjoyed your post but there is something I disagree with. Your vision of Agile is too pessimistic. It’s not only a newer approach that can solve any problem – there are projects where it suits best. And there are those where it doesn’t work at all. For example, in large and complicated projects. Too messy.
    If you want to learn more about the Agile drawbacks, check out the link in the description.

  2. Thank you for your comment. I’m an agile advocate, and my last 6 large CRM implementation projects over the prior 6 years have all been agile. However, I agree with your point (and I hope my article reflects) that there is no one size fits all answer to complex challenges.

  3. I making the most of your post however there is something I can’t help contradicting. Your vision of Agile is excessively cynical. It’s not just a more current methodology that can tackle any issue – there are projects where it suits best. Furthermore, there are those where it doesn’t work by any means. For instance, in huge and confounded ventures. Excessively untidy.

    On the off chance that you need to get familiar with the Agile downsides, look at the connection in the depiction.


Please use comments to add value to the discussion. Maximum one link to an educational blog post or article. We will NOT PUBLISH brief comments like "good post," comments that mainly promote links, or comments with links to companies, products, or services.

Please enter your comment!
Please enter your name here