大規模なITプロジェクトが失敗する傾向がある、またはコスト/スケジュールの超過が大きいのはなぜですか？
私はいつも大規模な変革または統合プロジェクトについて読んでおり、それは完全またはほぼ完全な災害です。彼らがなんとかしてコストとスケジュールを成功させることができたとしても、ブローアウトは莫大です。大規模なプロジェクトが失敗しやすい本当の理由は何ですか。これらの種類のプロジェクトでアジャイルを使用できますか、それとも従来のアプローチが最良です。
オーストラリアの1つの例は Queensland Payrollプロジェクト で、プロジェクトを提供するためにテストの成功基準を変更しました。
これに失敗したプロジェクトがいくつかありますSO質問 （ ウェイバックマシン上 ）
共有する個人的な経験はありますか？
主な理由は、スコープ「の増加」であり、本「The Pragmatic Programmer」では次のように説明されています。
- 機能満腹
- 忍び寄る特技
- 要件クリープ
カエルのゆで症候群の特徴です。
さまざまな「アジャイル」方法のアイデアは、フィードバックを加速し、できればプロジェクトの進化を適切に修正することです。
しかし、もう1つの理由はリリース管理です。プロジェクトをリリースする準備ができていない場合（ただし、プロジェクトが不完全であっても）、失敗する可能性があります（リリースが遅すぎて、バグの多い機能が多すぎて、修正/更新/アップグレードが難しいためです）。
これは、リリース日を固定する必要があることを意味するわけではありませんが、テスト/評価/リリースするために、プログラムの実行中のバージョンをいつでも構築できる必要があります。
ブログの投稿 " 遅いプロジェクトは一度に1日遅れる "には、さらに多くの例が含まれています。
「実現する」ことは、スコープを変更して発売日を固定することであることはわかっていますが、時間内に完了できない機能に合意した場合は機能しません。
そのため、私たちは仕様を主張したり、「機能性に同意したりしません」。それが問題の根本です。最初のピクセルが描画される前、またはコード行が記述される前でも、必要なものとその実装方法についてすべて知っていると言っています。
柔軟なプレゼントで厳しい未来を予測すると、困っています。厳格な先物は最も危険なものの1つです。彼らは、発見、出現、そして新しい扉を開くミスの余地を残しません。
通常、プロジェクトのcomplexityはnderestimatedです。
Steve McConnell（ "Code Complete"の名声）は クラシックミス のリストを持っています。
いくつかの非効率的な開発手法が非常に頻繁に、多くの人々によって選択されており、そのような予測可能な悪い結果は、「古典的な過ち」と呼ばれるに値します...
このセクションでは、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：自動化されたソースコード管理の欠如...
より大きなプロジェクト=より複雑
複雑さの増加=不確実性の増加
不確実性の増加=推定が困難
見積もりが難しい=悪い見積もり
悪い見積もり=コスト超過
入札プロセスのせいです。それは、取引を紙の上で最も安く/最も速く見せることができるグループに報酬を与えます。
入札をまとめる人々は、彼らが勝つ機会がない場合に彼らの時間を無駄にしたくないので、彼らの通常の見積もりは保留されます。 POEスイッチの代わりに通常のスイッチを指定して80ドル節約した人を知っています。しかし、プロジェクトにはIPカメラがあったためPOEが必要でした。その80ドルは使う必要がありますが、現在は仕様の範囲外です。
2か月の$ 2,000,000のプロジェクトには、入札数がいくつあっても2か月は$ 2,000,000かかると私は確信しています。正しく実行するのは費用がかかると思われる場合は、しばらく待って、それを間違って実行するのがどれほど高くつくかを確認してください。
考えられる理由の1つは、実際のコストの増加が、たとえば、複雑さが増し、プロジェクトの期間が長くなった（要件の変更にかかる時間が長くなった）などによる2次式。見積もりは難しく、プロジェクトが大きくなるほど、正しく見積もりを行うことが難しくなります。
もう1つの理由は、optimizmに偏った見積もりです。入札に勝つために、最良のケースの見積もりが価格の計算に使用されます。プロジェクトが大きいほど、最良のシナリオである可能性は低くなります。入札ルールにより、最も楽観的なオファーが受け入れられる可能性が高くなります。したがって、5つのベンダーが現実的な見積もりを行い、6番目が楽観的すぎる場合でも、楽観的なベンダーが入札に勝ち、後で失敗します。したがって、これは一種のネガティブセレクションです。
コストは、「管理」の観点からスケジュールを除外するものではありません。ご存知のように、"9名の女性は1か月で赤ちゃんを産むことはできません"ですが、その金額に関連して問題が深く減少していると考える人の数に驚くでしょう。彼らに投げられました。悪いプロジェクト管理は、しばしばマイクロ管理の形で現れますが、私の経験では、ほとんどのプロジェクトがタンキングの主な原因です。ミクロ管理は、「管理」が何かが制御不能になっていることを認識し、その理由が分からない場合に起動します。
それが原因ではない場合、プロジェクトの予想される結果は、おそらく最初から十分ではありませんでした。私の経験では、プロジェクトの時間枠が短すぎると、人々は間違いを犯して「二重の作業」になり、何もほとんど行われなくなる恐れがあります。
これが、成功したプロジェクトを生み出した主要なチームの歴史を持つ経験豊富なプログラマーを経営陣に投入する必要がある理由です。そのような人は、可能な収益にもかかわらず、「責任を持ってそれを行うことはできません」と言うかもしれず、長い間管理されていないでしょう、それが私たちの多くが（最終的に）PHDではなくMBAに答える理由です。
プログラマー以外の人がプログラマーの採用を担当していた会社の数を失った。かつて、採用担当マネージャーが最近のスポーツイベントについて話したいと思っていたところ、インタビューを受けました（フットボールの試合だったと思います）。担当者がKnuthよりもNFLのコーチからインスピレーションを得た場合、プロジェクトは失敗します。
たまに、よく計画され、よく理解され、現実的で、一見単純そうに見える何かに出くわします。何らかの理由で、開発から6か月ですべてが逆転しました。それが起こります。まれに、プロジェクトの栄光のポークバレルになる根本的な原因はまれです。
それでも、私は認めなければなりません..あなたがニュースを見るならば、あなたはたまにオートバイ事故または列車事故を見るかもしれません。無事に毎日時間通りに到着する何百万ものオートバイや電車について聞いたことはありません。同じことがプロジェクトにも当てはまります。確かに、本当に悪い結果が出たものの公開剖検を見るのは興味深いですが、本当にうまくいったものについてはほとんど聞いたことがないでしょう。戦車にかけられたプロジェクトはまだ例外であり、標準ではないと思います。
プロジェクトが大きいほど、大規模な組織で働く可能性が高くなります。組織が大きいほど、管理のレイヤーが多くなります。管理の層が多ければ多いほど、悪いニュース（「私たちが手に入れることができるもののために私たちが欲しいものを手に入れることができない」）が指揮系統を構成することが難しくなります。悪いニュースがコマンドチェーンを構成する可能性が低いほど、ファンタジープランが受け入れられ、実行不可能であることがわかった後も長く保持される可能性が高くなります。
ほとんどの場合、次の2つ以上の組み合わせです。
- 部門間のコラボレーションの問題
- 政治...政治が多すぎる...
- 間違ったチーム
- 非現実的なスケジューリング
- 適切な方法論なしでスコープを変更する
- 不足している情報
主題に関する素晴らしい本： Death March 。
人々は、ソフトウェア開発は予測的なプロセスであり、1年先に物事を測定および推定しようとする傾向があると考える傾向があります。これは不可能です！ソフトウェアの構築はボルトの製造ではありません。
同じ「傾向」に従って、彼らはすべての可能性をカバーすると考えて巨大な分析（これも1年先）を試み、プログラマーを単なるタイピストに変えようとします。なぜこれがうまくいくと思いますか？この種の行動は、誤った見積もりと多くの官僚主義につながるだけです。
あらゆる規模のソフトウェアプロジェクトは、「失敗する傾向がある」または「コストが超過する」。角を曲がったビジネスでのコスト超過については聞いていませんが、do FBIバーチャルケースシステムやデンバー空港の手荷物処理システムなどについて聞いています。したがって、私は、すべての大規模システムに障害が発生するわけではなく、すべての大規模システムにコスト/スケジュールの超過が発生するわけではないと主張します。
時間通りに到着した大規模なシステム（スケジュールは1回であり、プロジェクト中に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か月で3,500万ドルになりました。
知名度の高い大きなプロジェクトは、「これは間違いです」と言って人々を落胆させます。間違いは許されません。
VonCの答えを少し詳しく説明します。
この大きなプロジェクトは、「オールオアナッシング」の考え方を持つ傾向があります。定義されたプロジェクトは一度にリリースする必要があります-多くの場合、既存のシステムからの変更のためです。
これは、機能/要件のクリープの問題への対処が困難であることを意味します。そのため、プロジェクトが実現すると、要件を満たさなくなったと見なされることがよくあります。これは、既存のシステムが更新された場合、または技術がその間に移行した場合に悪化する可能性があります。
これに対する解決策は何ですか？
2つのシステムを分割して、2つのシステム間で分割された関数のセットを変更して、2つのシステムを並行して実行する必要はないので、実際にはわかりません。
大規模なプロジェクトの複雑さは、外部の政治的圧力によって激しく悪化する可能性があります。 1つの部門が新しいシステムに何を求めているかについて非常に明確で焦点を絞ったアイデアを持っている可能性がありますが、関連する部門は、「そうですね、そうしている限り、なぜあなたはそうしないのですか？私たちにもこの小さな副次的な仕事をしますか？」あなたは「いいえ、それは範囲外です。」と言うことから始めるかもしれませんが、その後、人々の間の政治的内戦が始まり、誰もがパイを手に入れなければ、プロジェクトの予算は脅かされます。
何年もの間、地元の警察は、自動車システムを介して部分プレートを検索することができませんでした。これは、非常に単純な機能のようです。私は友人にこの機能を追加することの難しさを尋ねました、そして彼らは彼らが現代のデータベースへの切り替えを提案するたびに、自動車システムと何らかの相互作用をした州内の他のすべての部門が自分たちの部分を手に入れたかったと言いましたシステムも修正されました。その結果、ITの近代化は完全に強化されました。最後に、州はシステム全体の近代化の取り組みを実行するのに十分な資本を集めました。
触れられたがまだ対処されていない要因：
ほぼすべての劇的な失敗は、落札された契約です。このような状況で有能な会社はどうなりますか？彼らは現実的な見積もりをするので、間違った見積もりをした人によってほぼ確実に入札されます。
会社が適切に見積もることができない場合、彼らもシステムを適切に構築できないのは驚くべきことでしょうか？
この種のプロジェクトでアジャイルを使用できるか、それとも従来のアプローチが依然として最善です。
うまく適用されたアジャイルプロセスがこの問題にそれほど苦しんでいないように見える理由は、単純な理由によるものです。大規模なプロジェクトを機敏に開始することはできません。どちらかを選択できます。
アジャイルプロセスを使用すると、プロジェクトの将来の1〜2回の反復を実際に過ぎることはありません。次の2年間の「計画」はなく、次の2週間のみです。あなたの見方がそんなに短いとき、あなたはいくつかの妥協をしなければなりません。設計しているウィジェットの種類に関係なく、「ウィジェットの最後の単語」を作成する計画から始めることはできません。せいぜい「フロブできるウィジェット」から始めることができます。これは、1回または2回の反復で実行できるほとんどの作業に関するものだからです。
これの良い点は、数回繰り返した後、誰かが便利だと思う完成した実用的な製品が既にあることです。特に、およびゾート。
大規模なプロジェクトは、潜在的な顧客すべての問題をすべて解決することを目的としているため、本質的に失敗する可能性があります。アジャイルプロジェクトにはこの目標はありません。代わりに、各バージョンで、1人の顧客が持つ可能性のある1つの重要な問題に対処します。しかし、かなり長い間、アジャイルプロジェクトは多くの顧客にとって重要な問題の多くを解決しているかもしれません。
彼らはホフスタッターの法則を忘れました：ホフスタッターの法則を考慮に入れても、予想よりも常に時間がかかります。
- 実際のユーザーへの出荷の失敗
大規模なプロジェクトは、何年も「インフラストラクチャ」モードになり、実際のエンドユーザー機能の構築と出荷を忘れるという厄介な傾向があります。出荷時には、変更に非常に費用がかかります。通常、最大の概念的な変更は、最初の実際のベータテストが行われた後に尋ねられます。
- コストを正確に見積もることができない
プロジェクトが投資収益率を上回ると思われる場合、プロジェクトはキャンセルされます。
- 品質管理の失敗
十分な欠陥があると、前進運動量がゼロ以下になる可能性があります。まったく進歩がなければ、存続を主張することは困難です。
私がWeb開発で見たこと：
コックが多すぎる-重点が突然Webに移行した大手B＆M小売業者。突然、20の部門長が新しいヘッドチーズを印象付けるためのあらゆるイニシアチブを駆り立てています。法務部門は古いアイコンの外観が気に入らなかったため、以前は新しいアイコンを実装する必要がありました。
目標を達成するために仕様を一致させることに過度の注意を払う-「IE6のアイコンはIE7のアイコンに比べてわずかに色あせています。現在実施しているそのリリース日が重要な作業を中止し、顧客ベースの.05％に参加して、数日かかるひどいことを行ってください。 IEエクスペリエンスをさらに実装し、速度を落とす。 "
社内の開発者にアドバイスを求めることさえできなかった非開発者が選んだ悪いツール。
ツールによって選択された悪い開発者-「バージョン管理を使用するのがあまりにも知られていない、ほとんどコードを知らない200人のかろうじてコードを書ける人をアウトソーシングできるのに、なぜ20の有能なJava開発者にまともな給料を支払うのか？」さまざまな国で、主に3つの大きなアプリのバックエンドに取り組みます。
Bad/Broken Architecture-解雇された、または現在はマネージャーとなった人々による、パニックに陥った、昨日行われたコードのレイヤーを重ねたレイヤー。
ZDNetのMichael Krigsmanは、「 IT Project Failures 」に特化したブログを公開しています。
もう1つのポイントは、何年にもわたる長いプロジェクトでは、通常、検討すべきアップグレードまたは代替ソリューションのいずれかが存在することです。プロジェクトがクラウドでオンサイトで行われるようになり、何かが次第に浮上し始めます。これらを考慮すると、プロジェクトが開始されたときにこれは想定されていませんでした。たとえば、何かが6.0のときに開始することもできますが、最初のフェーズが完了するまでに6.3または6.4が出る可能性があり、いつアップグレードするかという質問がされます。要件が正しく収集されなかったか、誰かが考えを変えたために、スコープと目的の機能が変更されたことが、すでにかなりカバーされているもう1つのポイントです。