日経コンピュータ2013年10月3日号の極言暴論というコラムに「感動するバカ、怒るアホウ」と題し、ＩＴプロジェクトの開発体制を固められないユーザーを揶揄する記事が掲載されていました。
「ＩＴ部門と事業部門の意志疎通が極めて悪いため、要件がまとまらず揺れ動き、プロジェクトの途中でも肥大化するのは必至」という危ない客に対したベンダー側の対応が描かれています。
ひとつは自社の能力ではできないと固辞するコンサルタントがかかわったプロジェクト、もうひとつはリスク分を反映して高い見積もりを提示したＩＴベンダーがかかわったプロジェクトです。
両プロジェクトとも別のＩＴベンダーに替えて開発を進めた結果、泥沼プロジェクトとなったようです。
自社の能力ではできないと固辞したコンサルタントの会社では、ユーザー企業の体制ではどうにもならないと匙を投げたのでしょう。せっかくコンサルティングを受注し、ユーザー側も開発を引き受けてくれと頼んだにもかかわらず、固辞したと書かれています。
リスク分を反映して高い見積もりを提示したＩＴベンダーは、他社が出てくることを想定していなかったのかもしれません。ユーザー企業はうちの会社以外には頼めないだろうと見くびっていた可能性も考えられます。いずれにしろ、どれだけのリスク分を上乗せするかについては、明確な金額は出せないはずですから、社内で議論になったことでしょう。
コンサルタントの見捨てたプロジェクトを代わりに受注したＩＴベンダーは、予想外のチャンスに飛びついたのかもしれません。ユーザー側体制のリスクについては、わからなかったか、わかっても見えないふりをしていた可能性もあります。受注のチャンスにリスクを見ようとしないのは、ありがちな心理です。
受注の結果、営業部門は社内で表彰され、責任者は昇進したかもしれません。ところが、数年後のプロジェクトサービスイン後は、システム開発責任者は大幅な納期の遅延と、費用の増加の責任をとらされ左遷されたかもしれません。最初の会社が見捨てたプロジェクトであることを考えると理不尽な結果に思えます。
高い見積もりを提示したＩＴベンダーの代わりに受注したＩＴベンダーでも、受注前に受注すべきか、受注するとしたらどれだけのリスクを見込んで見積もりを提示するかという議論があったことは推測できます。
それにもかかわらず泥沼プロジェクトとなってしまったのは、想定外のリスクが存在したのかもしれません。こちらの方は、プロジェクト開始前にある程度のリスクは想定できたはずですから、最初のプロジェクトよりはましかもしれません。
これらのプロジェクトは具体的なプロジェクトを想定したものではなく、ありがちな例として書かれたのかもしれません。ＩＴシステムの開発プロジェクトは４分の３以上が失敗しているといわれた時期もありました。現在でも大幅にサービスインが遅れ、費用が超過するプロジェクトは後を絶ちません。
日経コンピュータがユーザー側に主な原因あるプロジェクト失敗について書くことは、創刊当時にはありませんでした。当時は、プロジェクトの失敗はプロジェクト管理が悪かったとされ、プロジェクト管理さえきちんとすればプロジェクトはうまくいくという考えがはびこっていました。
プロジェクト管理者としては、プロジェクトをスタートさせないことしか失敗を避ける方法がないプロジェクトがあります。
受注することが失敗であるプロジェクがあることを、多くの人に知らしめることも日経コンピュータのような雑誌の存在意義です。
