ウォーターフォール型開発の致命的な弱点

典型的な失敗プロジェクトの一つの道筋に「前工程が終わらないうちから次工程に入る」というのがあります。
わりと勘違いしている人もいるけど、「とりあえず作る」という類の方法論も、本質的にはこの「前工程を終える」というのをなんらかの形で実現してはいるはずです。ちょっと手順が前後したりするけど、長い目で見るとそうなっているはず。
一般的な業務システムの構築においては、分析、設計をきちんとやらないで「まあ作ってみよう」というのは自殺行為だし、作ってみたら固まっていなかった部分が火を吹いたりします。そのときに、きちんと設計に立ち戻って作業できるか、もぐらたたきをしてしまって地面が穴だらけになるか。
大規模なプロジェクトになればなるほど、後戻りすることのリスク（主にコスト面）が大きくなるから、ウォーターフォールみたいな方法論がどうしても幅を利かせてしまいます。ウォーターフォールの問題点は、個人的には以下の点

実装をイメージしないまま、設計フェーズで実装の見積もりをしてしまう
精緻な見積のために設計を細かくしすぎて後戻りをする余地がなくなる
フェーズの最後に次工程に進んでも大丈夫かを評価する必要があるが、予算とスケジュールの都合でおざなり（端的にってNGを出すことはめったにない）の評価しかできない

換言すれば、ウォーターフォールはうまくいくプロジェクトがうまくいくための方法論でしかなく、失敗した時に何を捨てるか判断する際には一旦ウォーターフォールのプロセスで、やり直しの部分から再計画しないとうまくいかないはず。

つまり、一定レベル以上の失敗に弱すぎる。

そのことに気づかないと、プロジェクトの立て直しは難しくなるでしょうね。