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