Waterfall vs Agile Project Management for Salesforce Implementations

Waterfall vs Agile Project Management for Salesforce Implementations

Our partners at Idealist Consulting are hearty evangelists of agile project management. They find themselves in conversations about how key it is to minimizing risk in Salesforce implementation projects so wanted to share some of their reasons. This guest post comes from Idealist Consulting’s CRM Admin Consultant Ashley Bochiechio.

As a Salesforce consultant, I have worked on projects which use agile project management as well as projects which strictly adhere to a traditional waterfall approach. Remember the difference? Agile project management follows a project structure of design, tweak, repeat, launch, improve. Waterfall, on the other hand, is a style of project management which focuses almost half the scoped time on the creation of a highly detailed design document (an all-inclusive document listing what will be implemented for a given project). Based on my experiences, I have developed a strong preference for agile. In the great race to implement Salesforce, time is always of the essence, but not only that, your project risks will be much better managed through an agile approach.

Here is why should you insist on seeking out an agile consulting firm as your partner.

Why Waterfall Leads to Higher Risk

Before I sing the praises of agile, let’s look a little closer at the design documents involved in waterfall-style implementations. Typical design document will include business process, lead and opportunity lifecycle, email templates, any custom fields with respective values, role hierarchy and custom profiles, and many more. The only problem is, they just don’t work for Salesforce implementations.

The real use for a design document is to provide an insurance policy for the consulting company, disguised as a security blanket for the customer. No customer will ever be able to develop a lucid picture of the proposed system by reading a design document. So when the project derails the consultant can pull out the design document like its a get out of jail free card. The result is the customer pays big money to design their own system prison. At Idealist Consulting, we believe there’s a better way.

Agile Gives you Wings!

I feel much more confidant with my agile projects because the agile approach allows for the freedom to make changes as necessary, without the shackles of an outdated document. If I have 10 projects going, I know from day 1 when I will need to budget my time. With waterfall I have no real idea when the design document will be approved, which makes it difficult to allocate project resources and ensure a client’s schedule is maintained.

With agile projects, the first phone call starts with requirements gathering. On the next phone call, we are looking at their Salesforce system together with some freshly implemented customization. After more phone calls and modifications (quick iteration and early prototypes being one of the keystones of agile), we start on report creation.

Requirements Gathering and Implementation From the Start

Agile allows to skip the pomp and circumstance and get to what really matters – the work. With waterfall there are many long- winded review sessions focused on making the customer comfortable, the who’s who conversation, the business process review, overall analysis of existing systems, and of course many discussions about the big design document. None of these things show concrete results in Salesforce or provide valuable results, and much of this can happen very quickly in the project kick-off call. Every waterfall project I have had also involves explaining why half the hours and budget have been used up and nothing is in the system. The customers feel like the wheels are spinning but we are going nowhere. This simply never happens with agile because real work happens from the very start.


In summary, Agile will:

  • Save you time and money
  • Lead to faster results and a faster final product
  • Allow for greater customer self-sufficiency and autonomy
  • Give your team more relevant reports
  • Result in a higher degree of customer system comprehension
  • Grant you greater peace of mind

So you can see, agile makes happier consultants and happier customers – and who doesn’t want that? This was only a brief look at waterfall vs agile project management. Idealist Consulting has a more in depth review of the pros and cons over on their blog, so be sure to check out how you can save time and money by implementing an agile Salesforce integration.

Ashley Bochiechio

About Ashley Bochiechio

Ashley was born and raised in Southern California and graduated with her Bachelors in Mathematics. She then moved with her family to Buffalo NY. Ashley has been working at anything and everything Salesforce for going on 2 years now. She now works as a Consultant for Idealist Consulting. Although she is still getting to know more about the nonprofit world she is experienced with meeting all kinds of business needs with Salesforce CRM.


  1. while interesting as with most things agile it is so high level to not be of a great deal of use to me. I’d be interested to know your thoughts on how much documentation is enough as opposed to too much. Surely you don’t dispense with documentation entirely.

    The cost issue is an important one (agile is great I’m sure for consultants on T&M for a client with deep pockets)

    I also find it is difficult to get management away from thinking in terms of roadmaps (Gantt charts), it is virtually impossible to say to a senior bod, look it’ll happen when it happens, deal with it!

    We also have our salesforce org tied into a finance system, this system requires strict controls and document definition before any code can be developed, I’d be interested to know what processes you use in this instance?


  2. I’m loving the discussion here! This really highlights the fact that different methodologies fit different projects in very different ways – the ultimate goal of providing an approach that will work best for the needs and capabilities of the client should always be top of the list!

  3. Susan Kenna Wright

    Great related article talking about agile development’s effects on customer expectations.

  4. Is it possible that customers who want the security blanket, choose consultants that provide that, and those customers more comfortable, as hands-on learners, choose more agile consultants? We practice some kind of hybrid of agile and waterfall. During the sales process, I find customers tending toward one comfort zone, or the other. We tend to then emphasize one style over the other. How do you deal with the customer comfort with prior knowledge vs help-us-build-this-together?

    • Really good point. Customizing the service to the client is very important, and clients are very, very different from each other. I think a lot of clients have trouble wrapping their heads around agile deliverables with agile price — you’ll get what you want, with a lot of transparency and feedback, but we can’t tell you today how much it will cost. Most of the boards will sacrifice the deliverable because they can’t deal with that kind of pricing. Typically I’m the one criticizing nonprofits for being risk-averse, but in this case, I get it.

    • Great points, Anna and Charlie – we certainly have those customers who aren’t quite ready for agile, too. While you can’t win them all here are some ways to address specific concerns:

      “I want to know what I am buying” – Everything outlined in the original SOW will be implemented. That means unless you decide to modify or adjust something you will be able to count on the deliverables outlined in the SOW. Agile gives us the flexibility to keep things relevant and swap deliverables if the scope shifts as we proceed.
      “I want to make sure the project moves along in a timely manner” – Not only are we going to get things started today, agile lets us move as quickly as possible and you’ll see movement almost immediately.
      “I want to make sure we stay on budget” – In the amount of time it takes to create a design document we could have your system built. Budget shifts are almost always due to a scope change and with agile methodology you’ll learn about potential budget risks and be able to mitigate sooner.

  5. I definitely prefer agile from a development perspective, and I agree that it is better for clients. SF implementations will always have a lot of agile involved, since as soon as you deploy, you’ll be inundated with new ideas about functionality you could add. That’s a good thing, and means your users value the system!

    Our challenge with it (and why we continue to use design documents) is that clients need to know how much the project will cost before they really get started. Boards and executives are (rightly) concerned about signing up for a project with vague pricing – and then we’ve got an incentive to drag the whole thing out as long as possible. We provide our clients with fixed-rate pricing, which means that if we’re able to deliver efficiently, we win, and if we’re wrong about how difficult the project is, we lose. Obviously there are issues with this model, but we think it benefits our clients and puts our incentives in the right place. Our agile/waterfall compromise is that we do requirements gathering and design with a SF sandbox so that they can see at least a skeleton of what we’re talking about, including reports. This gives them enough detail so that they can give us important feedback early on. The design document includes screenshots and explanations of how the user will interact with the system so that non-technical people can tell what they’re really getting.

    It is my impression that it is pretty much impossible to do a fully agile implementation and fixed-rate pricing. If someone disagrees, I’d really love to hear how the two can be combined more effectively.

    (To clarify, we provide an exact amount for requirements gathering up front, with an estimate for design, implementation, and ongoing maintenance and improvements. Once requirements are done, we provide an exact amount for design and an updated implementation/maintenance amounts. Once design is done, we provide an exact amount for implementation, and so on.)

    • Bryan Giese

      Excellent points, Anna. I like the way you control the size of the waterfalls through the system to help with the cost estimates. These different stages allow for appropriate use of iteration and feedback as well.
      It can be tricky to provide fixed prices. We are providing services that depend on sometimes unclear starting parameters. It sounds like you have put together an effective approach!

  6. I’ve been on projects before where the client doesn’t see anything for several months – this is so much more risky! Love agile for the early prototypes and open communication it fosters.

  7. Kim Kupferman

    Yes! Agile is a great project management methodology for managing custom solution projects. It is an excellent way to give clients an early view into what’s being built to meet their needs to make sure time is being spent efficiently.

  8. I really love agile processes, and I’ve found that it’s important for the team to understand your PM process from the beginning. I’ve been in a few “agile” shops that tried to force a waterfall approach into a franken-agile framework. It became very difficult to manage the project, expectations, and deliverables.

    Clarify the approach ahead of time, and let the Project Manager do their magic. Agile can be great for making adjustments that work well with your team, but that flexibility can also derail a team if they don’t have a guiding force.

  9. Ashley makes some great points! I’d never thought of these differences in project management before.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Kyplex Cloud Security Seal - Click for Verification