橋の改修、新幹線、主要なスポーツイベント、石油精製所、運河、商業建設、ヘルスケアのアプリ、ソフトウェアのアップグレードなど、これらはすべて、記録的なコスト超過で最近の話題になりました。 これらのコスト超過の一部は、50〜60％を超えているだけでなく、予算よりも桁違いに高くなっています。
Standish Groupの報告によると、正常に完了したものは（つまり、予算内で、時間通りに、スコープの範囲内で）中規模プロジェクトのわずか７％、従来のウォーターフォール型を使用した大規模プロジェクトではわずか３％だということです。 つまり、大規模で複雑で費用のかかるプロジェクトの97％が期待どおりに機能しないというパンデミックレベルの数字になっているのです。
成功または失敗を知ることは重要であり、早いほど良いです。 プロジェクトが失敗していることを知らないことのコストと結果は、組織全体を沈没させる可能性があります。 知るためのコストは比較的安価です。
コスト超過の原因と治療法 残念ながら、すでに費やされたものを元に戻すことはできません。 ただし、さらなるコスト超過からの予防的治療法は可能です。
低い見積り
多くの見積りは、最善のケースに基づいて計算されます。 戦略的に見積りを低く設定し、プロジェクトに着手する承認を得る場合もあります。 いずれの場合も、精度が高いと思われていることが、最終的に失敗する環境を作っているのです。
治療法：
- 精度ではなく正確度を見積る： 相対評価で、見積りの正確度を高めます。 プロジェクト全体を通して、プロダクトバックログのすべての絶対時間または日数を見積ると、間違った精度感を得てしまいます。 ８か月後に何をするかは正確にはわかりませんが、同じチームが同じ時間枠で同じこと（つまり、製品を完全に構築する）を行うため、チームの以前のイテレーションのパフォーマンスを使って将来を正確に推定できます。 チームが楽観的に見積る場合でも悲観的に見積る場合でも、結果は、チームの個々の特異性に合わせて自己修正された、より正確な納品の見積りになります。
- 現実に基づいて範囲を提供する：PERT手法を正しく使います。 楽観的、悲観的、平均的（最も可能性が高い）のパフォーマンスの反復的な経験的データに基づいて、納期の範囲を広げます。 イテレーションで機能を開発するチームは、各イテレーションの最後に経験的な出力データ ポイントを確立します。 構築されたものは完全に構築されており、潜在的に出荷可能です。 これは、より現実的な納期シナリオをステークホルダーに提供するために使用できます。
- 段階的な資金調達：先行資金を避け、段階的に資金調達の期待値を設定します。 予算全体に前もって同意するのではなく（つまり、成功または失敗を判断する前に全額を費やすことができるという期待値を設定する）、要求された金額を割り当てることに同意しますが、最初のリリースにのみ資金を提供します。 少量の納品ができないのなら、大量の納品もできません。
弱い変更管理
従来、多くのプロジェクトチームは、すべての要件を前もって詳細にロックダウンし、変更を、実際に学んだことを適用する機会ではなく、失敗として扱おうとします。 精度を追求し、元の計画に固執するこのやり方では、変更管理が困難で時間のかかるプロセスになり、元のスコープに固執するがあまり、構築したものが、顧客が必要としているものではないということに気づく時期が遅くなります。 代わりに、元のスコープを続行し、スケジュールや予算を調整せずに新しいスコープを追加します（つまり、スコープの肥大化）。 言い換えれば、彼らは複雑さのせいで、変動性を計画することができません。
治療法：
- 段階的な精緻化：要件の優先順位が上がったときにのみ、要件の精緻化に時間を費やします（ビジネス価値とリスクに基づいて）。 次のリリース目標を達成するためにビジネス価値が必要であることが明らかになるまで、詳細に分解するという時間を費やさないでください。
- 価値に基づいた優先順位付けと資金提供：アジャイルチームは時間やお金を使い果たすのではなく、価値を使い果たします。 プロダクトバックログの優先順位と順序付けを、ビジネス価値とリスク別に簡素化します。 一度に１つのプロダクトバックログ項目を完了するまで開発します。 このパターンに従うことで、プロジェクトのどの時点でも、残りの資金の量に関係なく、最も優先度の高い （価値） 機能を出荷できるようになります。 プロジェクトの終了日は、プロジェクトの予算が使い果たされたときではなく、現在のプロジェクトを継続するための実際のコスト（AC） と、別のプロジェクトで作業しない場合の機会費用（OC）が、現在のプロジェクトで作業を続けることによって得られる価値（V） を上回る場合に基づいて決める必要があります。 AC＋OC > Vは、現在のプロジェクトを終了し、限られたリソースをより価値の高いイニシアチブに集中させる必要がある点です。
- スコープの入れ替え： スコープクリープや肥大化を心配せず、スコープの入れ替えによって変更を管理する。 プロダクトバックログの反復的開発では、機能が、短いイテレーションで完了するまで開発され、すぐに適応できるように顧客に提示されるため、実際のフィードバックを利用して競争上の優位性を獲得します。 ピボットの決定は、作業中の項目が最も優先度の高い項目であるため、頻繁に行うことができます。
検証が不十分な仮定
ほとんどの仮定は、検証できるようになるまで「悪い」と見なす必要があります。 私たちは、プロジェクトの開始時、最も知識が少ない段階で、最も多くの仮定をします。 これらの仮定を早期に検証しなければ、その後下す決定に仮定がずっと影響を受けることになります。 ピボットの機会を遅らせると、軌道に戻るために移動しなければならない距離が長くなります。
仮定の妥当性が確認されるまでは、プロセスの早い段階で決定を確約することは、プロジェクトチームが将来下すことのできる決定において、足かせとなります。 同様に、早い段階で過剰にエンジニアリングすると、チームがプロジェクトの残りの部分を実行しなければならないオーバーヘッドが発生し、選択肢が制限されます。 プロジェクト全体でチームの柔軟性が高いほど、やり直しや最適ではない代替案へのコスト依存によるコストの遅延が発生する可能性は低くなります。
治療法：
- フィードバックループを通じて最もリスクの高い仮定を早期に検証する： 完全に構築された製品を早期かつ頻繁に顧客に提供し、即座にフィードバックを収集します。 プロジェクト内のできるだけ早い段階で（つまり、最初の数回のイテレーション）、顧客とのフィードバックループを通じて、最も高いリスクの仮定に対処します。 仮定が間違っている場合、早期に見つけることで、それ以上お金を無駄にする前にピボットまたは停止することができます。
- 検証済みの学習に基づいてすぐに行動する：顧客にビジネス価値を提供する能力を強化するためにピボットが理にかなっている場合は、すぐにピボットを行います。 学習内容から、当初期待したビジネス価値を提供できない可能性がある場合は、損切りをします。 早期の失敗は成功の一つの形です。
- 決定を延期する：いつかは決断を下さなければならないとわかっているからといって、最初から決断を決めつけないことです。 決定を下す前に、合理的な範囲で可能な限りチームに時間を与えましょう。 アーキテクチャを出現させ、現在進行中の要件を完了するために必要なものだけを実装します。
これらすべてにとっての本当の治療法は、考え方の変化に要約されます：早期の失敗が成功の一つの形であることを認識する能力。
失敗したプロジェクトに大金を費やした後では、それを本当の意味でのサンクコストではなく、何かに変えようと努力し続けなければならない投資と考えるのは自然なことです。 プロジェクトが資金を使い果たすべきではありません。 プロジェクトが使い果たすのは価値です。 「いまだ」というべきタイミングを知り、実際に実行することが、コスト超過のパンデミックを治すために必要なスキルなのです。
