プロジェクトオーナーはなぜ必要なのか？

プロジェクトオーナーからのお叱り

「なぜそんなに予算オーバーしているんだ！」
「そもそも業務統合ができないなら意味がない！」
「現場のワガママを聞きすぎなんじゃないか」
「このプロジェクトは一度保留とする」

ベンダーの提案プレゼン後に、プロジェクトオーナーである役員Aさんに呼び出されました。そして厳しく叱られました。

このプロジェクトでは、最初の企画段階でAさんの承認をもらっていました。その後、現場要求を整理し、RFPを作成します。ベンダーから提案書を受け取ると、予算の約2倍となっていました。

今回、プロジェクト方針として「業務の統合」があります。そのため、システムも標準化するため、パッケージシステムの導入で進めていました。

ところが、各現場と調整を進めたところ、反発が非常に大きく、難航しました。その結果、パッケージへのカスタマイズが膨大となり、費用が一気に跳ね上がります。業務の統合ができたのはごく一部、ほとんどは従来のままとなりました。

プロジェクト側は個別要求に優先順位をつけて、予算内におさまるよう調整をします。しかし、各業務とも譲らず、取り下げる要求はほとんどありませんでした。

プロジェクトマネージャーのSさんは、各現場の要求も無視できず、いったんこのままベンダーへの見積もりをとってから考えることにしたのです。

大きな改革だからこそトップダウンが必要

あらためて考えてみましょう。

過去に経験した「失敗プロジェクト」を頭に思い浮かべてください。

そのプロジェクトは、プロジェクトオーナーと距離がありませんでしたか？

何かあったらすぐ相談に乗れるような関係でしたか？

おそらくほとんどの回答は「No」ではないでしょうか。

なぜなら、役員クラスのプロジェクトオーナーが介入すれば、ほとんどの問題は解決するからです。

特に部門間の調整で難航した場合は、プロジェクトオーナーの出番です。

「この件はオーナーに判断してもらいますがよろしいですか？」
と場をおさめることができ、それ以上にこじれることはありません。

そもそも、現場に意見を求めたところで「今の業務が正しい」と言うに決まっています。大きな改革をしたいのならば、まずは「トップダウン」で改革の意思を伝えた上で、プロジェクトを進めるべきです。

「ボトムアップ」を否定するわけではありません。現場から課題を吸い上げることは大事です。

ただし、それらの要望をすべて取り込んでしまうと、業務の統合や標準化が難しくなってしまいます。

システムは複雑化し、カスタマイズ費用が大きくなり、予算オーバーとなります。

そのような時こそ、オーナーに相談しにいくのです。

「経営判断としてどこまでカスタマイズを許容し、システムにお金をかけるか？」

つまり、プロジェクトメンバーでは解決できない「上位レベル」の問題を解決するのが「プロジェクトオーナー」の役目となります。

だからこそ、プロジェクトオーナーは、プロジェクト体制図のトップに位置します。その業務を担当する役員クラスが務めます。ちなみに、IT担当の役員を置いても「そこは業務側に判断してもらえ」とたらい回しに合うだけで解決しません（実は、この失敗は多かったりします）。

オーナーは平穏時には、状況を見守っているだけで表には出てきません。ところが、いざ解決が難しい問題が出てきた場合、オーナーの介入が解決のカギを握ります。

問題のないプロジェクトなどありません。問題がないとしたら、それはプロジェクトではなく単なるタスクです。難しいからこそ、プロジェクト化しています。

そんな難しいプロジェクトの成功には、オーナーの積極的な関与が不可欠です。オーナーの強力な後ろ盾があるからこそ、プロジェクトメンバーも大きな変革を推進できるのです。

情シスがプロジェクトオーナーとの関係を取り持つ

冒頭のプロジェクトは、プロジェクトオーナーと疎遠でした。

それが失敗の直接的な原因です。

もっともっと、プロジェクトオーナーに相談できる関係を築いていくべきでした。

そして、間接的な原因としては、情シスがPMOとしてフォローが至らなかったこと。

業務部門はプロジェクトに不慣れです。だからこそ、情シスがプロジェクトのノウハウを持ち込み、プロジェクトオーナーとの「定例会」を設計するべきでした。

また、業務部門にとっては、オーナーが偉すぎて、みんな遠慮してしまいます。だからこそ、客観的な立場の情シスが、積極的にオーナーに相談するよう背中を押すべきでした。

貴社の情シスは、プロジェクトオーナーをうまく巻き込んで、プロジェクトを「ドライブ」できていますでしょうか？