ITプロジェクト成功の鍵を握るビジネスユニットの関与

ITビジネスアプリケーションのプロジェクトが高い比率で失敗する理由の1つは、ビジネスサイドにある程度プロジェクトの責任を負える人物がいないことにある。プロジェクト承認当初の高揚感が徐々に薄れて実際の開発作業が始まると、ビジネスサイドは興味を失うことが多いようだ。その結果、ITプロジェクトのマネージャは、プロジェクトを成功に導くには自分が全責任を負わねばならぬと観念するのである。

ビジネスアプリケーションの開発プロジェクトを担うITマネージャは、たいていこの現象を経験している。ビジネスユニット内部にITプロジェクトを十分支援する人員がいないのは、興味や願望の欠如のせいばかりでなく、もっと重要な問題がほかにあるとビジネスセクションの経営陣が示唆するせいでもある。それで、ビジネスサイドの社員は開発中のITプロジェクトよりも自分の部署の日々の業務を優先すべしと解釈する。時として経営陣は、IT活動なのだからプロジェクトを成し遂げるのはIT部門の責任だと明言することさえある。

ビジネスユニットを関与させないのは、いくつかの点で正しくない。ビジネスアプリケーションの開発フェーズにおけるオーナーシップは共有プロセスという形を取るべきである。この考え方を認めようとしなければ、また、どんな理由であれ、ビジネスユニットがプロジェクトを支援する責務を果たそうとしなければ、成功の可能性は減る。

ビジネスユニット側が関与しないとプロジェクトが完成しないわけでもない。多くのプロジェクトは、関係者がまったく参加しなくても完成している。問題は、利益に与る関係者が全員当事者として開発の場にいたならプロジェクトはもっとずっとよいものになっていたのではないか、ということである。当初の目標に達しないビジネスアプリケーションプロジェクトが少なからずある事実を踏まえて、どの組織も関与を深めることに真剣に取り組むべきである。

IT部門がプロジェクトの事実上のオーナーシップを握ると、ITマネージャは、プロジェクトの進行を止めるわけにいかないので、どうしても一方的な決定をする。関係するビジネス問題の理解不足から、それらの決定に不備があることもある。そうした問題含みの決定は、結局、プロジェクトとプロジェクト・マネージャを悩ますことになる。

残念ながら、誰もプロジェクトのオーナーシップの問題をプロジェクトの成否を決する重要な要素と考えていない。多くの場合、事実は逆を示しているのに、プロジェクト・マネージャはプロジェクトの関係者全員が成功を約束するものと決めてかかっている。プロジェクトの論理的根拠がビジネスユニットに利益をもたらすことであるとするなら、これは必然的な仮定である。

これを解決するにはビジネスユニットの継続的な関与を確実にする手順を実施することだ。然るべき関与がなければ、IT部門はプロジェクトのオーナーシップを自動的に得ることになり、これは事態が悪い方向へ進んだときIT部門が非難されることも意味する。

私は、これまで多くのITプロジェクトを管理してきたが、すべて成功したわけでもない。確かに本番へ移行して会社の多くのニーズを満たしたが、ビジネスユニットが積極的に関与しなかったため、本来の能力を発揮できなかったプロジェクトもある。

しかし、これこそ成功と言えるプロジェクトもあった。それを何が成功に導いたか説明すれば、オーナーシップの問題を最初から解決しておくことがいかに重要かわかるだろう。

そのプロジェクトは、ある大企業の事業部に重要な財務アプリケーションを導入するものであった。幸い、その部門の部長はオーナーシップの問題の重要性を認識していて、その話は当然のことと最初から確約したのである。

プロジェクトが承認されると、部長は事業部内で4名のマネージャによる会議を招集し、彼らはプロジェクトへの参加問題を議題にのせると部長に報告した。そして、マネージャの1人をビジネスユニット側の常勤メンバとしてプロジェクトチームに参加させることにしたのである。プロジェクト期間中、ビジネスユニットの視点からプロジェクトの進行を見守ることが、そのマネージャの唯一の任務とされた。

そのため、彼はプロジェクトに専念でき、部長はそのマネージャの通常業務を他の3名のマネージャに振り分けたのである。それらのマネージャに対しては、プロジェクトに参加したマネージャをつまらぬビジネス問題で煩わすなとの指示が出された。4名のマネージャは、その部長に関する限り、プロジェクトが成功しても失敗しても全員が等しく責任を分かち合うことを了解した。4名全員が同じ気持ちだったことは間違いない。

プロジェクトの職務の配置に関してある決定を行った際、部長は覚え書きを発表し、それで事業部の社員全員にプロジェクトの経緯を示すとともにプロジェクトに関する基本原則と責任を明らかにした。この覚え書きによって、部長がプロジェクトを決定的に重要であると考えていることと、事業部の全員にその思いを共有して欲しいと考えていることが明らかとなったのである。

ITプロジェクトのマネージャとして、私はビジネスユニットの関心を引くことにいつも苦労していたのだが、その問題はこれで解決した。私が相手にした人物は、プロジェクト関連のビジネスニーズをよく心得ており、ビジネスユニット内の社員と良好な関係にあり、しかもプロジェクトの失敗はIT部門の責任に止まらないことをよく理解していた。さらに、この人物は事を進める権限を持っていた。結果として、私の質問に答え、問題を次々と解決し、アプリケーションを慎重かつ完璧にテストするための課題を一気に解決したのである。

プロジェクトのオーナーシップの問題と取り組み、それに積極的にかかわることでどんな利益がもたらされたか？実際面で言うと、プロジェクトがスケジュールどおり完了したことである。プロジェクトのトータルコストは当初の見積もりを超えなかったが、追加の出費に備えてプロジェクトの偶発危険準備金が多めに引き当てられた。アプリケーションの本番移行後に若干の修正が生じたが、それは些細なものであった。

プロジェクトをスケジュールどおり進めることができたのは、我々の質問にビジネスユニットが答えてくれたからである。また、ビジネスユニットはテストの出力を積極的に検討し、テスト結果をタイミングよく評価してくれた。プロジェクトの成功が彼らのボスにとって何にもまして重要であることを全員が理解すると、協力関係はいっそう高まり、通常のITプロジェクトでは考えられないほどの協力が得られた。オーナーシップの問題が解決するとプロジェクトのストレスが大きく減るのは興味深いことである。

このプロセスの効果は実際面のみならず、別の面でも重要な利益をもたらした。共同所有という傘の下で協力することによって、IT部門とビジネスユニットのメンバの間に揺るぎない関係が生じたのだ。プロジェクトの成否が共同責任であり、経営陣がその成果に大いに関心があることを関係者全員が理解したとき、真の協力関係が展開したのである。たまに事態が悪い方向に進むこともあったが、いつもの告発や非難合戦は起こらなかった。関係者全員が、失敗はグループの失敗であると理解していたからだ。そのため、非難よりも解決することに意識が向かったのである。

私は、このプロジェクトの成功が、その会社の今後のITプロジェクトの運営管理の方向を変更する1つのモデルになればよいと思った。このプロジェクトが終了して間もなく別の会社に移ったので、実際そうなったか知らない。思うに、これは人の常なのだが、ビジネスユニットの多くのマネージャは旧来のモデルを続けた方が都合がよいと考え、従前通りITに任せ、失敗したら非難といういつもの道を選ぶのではないだろうか。

このプロジェクトが成功したのは、部長が共同作業としてのプロジェクトの重要性を認識し、関係者にそのプロセスの重要性を積極的に説いたからにほかならない。経営陣がここまで踏み込まなければ、成功してもその可能性は限られたものになるだろう。

しかし、ITとビジネスユニットの間の協力関係にはもっと大きな利益を生む可能性があり、ITもビジネスサイドも含め、プロジェクトの関係者全員が、プロジェクトのオーナーシップに関与していることを認識し、それ相応の行動をすべきである。