ITプロジェクトはなぜ失敗するの?

「先生、質問があります。こんなに詳細な計画を立てるのに、なぜ、失敗するITプロジェクトが多いのですか?」
私が非常勤講師をしている北海道大学大学院生から授業の最後で、投げかけられた鋭い質問です。
皆さんは、どう回答しますか?
今日は、一連のプロジェクト計画作成をお休みして、この質問について、考えてみたいと思います。


プロジェクトの成功とは、どのような状況なのでしょうか。
プロジェクトが期間内に、予算の範囲で、予め定義された品質を実現して終了した場合をプロジェクトが成功したと考えます。
上記に加え、最終ユーザがプロジェクトの結果に満足し、当初より定義していた最終目標を達成できたときにも、プロジェクトが成功したと言います。
本来であれば、後者のほうをプロジェクトの成功ととらえると思いますが、評価を下すには、プロジェクトが終了してある程度の期間を経なければなりません。
ここでは、前者をプロジェクトの成功ととらえて議論を進めます。
質問への回答を考えると、一言では言い表すことができません。原因が錯綜しています。
まず第1に、最近のITプロジェクトは、ベンダー任せ、丸投げ傾向が強くなっていることが挙げられます。ベンダーの言いなりにプロジェクトが進む。
かといって、ユーザ企業が明確に作業範囲を定義しているかといえばそうではありません。何でもかんでも押し込もうと考えるユーザ企業が多いのも事実です。
従って、詳細な契約書を作ることもありません。仮に、詳細な契約書を作ったとしても、「これは契約範囲外です」なんて答えると、怒り出すユーザが大半です。
第2に、上記と関係がありますが、ユーザ側のシステム担当者がリスクを回避し、何か問題が発生すれば、ベンダーの責任に押し付けようという考えが強くなってきています。
自分たちのシステムですから、最終責任は自分たちにあるという意識が希薄になっているのではないでしょうか。
第3に、立上げフェーズで、プロジェクトの目的、性格、範囲、前提条件、制約条件などを明確に定義できていないことです。
前にも書きましたが、前提条件が変われば、プロジェクトの性格も変わり、目的さえも変更せざるを得ない可能性が大きくなります。
第4に、システムは、目に見えないものですから、明確に品質を定義することができません。バグ0%を品質標準にしてしまうと、プロジェクトが終了しません。何もバグを作ろうと思ってはいないのですが。
だからこそ、ユーザとベンダーの間で、品質についての合意が必要になります。
第5に、ITプロジェクトでは、リスク管理が十分になされているとは思えません。課題の管理は十分に行なっているのですが、リスク管理は…
リスクとは、将来起こる可能性があるプロジェクトにマイナスの影響を与える事象のことを指します。(PMBOK第3版からは、プラスの影響も含まれるようになりましたが)
課題とは、現在起こっているプロジェクトにマイナスの影響を与える事象です。そういう意味で、リスクは起こってしまえば、課題となります。
リスク計画は、起こったときに「あわてない」ようにするための計画です。
まだまだ、コミュニケーションの問題とか、チームビルディングの問題とかありますが、上記のようなことが大きな原因ではないでしょうか。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*