Το IT Project Success Survey 2011 που έκανε ο Scott Ambler και παρουσιάζεται στο Dr Dobbs βρήκε ότι το κλασσικό μοντέλο είναι ίδιο ή και χειρότερο ακόμα και από το ad-hoc development, ενώ η σημαντική γραφειοκρατία που απαιτεί έχει ως αποτέλεσμα να είναι οικονομικά ασύμφορο (αρνητικό ROI, Value, Time ακόμα και σε σχέση με το ad-hoc). Παλαιότερα surveys (2010,2008) δείχνουν αντίστοιχα αποτελέσματα, με το κλασσικό μοντέλο να μην αξίζει το μπελά του (μικρότερο ROI από τις άλλες μεθόδους).

Αντίθετα, σε όλες τις περιπτώσεις οι καλύτερες μεθοδολογίες σε ποσοστά επιτυχίας αναδεικνύονται οι iterative και αμέσως μετά οι agile. Από την άλλη, αν δει κανείς πως τα πάνε οι διάφορες μεθοδολογίες όσον αφορά χρόνους και ποιότητα θα δει ότι οι lean έχουν καλύτερους χρόνους και ποιότητα ενώ οι agile καλύτερο ROI και απόδοση.

Το καημένο το waterfall τα πάει πολύ χάλια σε όλους τους τομείς: Σε χρόνους (πόσο έγκαιρα παραδίδεται το έργο) το waterfall βγαίνει χειρότερο και από το "χύμα" (ad-hoc) development, ενώ σε κόστος και απόδοση είναι επίσης χάλια.

Προκαλεί εντύπωση πόσο άσχημα τα πάει το waterfall στους χρόνους, ειδικά αν σκεφτείς πόση δουλειά απαιτεί για τη συλλογή λεπτομερών requirements και εκτιμήσεων για κάθε βήμα του υπερλεπτομερούς project plan. Είναι λογικό όμως αν σκεφτεί κανείς ότι οι χρόνοι στους οποίους βασίζεται το waterfall είναι πλασματικοί. Η καλύτερη δυνατή εκτίμηση στην αρχή ενός έργου δεν μπορεί να είναι καλύτερη από ±4 φορές του πραγματικού χρόνου ενώ ακόμα και μετά τα requirements η αβεβαιότητα περιορίζεται μόλις στο 0.67 - 1.5 φορές. Ακόμα και σε αυτό το σημείο, οι πιθανότητες να βγει το έργο στον υπολογισμένο χρόνο ( μέχρι 1.1 φορές) είναι ελάχιστα καλύτερες από κορώνα-γράμματα.

Υπάρχει όμως ένα σημείο στο οποίο το Waterfall υπερτερεί: Σε εξασφαλίζει αν το έργο καταλήξει στα δικαστήρια. Από τη στιγμή που ο πελάτης έχει αναγκαστικά συμφωνήσει με τις αρχικές προδιαγραφές (ακόμα και αν αυτές αλλάξουν μετά) και εφόσον έχεις "φουσκώσει" αρκετά τους χρόνους, μπορείς να πας στο δικαστήριο και να αντιμετωπίσεις τυχόν απαιτήσεις. Ειδικά αν ο πελάτης θα έχει ζητήσει αλλαγές (που πάντα ζητάει) θα μπορέσεις να πεις ότι οι αλλαγές ευθύνονται για τυχόν καθυστερήσεις.

Εξάλλου ο δικαστής δεν θα κοιτάξει τον κώδικα. Τα requirements και τα change requests θα διαβάσει ....

ΥΓ: Μπορεί να φαίνεται περίεργο που το "χύμα" βγαίνει καλύτερο σε κάποιους τομείς από το watefall, θα πρέπει όμως να έχουμε υπόψη ότι το "χύμα" σημαίνει ότι ένα έργο δεν ακολουθεί συγκεκριμένη μεθοδολογία, όχι ότι δεν χρησιμοποιεί μεμονωμένες τεχνικές. Τεχνικές όπως το unit testing, το pair development, το refactoring, τα user stories, χρησιμοποιούνται άτυπα ακόμα και σε έργα που θεωρούνται ότι δεν ακολουθούν κάποια μεθοδολογία. 

Οι ίδιες τεχνικές είναι σχεδόν απαγορευμένα σε έργα waterfall ή γίνονται αναγκαστικά κάτω από τη μύτη του project manager ο οποίος θεωρεί ότι το testing πρέπει να γίνεται μόνο στο τέλος ή ότι refactoring πρέπει να γίνεται μόνο όταν τελειώσει η τρέχουσα φάση του έργου.