人気ブログランキング | 話題のタグを見る

プロジェクト・スポンサーシップが足りない

アメリカにNeal Whittenという著名なプロジェクト・マネジメントのコンサルタントがいる。何年か前に、ボストンで彼の講演を聴いたことがあった。彼はその中で、プロジェクトが失敗する三つの主な原因を挙げていたのだが、それがずっと頭にひっかかって残っている。彼のいうプロジェクトの三つの失敗理由とは、以下のようなものだ:

(1) プロマネのハード・スキル不足
(2) プロマネのソフト・スキル不足
(3) プロジェクト・スポンサーシップの不足

プロジェクトの失敗の理由がプロマネに帰されるのは、ある意味、当然のことだ。Whittenはプロマネの能力を、ハード・スキルとソフト・スキルとに分解する。ハード・スキルとは、知識や技法など、いわゆる座学で習得できる種類のものである。WBSだとか、PERT/CPMだとか、パラメトリック見積法だとかいった事柄で、これらは技術として移転可能なものである。わたしの言い方では「マネジメント・テクノロジー」であり、これを使いこなせる能力を、ハード・スキルと呼ぶ。

二番目のソフト・スキルとはむしろ、座学では学びにくい、より属人的な習熟を要する能力だ。交渉力だとか、指導力だとか、問題解決力だとか、後進育成とかコミュニケーションの能力など。わたし達の社会ではよく「人間力」などと称される。いわゆるリーダーシップとも、重なる点が多いだろう。

ところで、三番目の「プロジェクト・スポンサーシップの不足」という指摘には、意表をつかれた。プロジェクトの失敗の、いわば1/3は、プロマネ以外のところが原因で起きる。彼は経験をもとに、そう主張する訳だ。では、プロジェクトのスポンサーシップとは何か。

米国のPM関係の大会では、物事を理解するデフォルトの枠組みはPMBOK Guideと、PMP資格である。わたしもPMPは持っている。だが、PMOのメンバーとして社内のいろいろなプロジェクトを見ていくうちに、それだけでは次第に物足りない点を感じるようになっていた。

PMBOK Guideはたしかに、「プロジェクト」という枠組みの中で、それをいかに効率的に遂行するかを教える。しかし、そもそもプロジェクトの枠組みを与えるのは誰か。またプロジェクト・マネージャーを任命するのは誰なのか。プロジェクトがうまくいかなくなり、たとえ完遂しても価値を生み出さないことが明白になったとき、プロジェクトを止める権限があるのは誰か?

それは、プロジェクト・スポンサーである。

プロジェクト・スポンサー(業界によっては「プロジェクト・オーナー」ともいう)は、上級マネジメント層を代表して、プロジェクトをウォッチする。だから、重要なプロジェクトの場合は、役員かそれに準ずるレベルの人がなる。中小規模の場合は、プロマネの所属する部門長がやるだろう。
(もしプロジェクトが上位プログラムの一部である場合は、通常はプログラム・マネージャーがその役割を果たすか、あるいは自分のプログラム・オフィスのスタッフにその権限を委譲するはずである)

わたしは勤務先でPMOの仕事を何年間もやってきた。それなりの数のプロジェクト・レビュー会議に参加し、またプロマネ達のマンスリー・レポートをウォッチもした。念のためにいうと、社内にいるベテランのプロマネ達は、わたしなんかよりずっとマネジメント能力があり、技法などについても熟知している。なのに、なぜPMOによるウォッチや助言が必要なのか?

それはスポンサーのためなのだ。多忙なプロジェクト・スポンサーに、配下のあのプロジェクトはきな臭い煙が出ています、近いうちに火の手が上がるかも知れませんよ、と告げる。それがPMOの重要な仕事なのである。ちょっとPMとじっくり話してみてください、と。

なぜ、プロマネが直接、スポンサーに自分のピンチを告げないのかというと、通常は、問題を押さえ込めると自分で思っているからだ。わざわざ報告の要はない、と。プロマネという人種は楽天的で、自信家だ。そうでないと、プロマネはつとまらない。まあ、たまにはプロマネが自分のプロジェクトで問題が起きているのに気づかない場合もある。PMOは全部のプロジェクトを横並びで数値的に比較しながら見ているから、そのような異常に敏感になっている。むろん、異常がつねに病気とは限らないのだが、アラームはならすことになる。プロマネから見れば、自分が十分マネージしているつもりなのに、横で小うるさいことをスポンサーに進言する心配性のPMOなんか、うるさい限りだ。スコアラーは黙って試合を見てろ--そういう気持ちにもなるだろう。ある意味、PMOはせつない役回りである。

むろん、本来はPMOがいようがいまいが、プロマネと、それを管掌するスポンサーとの間には、定期的なコミュニケーションがなければいけない。
スポンサーはプロマネを任命し、支援する。
プロマネはスポンサーに報告し、相談する。
--これが両者の間の役割だ。

そしてプロマネの悩みとはたいてい、予算が足りないか、人が足りません、なのだ。(時間が足りません、ということもあるが、通常はお金か人をかければ期間は短縮できる)。そこでスポンサーは、トップ層を動かして、予算をつけたり、他部門から必要な人を持ってくるような働きが必要とされる。つまりスポンサーもまた、「実力」がないといけないのだ。

逆に言うと、プロジェクトにおいて、プロマネだけの能力と努力でできることには、一定の限度があるということだ。わたしの実感でも、プロジェクトの成否のうち、プロマネの権限内で達成できる部分はせいぜい2/3程度である。場合によっては、もっと少ない。それ以外の部分は、プロマネが任命される以前に決まっていた枠組み(契約条件等)とか、プロマネがコントロールできない社内の配員や、外部環境の変動(たとえば為替リスクだとかベンダーの倒産だとか)などで、成功か失敗かが決まってしまう。

つまり、与えられたプロジェクトという枠組み、所与の制約条件(予算・納期・スコープ)の中だけで、プロジェクトの成功率を上げることはできないのだ。したがって、プロジェクトの成功率をもっと向上したかったら、会社が本気でプロジェクトを支援する仕組みづくりが必要となる。

受注型プロジェクトの場合は、受注側のプロマネの上に、プロジェクト・スポンサーがおり、発注側にも本来はプロマネとスポンサーがいる。したがって、両者のスポンサーが定期的に(たとえば年4回とか隔月とか)で会合を持ち、プロマネのレベルでは解決できなかった問題(イシュー)を話し合い、なんとか解決に持ち込むことが望まれる。少なくとも、わたしが知る限り、エネルギー系の海外プロジェクトでは、そういう仕組みが常識化している。

では、プロジェクト・スポンサーという役割の人が、具体手にするべき仕事の内容は何か?

わたしの知る限り、ISOをはじめとして、米国PMIや英国OGC、日本のP2Mなどでも、スポンサーについて定めた標準書はほとんど存在しない。唯一知っているのは、GAPPS Initiativeの定めたStandardである。昨年、GAPPSのワークショップが日本で開催されたとき、わたしも手伝ったのだが、そのときはまだスケルトンだった。今年はドラフト段階まで来ている。
http://globalpmstandards.org/tools/gapps-pm-standards/project-sponsors/
これによると、スポンサーの役割は大きく三つある:

(1) プロジェクトのAccountabilityを引き受ける
(2) プロマネを支援する
(3) プロジェクトを支援する

最初の「(1) プロジェクトのAccountabilityを引き受ける」、とは、プロジェクトの意義を明確にし、有効なガバナンスを確立し、プロジェクトの生み出すアウトカムと便益が現実に役立つよう計画する、などを含む。Accountabilityとは『説明責任』などと訳されることも多いが、ふつうは説明行為だけではなく最終的な責任を引き受けることを指す(わたしは『面目責任』と訳した方がいいと思っている)。

つぎの「(2) プロマネを支援する」は、プロマネに時間を割いてやり、プロマネレベルでは解決しにくい紛争や問題について助けてやり、またプロマネ自身のパフォーマンスについて率直に評価・助言してやる、が含まれる。そして「(3) プロジェクトを支援する」とは、リソース(配員や資金など)面で助けてやり、ステークホルダーにプロジェクト状況を見えるようにし、適切なプロジェクト・レビューと意思決定がなされるよう組織を動かす事を指している。
プロジェクト・スポンサーシップが足りない_e0058447_19482827.gif

もっとも、こうしたスポンサー制度の説明をすると、そんな風に上からプロマネを支援するなどしたら、プロマネの「甘え」を助長するからよくない、といった論議をする人が出てくる。何を甘えたことを言っているのか、寝言を言うな、と。

たしかに自分の判断を放棄して、すべてをスポンサーに相談し依存してくるプロマネがいたら、「甘えるのもたいがいにしろ」と叱るべきだろう。ある程度は厳しくしてこそ、育つ責任感というものもある。だが、そもそも組織がプロジェクトを遂行する目的は、何だろうか。一切の助言や支援を「甘え」の名前でシャットアウトして、本当に企業としてそれでいいのか。顧客やステークホルダーに迷惑をかけ、赤字を増大し、自社の信用を毀損するようなプロジェクトを放置してまで、プロマネの「甘え」を拒絶することで得られるものは何があるのか? 物事にはどこかに、適切な限界があるべきだろう。イエスかノーか、0か100かで決められるほど、マネジメントとは単純な仕事ではないはずだ。

ご存知の通り、日本におけるプロジェクト・マネジメントの普及とブームは、2000年以後におきた。その中心はIT産業、とくにSI(システム・インテグレーション)と呼ばれる受託ソフトウェア開発の分野である。SIerと呼ばれる業種において赤字プロジェクトの頻発が問題となり、業界全体の悩みとなったし、その結果生まれた労働環境の劣化は、優秀な人材をリクルーティングする障害になった。

PM論がはやる以前のキーワードは、『リーダーシップ』だった。「お前はプロジェクト・リーダーなんだから、リーダーシップを発揮しろ! それでなんとか困難を切り抜けろ!」と号令することで、赤字や納期問題を解決しようとしていた。意地わるくいえば、上司は問題を、部下であるリーダーに、リーダーシップなる魔法の言葉で、『丸投げ』していた訳である。

さいわい、プロジェクト・マネジメントという概念と知識体系が普及することによって、そうか、プロマネには、身につけるべきスキル・セットがあるのだな、という認識が進んだ。多くのSIerが社内でPMP資格取得を奨励したのも、こうした理由が大きい。こうした活動の結果、10年間で、PM論に対する認識はかなり普及したといっていい。また、社内レビューなどの制度的な前進もあって、赤字プロジェクトはある程度、減少したという調査結果もある。しかし、では業界の悩みは解消したかというと、わたしの聞く限りは、そうではない。

そして、なまじPM論の知識が広まったが故に、「プロジェクトの失敗は、プロマネのマネジメント能力不足である」という認識も、妙に広まってしまったように思える。つまり、問題解決を部下であるプロマネに丸投げする上司の体勢自体は、あまりかわっていないのだ。単にキーワードが、曖昧なる『リーダーシップ』から、舶来風の『プロジェクト・マネジメント』に昇格(?)しただけである。人によっては、PMの最大のポイントはプロマネのリーダーシップである、と論じて、わざわざ論点をプロマネ個人の資質に引き戻したりしている。

ここで最初のN. Whittenの「プロジェクトの三つの失敗理由」を思い出してほしい。プロマネ個人のリーダーシップは、もちろん非常に大切だ。だが、それはプロマネの「ソフト・スキル」である。また、PMBOK Guide的な知識と技法の習得も、必要である。それはプロマネの「ハード・スキル」部分だ。だが、それらと並んでもう一つ、プロジェクトへの「スポンサーシップ」も、企業にとっては必須なのである。

スポンサーは、トラブルがひどくなったら自分で出て行って混乱を食い止め、プロマネが倒れそうになったら支え、顧客やステークホルダーを説得して終結まで持ち込むだけの、覚悟が求められる。逆にプロジェクトがうまくいったら、部下であるプロマネを賞賛する。つまりスポンサーという仕事は、良いときは部下を誉め、まずい時は自分が責任をひっかぶる、割にあわない商売である。そういう役割なのだ。そのおかげで、部下であるプロマネが育っていく訳だ。

そして、スポンサーのさらに上位にいる経営層は、スポンサーがきちんと自分の仕事をして、プロマネを育成しているかどうかを評価する。成功したらプロマネの功績を横取りし、失敗したらプロマネに責任をかぶせるような、本来とは逆のことをしていないか、監視する。これが、あってほしい企業の姿だろう。

もう一度いうけれども、プロジェクトは、プロジェクト・スコープという枠の中だけで評価してはいけない。プロジェクトを取り囲む、企業のより大きなコンテキスト(文脈)の中に位置づけて、考えるべきなのである。プロマネに文脈を与えて、上位の戦略や外部環境とアライメントをとるのが、スポンサーシップの役目であろう。
by Tomoichi_Sato | 2015-07-08 19:52 | プロジェクト・マネジメント | Comments(0)
<< 書評:「日本的マネジメントの感... トヨタのグローバル・サプライチ... >>