<img src="https://secure.leadforensics.com/133892.png" alt="" style="display:none;">

One of the first decisions you’ll need to make for your implementation project is which approach to take. Agile vs waterfall is a popular topic and just to make it clear, they’re both types of implementation methodology, not a style of project management (though you might hear these terms used interchangeably).

Microsoft Dynamics 365 CRM solutions, such as Sales, Customer Service and Field Service, lend themselves to a more Agile approach given the relative ease the solution can be configured or customised, but what are the right conditions for Agile to be successful? And when does waterfall work better?

In this blog post, I’ll be explaining what these two implementation methodologies involve and help you choose the right one for your business.

A quick foreword before we start: Your choice of approach won’t determine whether your project is a success or a failure. Most of the time, it’s not a failure of the methodology that causes a project to fail (or indeed to be a stellar success) – it’s normally down to a failure of an associated step or component within the project.

What is the waterfall methodology?

Over the years, this implementation method has been the best way to navigate the often complex and business-critical areas covered by ERP. Most of the large-scale ERP implementations that were used to transform finance, supply chain and manufacturing processes – often based on SAP or Oracle – were implemented using a waterfall methodology.

Without going into reams of detail, the waterfall methodology is so named because it’s often portrayed as a set of waterfalls, with linkages between these waterfalls dropping sequentially.

Waterfall methodology

The linear approach demonstrated by the waterfall methodology

The implementation partner will spend time gathering requirements for the complete project. Most platforms such as Microsoft Dynamics, SAP and Oracle have “best in class” processes pre-defined in the software.

However, every business does things in different ways, and so the process of gathering requirements allows the implementation partner to understand:

  • What fits
  • What is a gap
  • Whether the gaps are critical, and whether the business will move towards the software or want the software to change to suit the business

The partner uses this information to design a solution that will elegantly fit the customer’s needs. Once this is signed off, system build ensues and the solution is integrated into other applications. Finally, the business “system tests” the application and then it gets moved from Test into Live operation.

 

What is the Agile methodology?

The need to deliver early results through any solution implementation is becoming increasingly important to many customers. While the more traditional Waterfall approach has been around for a while, it arguably tends to result in ‘hands on’ being towards the end of the implementation process.

As a result, Agile has been pushed forward as the alternative delivering a faster approach and getting ‘hands on’ much quicker to yield much earlier benefits.

However, adopting an agile approach to implementations isn’t the nirvana everyone believes it to be and contrary to belief, it often doesn’t lead to a faster implementation. In fact, this type of project is much more demanding on the time allocated by the business.

Agile methodology

The team-based approach demonstrated by the Agile methodology

Agile implementations look at the project and then slice the project into much smaller chunks. Each chunk is then treated as a mini project of its own, with these “sprints”, then driven sequentially.

Within a sprint, the “Scrum-master” drives a combined team from the implementation partner and the business, and the sprint focuses on one small functional area of the overall solution.

There are two key benefits of this:

  • The business gets very early access to the software and that from an early stage, the elements of the overall solution get into the hands of the business
  • If there are required changes, they can be recognised much earlier in the project and then dealt with in the ensuing sprints (in contrast to the waterfall approach where issues are noticed at the end - when it's arguably, as some would say, too late)

Below is an example implementation of Microsoft Dynamics 365 (D365) Sales. The D365 Sales solution could have seven or more of these sequential sprints, with each sprint taking less than 2 weeks to complete.

Agile methodology example for D365

Agile vs waterfall: A side by side comparison

Now that we’ve covered the basics, it’s time to move onto the pros and cons. To help you digest this information more easily, I’ve put the pros and cons into a handy table. If you’d like to read the information in more depth, check out this blog where I dive deeper into the points.

The pros and cons of waterfall

Pros

Cons

It’s a method that’s been around for many years and the process is well-documented.

The modern-day world is very fast-paced and the business landscape can quickly and easily change. A waterfall project is often long (sometimes taking more than 12 months) so by the time your solution is deployed, it may no longer fit your needs.

The majority of implementation experts know this methodology very well and are technically experienced enough on it to easily navigate potential pitfalls.

Your users don’t often engage with your new solution until the system testing stage, which is right at the end of the implementation project. So, acceptance and adoption can become an issue.

It’s very well-suited for large-scale, complex implementations, hence its popularity with global businesses who opt for phased rollouts.

There’s a chance that your end solution isn’t the right choice or fit for your business. Unfortunately, it’s near-impossible for this to be recognised or fixed until it’s too late and would cost a significant amount to rectify.

The pros and cons of Agile

Pros

Cons

Your users can engage with the new solution from the start so gaining their buy-in is much easier.

It’s time-consuming for your team, especially your business leaders.

Potential issues can be flagged and resolved before they become a problem (and significant costs are required to fix) - e.g. if the fit isn’t 100% right.

Your business leaders need to be involved as the approach requires people who know the business inside and out and have the power to make key decisions.

Minimal system testing is needed as your users can access the solution from the beginning and should have a good understanding by the end. This shortens the project timeline.

It may need frequent refactoring which can be time-consuming. Without this, the quality of the new solution can be affected.

 

So, which should you choose: Agile or waterfall?

As I mentioned at the start, your choice of implementation methodology won’t determine the success of your project. Success is defined by how well you conduct and complete associated steps/components within your project. So, it’s difficult to say one methodology is better than the other.

I recommend you think through the benefits of each approach and the potential pitfalls and drawbacks. Your biggest consideration should be around the ability of the business to commit the resources for an Agile project, and to empower them to make the decisions quickly.

The benefits of Agile methodology

In other words, do you have the resources required for an Agile project? If your business is tight on resources or decisions aren’t delegated to the team engaged on the project and they don’t understand the new landscape well enough, then maybe Agile is not the best approach for you.

However, if you’re able to manage these requirements for Agile to work, then in my experience, I’ve seen a higher success rate and happier customers with higher adoption rates in customers where we’ve implemented using an Agile approach.

A final and cautionary note – do not go into Agile because of the ‘hype’ or because you want to save money on the implementation time or cost. Agile implementations can be shorter or longer, less expensive or more expensive than waterfall - it depends on the individual project.

However, despite Agile being more demanding on your business, it gets you more hands-on earlier in the process. And this normally leads to a more suitable overall solution for the business.

How to ensure your implementation project is a success

The right system and methodology aren’t the only elements crucial to the success of an implementation project. You also need to work with the right partner. At Columbus, we’re highly experienced in system implementation projects, such as CRMs, but we’re not here to sell you the benefits of working with us.

In our guide to CRM implementation projects, we cover the best practices you should follow, pitfalls to avoid and the pros and cons of working with an implementation partner compared to keeping it in-house.

Click the button below to learn more.

CRM Implementation

Topics

Discuss this post

Recommended posts

Having been involved with ERP over a number of years from a customer perspective, I’ve seen how the right ERP solution can help transform the way a business performs and brings all the relevant data and processes together under ‘one roof’. 
A modern CRM system can benefit a business of any size and industry. But you need to ensure you’re not just implementing the right one but also that you’re doing it at the right time. Here are some signs that indicate it’s time to look for a CRM system…
The quality of your field service contributes to your overall customer service and experience. Great field service is one where the engineer arrives promptly (even better if they arrive before the customer realises there’s an issue) and fixes the problem the first time around. To ensure that, you need the visibility to assign the right engineer to the right task at the right time. That’s where a field service management solution comes in.
right-arrow share search phone phone-filled menu filter envelope envelope-filled close checkmark caret-down arrow-up arrow-right arrow-left arrow-down