CHAOSレポートにおけるプロジェクト評価の定義
CHAOSレポート（Standish Group が定期発行するソフトウェアプロジェクトの実態調査）では， プロジェクトの結果を以下の3カテゴリに分類している．
| カテゴリ | 英語名 | 定義 |
|---|---|---|
| 成功 | Successful | 予算内・期限内に完了し，要求された機能・特性をすべて備えている |
| 問題あり | Challenged | 完了はしたが，予算超過・期限超過・機能不足のいずれかが発生している |
| 失敗 | Failed | キャンセルまたは納品されたが使用されなかった |
上図は Standish Group CHAOS Report（2015年）のデータをもとに，開発手法（Agile / Waterfall）とプロジェクト規模（全体・大型・中型・小型）の組み合わせ別に，成功・問題あり・失敗の割合を示したものです．
- 全体傾向として，Agile はすべての規模において Waterfall より成功率が高く，失敗率が低い．
- 規模の観点では，プロジェクトが大型化するほど成功率が急激に低下する
「成功」定義の問題点
① 計画精度を前提とした定義
CHAOSレポートの成功定義は，「期限・予算・機能の計画値と実績値が一致していること」を基準としてます． この評価軸は，設計段階において納期・予算・機能スコープを正確に見積もれることを暗黙の前提となってます
多くのソフトウェア開発プロジェクト，特に探索的・イノベーティブな性質を持つものでは，初期段階で正確な見積もりを立てること自体が構造的に困難． また，不確実性の高いプロジェクトほど計画が外れやすく，「問題あり」に分類されやすいという問題があります．
② 「計画通りに完了したが価値を生まなかった」ケース
予算内・期限内・全機能を実装して「成功」と判定されたプロジェクトが，リリース後にユーザーに使われないケース，あるいは事業目標を達成しないケースは珍しくないです． そもそも，開発したソフトウェアが市場やクライアントのニーズにどれだけ適合したものかどうかは，判断基準に含まれていないです．
逆に，スコープ変更や期限延長が発生したプロジェクトが「問題あり」に分類されながらも，市場での大きな成功を収めることもありえます．
③ 計画変更を「失敗」として扱う問題
アジャイル開発など，学習を前提とした反復型アプローチでは，要件の変化や優先度の見直しはプロジェクトの健全なシグナルですが， CHAOSの基準では，計画との乖離はカテゴリを問わず評価を下げる方向に働きます．計画の変更そのものを失敗の証拠として扱うこの設計は， アジャイル型プロジェクトの実態を正しく測定できていないリスクがあります．
- 納品１ヶ月後にクラッシュしたプログラム
- ユーザーから簡単な機能追加を依頼されたが，実現が簡単ではない．機能追加には多大な時間が必要だし，新たなバグを生む可能性が高い
- 二度とその顧客から発注が来なくなった