When Does Waterfall Work Well?

  • Post category:ERP
  • Post comments:3 Comments
  • Reading time:2 mins read

Today I’ve completed delivering the Microsoft Dynamics Sure Step course in Belgrade, Serbia, and I totally enjoyed it. The discussions were great, there was a lot of experience accumulated in that room, and all of the thirteen people attending the training were participating and contributing knowledge. If ever, this time during training I got zillions of ideas for blog posts, too bad I forgot most of them immediately thereafter 🙂

One of the discussions we led was about waterfall and its (in)effectiveness. Some of the people, those who primarily come from development background, expressed their belief that waterfall is a bad and an outdated approach which usually leads to failed projects. I shared some of my thoughts on the topic, but I still believe that I didn’t give a good explanation when the waterfall approach works better than an agile one.

Anyway, after a nice evening guided tour of Belgrade (thanks Marko!), and delicious cheese, yoghurt, ham and mushrooms pancakes, when I returned to my room I pondered a bit about the waterfall approach and how it could be put down simply: when to apply it, and when to just opt out.

Then I remembered I’ve once heard at a project management training (or read in a book, or a blog or somewhere) that the waterfall is a good approach when the duration of the project is shorter than the frequency of organizational change.

In other words, if the organizational change is frequent, and the project is long, then the project might fail, because the requirements might change as well.

I’ve tried to google it up quickly, but it yielded nothing, and this is definitely not my own brainpower at work here. I hate skipping giving credit to the author of this thought, but I have a plane to catch.

Bye-bye Belgrade, it was a great training, I hope you all pass the exam!


Vjeko has been writing code for living since 1995, and he has shared his knowledge and experience in presentations, articles, blogs, and elsewhere since 2002. Hopelessly curious, passionate about technology, avid language learner no matter human or computer.

This Post Has 3 Comments

  1. Tarek Demiati

    Requirements changes occurs even when there is not organizational changes. So it’s not a valid reason for sticking to a doomed methodology (I’m referring to Water Fall here) 🙂

    but I still believe that I didn’t give a good explanation when the waterfall approach works better than an agille one”

    I would have the same hard time, if I would have to convince someone that a Citroen 2CV is faster than a Ferrari Testarossa

    Yes, My opininion is totally biased : I’m a certified Scrum Master 😉

    Ship Early & Often IS the way to go :

    1. Vjekoslav Babic

      @Tarek: Actually, Citroen 2CV has a series of advantages over Ferrari Testarossa in certain situations – they are two totally different types of cars for different purposes and cannot be compared. Scrum is fantastic for software development, and Agile approach in Sure Step is pretty close to the Scrum principles – however waterfall is still a valid approach in situations where the project doesn’t comprise only development requirements, and ERP projects, at least at large scales, often don’t. You can build a farm by applying Scrum principles; you cannot build a hospital by doing so. IMHO: the same huge difference exists with software development and software implementation, and ERP solution providers so often fail to understand that. I am a huge fan of agile approaches (such as Scrum) – I even blogged about it here in this blog in a series of posts a year ago and talked about it on couple of conferences, but still – there are situations when agile would just fail.

Leave a Reply