Agile versus Waterfall for CRM Implementation Success
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 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.
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 or the longer the duration, 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 1 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.
 |
 |
 |
| 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.
|
Waterfall
|
Agile
|
| 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.