リリースの日を迎えることなく、
プロジェクト自体が中止になった。
予算オーバー、納期遅れ、
または要件を満たせなかった。
当初の予定通りに
（あるいはそれ以上に）成功した。
Source: The Standish Group "CHAOS Report"
当初はシンプルな在庫管理システムのはずだった。
しかし、現場からの「あれも欲しい」「これも欲しい」という要望を全て受け入れてしまった結果、機能は膨れ上がり、納期は半年遅れ、予算は3倍に。
最終的に完成したのは、多機能すぎて複雑すぎるシステムだった。
「やらないこと」を決める勇気が、プロジェクトを救う。
発注者は「安くて何でも言うことを聞いてくれる」ベンダーを選んだ。
しかし、そのベンダーは技術力が低く、仕様の矛盾を指摘することもしなかった。
テストフェーズで致命的なバグが多発。
全てを作り直すことになり、リリースは1年遅れた。
イエスマンはパートナーではない。リスクを指摘できる専門家を選べ。
最初から100点を目指さない。まずは「なくてはならない機能（Must）」だけで小さく作り、最速でリリースする。ユーザーの反応を見ながら改善していく。
一括請負は「仕様変更＝追加お見積り」の戦いを生む。信頼できるチームと月額固定で契約し、優先度の高いものから順に作っていくアジャイル型が現代の主流。
「システム担当者がいないから全部お任せ」は事故の元。社内に担当者を置くか、それが無理なら外部のPMO（Project Management Office）を雇い、発注者側の利益を守らせる。
分厚い仕様書よりも、動くプロトタイプ。紙の上で議論するより、実際の画面を触って確認する回数を増やす。