大規模なITプロジェクトが失敗する傾向があるか、コスト/スケジュールのオーバーランが大きいのはなぜですか？[閉まっている]

私は常に、大規模な変革または統合プロジェクトについて読んでいますが、これは完全またはほぼ完全な災害です。なんとか成功したとしても、コストとスケジュールの破綻は莫大です。大規模なプロジェクトが失敗しやすい背後にある本当の理由は何ですか。この種のプロジェクトでアジャイルを使用できますか、それとも従来のアプローチが最適です。

オーストラリアの1つの例は、プロジェクトを実施するためにテストの成功基準を変更したクイーンズランド州の給与プロジェクトです。
このSOの質問（Wayback Machineで）で失敗したプロジェクトをいくつか見る

共有する個人的な経験はありますか？

主な理由は、スコープの増加です。「Pragmatic Programmer」という本では、次のように説明しています。

• 機能の肥大化
• 忍び寄る特徴
• 要件クリープ

ゆでカエル症候群の一面です。

さまざまな「アジャイル」メソッドのアイデアは、フィードバックを加速し、できればプロジェクトの進化を時間内に修正することです。

しかし、もう1つの理由はリリース管理です：プロジェクトのリリースに向いていない場合（不完全であっても）、失敗する可能性があります（リリースが遅すぎ、バグの多い機能が多く、修正/更新/アップグレード）。

これは、リリース日を固定する必要があるという意味ではありませんが、テスト/評価/リリースするためには、常にプログラムの実行バージョンをビルドできる必要があります。

ブログ投稿「後期プロジェクトは一度に1日遅くなります」には、さらに多くの例が含まれています。

「Getting Real」の目的は、スコープを変更して起動日を固定することですが、時間内に完了できない機能について合意されている場合は機能しません。

そのため、仕様を提唱したり、「機能に同意した」ことはありません。それが問題の根本です。最初のピクセルがペイントされたりコード行が記述される前であっても、必要なものとその実装方法に関するすべてを知っていると言うことです。

柔軟なプレゼントで堅い未来を予測するとき、あなたは困っている。剛体の先物は最も危険なものです。彼らは、新しい扉を開く発見、出現、間違いの余地を残していません。

通常、プロジェクトの複雑さは過小評価されています。

スティーブマッコネル（「コードコンプリート」の名声）には、古典的な間違いのリストがあります。

いくつかの非効率的な開発手法が非常に多くの人によって非常に頻繁に選択されており、そのような予測可能な悪い結果は「古典的な間違い」と呼ぶに値します...

このセクションでは、3ダースの古典的な間違いを列挙します。私は個人的にこれらのミスのそれぞれが少なくとも一度は見たことがあり、私はそれらの多くを自分でしました...

このリストの共通点は、間違いを避ければ必ずしも迅速な開発を得られないということですが、避けなければ間違いなく遅い開発になります...

参照しやすいように、リストは人、プロセス、製品、および技術の開発速度の次元に沿って分割されています。

人

＃1：やる気を損なう...

＃2：人員が少ない...

＃3：管理されていない問題のある従業員...

＃4：ヒロイック...

＃5：遅いプロジェクトに人を追加する...

＃6：騒がしい、混雑したオフィス...

＃7：開発者と顧客の間の摩擦...

＃8：非現実的な期待...

＃9：効果的なプロジェクトスポンサーシップの欠如...

＃10：利害関係者の賛同の欠如...

＃11：ユーザー入力の欠如...

＃12：実質に置かれた政治...

＃13：希望的観測...

プロセス

＃14：過度に楽観的なスケジュール...

＃15：不十分なリスク管理...

＃16：請負業者の失敗...

＃17：不十分な計画...

＃18：圧力の下での計画の放棄...

＃19：ファジーフロントエンドでの時間の無駄。「ファジーフロントエンド」とは、プロジェクトが開始されるまでの時間であり、通常は承認および予算化プロセスに費やされる時間です...

＃20：アップストリームアクティビティの短縮...「コーディングへのジャンプ」としても知られています...

＃21：不十分な設計...

＃22：品質保証の変更...

＃23：不十分な管理コントロール...

＃24：収束が早すぎるか、頻度が高すぎます。製品のリリースが予定されている少し前に、製品のリリース準備を進める必要があります。製品のパフォーマンスの向上、最終ドキュメントの印刷、最終ヘルプシステムフックの組み込み、インストールプログラムの洗練、今後予定されていない機能のスタブ時間通りに準備など

＃25：見積もりから必要なタスクを省略する...

＃26：後で追いつく計画...

＃27：コードのような地獄プログラミング。一部の組織は、高速でゆるい、使いやすいコーディングが迅速な開発への道だと考えています...

製品

＃28：金メッキの要件。一部のプロジェクトには、最初から必要以上の要件があります...

＃29：機能クリープ...

＃30：開発者の金メッキ。開発者は新しいテクノロジーに魅了され、新しい機能を試してみたいと思うことがあります...製品に必要かどうか...

＃31：押してくれ、交渉してくれ...

＃32：研究指向の開発。Crayスーパーコンピューターの設計者であるSeymour Crayは、障害のリスクが高すぎるため、一度に2つ以上の領域でエンジニアリングの制限を超えようとしないと述べています（Gilb 1988）。多くのソフトウェアプロジェクトはCrayから教訓を学ぶことができます...

技術

＃33：銀弾症候群...

＃34：新しいツールまたは方法による節約の過大評価...プロジェクトが以前のプロジェクトのコードを再利用すると、節約の過大評価の特別なケースが発生します...

＃35：プロジェクトの途中でツールを切り替える...

＃36：自動化されたソースコード管理の欠如...

大きなプロジェクト=複雑性が 増す
複雑性が増す=
不確実性が増す不確実性が増す=推定が難しくなる推定が困難になる
=悪い推定値
悪い推定値=コスト超過

入札プロセスのせいにします。紙上で取引を最も安く/最も速く見せることができるグループに報いる。

入札をまとめる人々は、勝つチャンスがなければ時間を無駄にしたくないので、通常の見積もりは保留されます。私は、80ドルを節約するためにPOEスイッチの代わりに通常のスイッチを指定した人々を知っています。しかし、プロジェクトにはIPカメラが搭載されていたため、POEが必要でした。その80ドルを費やす必要がありますが、現在は仕様外です。

私は、2か月の2,000,000ドルのプロジェクトには、入札単価に関係なく2か月の2,000,000ドルがかかると固く信じています。あなたがそれを正しく行うことは高価だと思うなら、待って、それを間違えることがどれほど高価かを見てください。

考えられる理由の1つは、実際にはコストの増加が複雑さの増加、プロジェクト期間の延長（要件変更の時間の延長など）のために2次である場合、コストがプロジェクトサイズに比例して増加することを想定して、小さなプロジェクトに基づいていることです。プロジェクトが大規模になるほど、正確に見積もることが難しくなります。

別の理由は、最適化された推定値です：入札に勝つために、ベストケースの推定値を使用して価格を計算します。プロジェクトが大きくなるほど、ベストケースのシナリオになる可能性は低くなります。入札ルールにより、最も楽観的な申し出人が受け入れられる可能性が高いため、5つのベンダーが現実的な見積もりを行い、6番目が楽観的すぎる場合でも、楽観的な方が入札に勝ち、後で失敗します。したがって、これは一種の否定的な選択です。

コストは、重要な区別である「管理」の観点からスケジュールを排除しません。私たちが知っているように、「9人の女性が1ヶ月で赤ちゃんを作ることはできません」、しかしあなたは、彼らに投げられたお金の量に関連して問題が深くなると考える人がどれだけいるかに驚かれることでしょう。悪いプロジェクト管理は、多くの場合、マイクロ管理という形で現れますが、ほとんどのプロジェクトがタンキングの主な原因です（私の経験では）。マイクロ管理は、「管理」が何かが制御不能になっていることに気づき、その理由が分からないときに開始します。

それが原因ではない場合、プロジェクトの期待される結果は、おそらく最初から受け入れられなかったでしょう。私の経験では、プロジェクトの期間が短すぎると、人々は間違いを犯すことを恐れて「二重の仕事」になり、ほとんど何もしません。

これが、成功したプロジェクトを生み出した主要なチームの歴史を持つ経験豊富なプログラマーを経営陣に取り込むべき理由です。そのような人は、可能な収入にもかかわらず「責任を持ってそれを行うことはできません」と言うかもしれず、長い間管理されていないだろう。

私は、プログラマーではないプログラマーの雇用を担当していた会社の数を失いました。かつて、採用マネージャーが最近のスポーツイベント（サッカーの試合だと思う）について話し合う以外に何もしたくないというインタビューをしました。担当者がKnuthよりもNFLコーチからより多くのインスピレーションを得た場合、プロジェクトは戦車になります。

ときどき、よく計画され、よく理解され、現実的で、一見単純に見える何かに出くわします。何らかの理由で、開発から6か月で、すべてが逆転しました。それは起こります。ただし、プロジェクトが栄光の豚肉樽になるという根本的な原因はめったにありません。

それでも、ニュースを見ると、バイクの事故や列車の事故が時折見られるかもしれません。毎日定刻に到着する何百万ものオートバイや電車については、何の問題もなく聞くことはありません。プロジェクトにも同じことが言えます。確かに、本当に本当に悪くなったものの公開検死を見るのは面白いですが、本当にうまく行ったものについてはほとんど聞いていません。タンクプロジェクトはまだ例外であり、標準ではないと思います。

ほとんどの場合、以下の2つ以上の組み合わせ：

• 部門間のコラボレーションの問題
• 政治...多すぎる政治...
• 間違ったチーム
• 非現実的なスケジューリング
• 適切な方法論なしで範囲を変更する
• 不足している情報

主題に関する素晴らしい本：死の行進。

人々は、ソフトウェア開発は予測プロセスであると考えがちであり、1年先のことを測定および推定しようとします。これは不可能です！構築ソフトウェアはボルト製造ではありません。

同じ「トレンド」に続いて、彼らはすべての可能性をカバーするだろうと考えて巨大な分析を（再び1年先に）しようとし、後にプログラマーを単なるタイピストに変えます。どうしてこれがうまくいくと思う？この種の振る舞いは、間違った見積もりと多くの官僚主義につながります。

プロジェクトが大きいほど、大規模な組織で働いている可能性が高くなります。組織が大きいほど、管理の層が多くなります。管理の層が多ければ多いほど、悪いニュース（「余裕があるために必要なものを手に入れることができません」）が指揮系統を構成するのが難しくなります。悪いニュースがそれを指揮系統にする可能性が低いほど、ファンタジー計画が受け入れられ、それが受け入れられないと知られた後、長く保持される可能性が高くなります。

すべてのサイズのソフトウェアプロジェクトは「失敗する傾向がある」または「コスト超過を抱えている」。あなたは角を曲がった事業でのコストオーバーランについては聞いていないが、あなたはやる FBI仮想ケースシステム、またはデンバーの空港手荷物搬送システムのようなものについて聞きます。したがって、すべての大規模システムで障害が発生するわけではなく、すべての大規模システムでコスト/スケジュールのオーバーランが発生するわけではないと主張します。

スケジュール通りに（プロジェクト中にスケジュールが1回だけ移動した）、仕様どおりに（多くのサプライヤの1つであるため予算情報にアクセスできませんでした）大規模なシステムに遭遇しました。感銘を受けたのは（このサイトで少し書いたことがある）、大規模な（フォーチュン500の最初の100の）金融クライアント向けの大規模な統合顧客管理システムでした。私は、彼らが電話会議中に人々の給料で1日あたり約10万ドル（1年以上）吹いたと推定しています。

手荷物処理システムの場合、ソフトウェア管理者は「この規模と複雑さのプロジェクトに基づいて、このシステムの構築とデバッグには4年かかるだろう」と述べた。営業マネージャーとエグゼクティブマネージャーは、「空港は2年で開くので、クライアントには2年かかると言ったので、2年かかる」と言いました。あなたがプログラマであるか、管理者であるかを確認するテストは、次の質問に対する単純な答えです。

顧客が自分が望むものを正確に知っている（そしてごく少数の人がしている）場合、彼らはコストと時間を管理下に置く道に非常に遠くなります（そして、これらは非常によくオフショアリングする傾向がある人々です）。顧客が夢見る可能性のあるあらゆる機能をプロジェクトで満たす必要があり、ペットの金塊がプロジェクトに追加されたときにすべての部門が拒否権を持っている場合、最初から失敗を免除する運命にあります（FBIのように） VCFプロジェクト）。

現実の知覚

ここに私が見つけたこの問題の最良の説明があります。businessballs.comからのツリースイング

私はプログラミングキャリアの初期に「現実の知覚」の概念を紹介されました。このため、私は本当に感謝しています。これが、ITプロジェクトだけでなく、プロジェクトが失敗する最大の理由だと思います。

失敗の1つの理由は、大規模なプロジェクトは通常、注目度の高いビジネスにとって重要なプロジェクトだからです。プロジェクトとタスクが注目を集めるとき、それは人々が嘘をつくことを奨励します。

上司は、ハイサイドでの完了ステータスを推定することを望んでいます。彼は、ローサイドのオーバーランと遅延を推定したいと考えています。問題が発生した場合、彼はそれがタスクに3週間を追加することを聞きたくありません。彼はあなたが今夜数時間にそれを働かせることを聞きたいと思っています。

などなど。

私はクライアントのために、数年前に1つのプロジェクトに参加しました。入札とプロジェクト計画が完了した後、私は連れてこられました。より速く、より速く、とんでもないコスト削減の意思決定、スタッフの過負荷、彼らのためのリソースなしに進むことへの一定の圧力がありました。机、コンピューターなど何もありません。

最後に、プロジェクトが7か月と1600万ドルで入札されたことを発見しました。封筒の裏側では、24か月で5,000万から1億になるはずです。私はマネージャーと彼のマネージャーとのミーティングを設定し、私のケースを説明しました。彼らはすべての問題を軽視した。ミーティングの終わりに、CIOは元の入札の欠陥を除き、基本的に私が言ったことを両方のマネージャーに電話して伝えました。

彼らが技術を私が不慣れなものに変えたとき、私はプロジェクトをロールオフする機会がありました。後で誰かと話しました。プロジェクトは、約半年で終了しました... 12か月、3500万ドルでキャンセルされました。

注目度の高い大規模なプロジェクトは、「これは間違いです」と言う人々を思いとどまらせます。間違いは許されません。

VonCの答えについて少し詳しく説明します。

この大きなプロジェクトは、「オールオアナッシング」の考え方を持っている傾向があります。定義されたプロジェクトは一度にリリースする必要があります-多くの場合、既存のシステムからの変更です。

これは、機能/要件のクリープの問題に対処するのがより困難であることを意味します。そのため、プロジェクトが実現すると、要件を満たさなくなったと見なされることがよくあります。これは、既存のシステムが更新されたか、その間に技術が進歩した場合に悪化する可能性があります。

これに対する解決策は何ですか？

私は、2つのシステムを2つのシステム間で分割された一連の変化する機能で並行して実行することを望んでいないので、本当に知りません。

大規模なプロジェクトの複雑さは、外部の政治的圧力によって大幅に悪化する可能性があります。ある部門は、新しいシステムで何を望むかについて非常に明確で焦点の合ったアイデアを持っているかもしれませんが、その後、関連する部門は「さて、あなたがそれをしている限り、なぜこの小さな副作業も私たちのためにしていますか？」「いいえ、それは範囲外です。」と言うことから始めるかもしれませんが、その後、学問間の政治的内戦が始まり、誰もがパイを手に入れない限り、プロジェクトの予算が脅かされます。

長年、地元の警察は、自動車システムを介して部分プレートを検索できませんでしたが、この機能はばかばかしく思えます。友人にこの機能を追加するのがどんなに難しいのかを尋ねたところ、彼らは現代のデータベースへの切り替えを提案するたびに、自動車システムと相互作用した州の他のすべての部門が自分の一部を手に入れたいと言ったシステムも修正されました。その結果、ITの近代化が完全に完了しました。最後に、国家はシステム全体の近代化努力を行うのに十分な資本を集めました。

触れられたがまだ対処されていない要因：

劇的な失敗のほぼすべては、入札された契約です。そのような状況で有能な会社はどうなりますか？彼らは現実的な見積もりをするので、悪い見積もりをした誰かによってほぼ間違いなく低められています。

会社が適切に見積もることができない場合、システムを適切に構築できないことは驚くべきことですか？

ZDNetに関するMichael Krigsmanのブログには、「ITプロジェクトの失敗」に関するブログがあります。

もう1つのポイントは、長年にわたる長いプロジェクトでは、一般に、検討するアップグレードまたは代替ソリューションのいずれかがあることです。これらは、プロジェクトが開始されたときに与えられていませんでした。たとえば、何かが6.0のときに開始することもできますが、最初のフェーズが完了するまでに6.3または6.4が出て、いつアップグレードするかという質問が出されることがあります。要件が正しく収集されなかったか、誰かが考えを変えたために、スコープと目的の機能の変更は、既にかなりカバーされている別のいくつかのポイントです。

この種のプロジェクトでアジャイルを使用できますか、それとも従来のアプローチが最適です。

うまく適用されたアジャイルプロセスがこの問題に苦しんでいないように見える理由は、単純な理由のためです。大規模なプロジェクトを機敏に開始することはできません。どちらかを選択できます。

アジャイルなプロセスを使用すると、プロジェクトの将来への1〜2回の繰り返しを実際に見ていることはありません。次の2年間には「計画」はなく、次の2週間だけです。あなたの意見がそんなに短いとき、あなたはいくつかの妥協をしなければなりません。どんな種類のウィジェットを設計する場合でも、「ウィジェットの最後の言葉」を作成する計画から始めることはできません。せいぜい「フロブできるウィジェット」から始めることができます。これは、1回または2回の反復で行うことができるほとんどの作業に関するものだからです。

これについての良い点は、数回の反復の後、誰かが有用であることがわかる完成した実用的な製品を既に持っていることです。特に、フロブとゾートが可能なウィジェットを必死に必要とする顧客。

基本的に、大規模なプロジェクトは、すべての潜在的な顧客の問題をすべて解決することを目的としているため、失敗する可能性があります。アジャイルプロジェクトにはこの目標はありません。代わりに、各バージョンで、1人の顧客が抱える1つの重要な問題に対処します。しかし、長い間、アジャイルプロジェクトは多くの顧客にとって多くの重大な問題を解決しているかもしれません。

• 実際のユーザーへの出荷の失敗

大きなプロジェクトでは、何年もの間「インフラストラクチャ」モードに移行する傾向があり、実際のエンドユーザー機能を構築して出荷することを忘れています。出荷時までに変更するのは非常に費用がかかり、通常、最初の実際のベータテストが行​​われた後に、概念上の最大の変更が求められます。

• コストを正確に推定できない

プロジェクトが投資収益率を上回ると思われる場合、キャンセルされます。

• 品質管理の失敗

十分な欠陥があると、前方運動量がゼロまたはそれ以下に低下する可能性があります。まったく進歩がなければ、継続的な存在を主張することは困難です。

彼らは、ホフスタッターの法則を忘れていました。ホフスタッターの法則を考慮に入れたとしても、予想よりもずっと長くかかります。

Web開発で見たもの：

• 料理人が多すぎる-急にウェブに重点が移った大手B＆M小売業者。突然20人の部門長が、新しいヘッドチーズを印象付けるためにあらゆるイニシアチブをドッグパイルしています。法律上は古いアイコンの外観が気に入らなかったため、新しいアイコンを実装する必要がありました。

• 「IE6のアイコンはIE7のアイコンに比べてわずかに色あせています。実行中のローンチ日が重要な作業はやめてください。数日かかる恐ろしいことを行うには、顧客ベースの.05％に注意してください。 IEエクスペリエンスをさらに実装し、速度を低下させます。」

• 社内の開発者に助言を求めることすらできない非開発者が選んだ悪いツール。

• ツールに選ばれた悪い開発者-「バージョン管理を使用するのがあまりにもわからない200人のかろうじてコードリテラシーな人をアウトソーシングできるのに、なぜ20人の有能なJava開発者にまともな給料を支払うのですか？」同時に、またさまざまな国の人々と一緒に、主に3つの大きなアプリのバックエンドに取り組んでいます。

• 不良/破損したアーキテクチャ-解雇された、または現在マネージャーになっている人々による、パニックに陥った、昨日取得したコードのレイヤーのレイヤー。