「ステークホルダー特定」プロセスは、数少ない立ち上げプロセス群の1つだ。ということは、プロジェクトやフェーズのかなり初期段階で行うプロセス、ということになる。確かに、ステークホルダーが誰か分かっていないと、プロジェクトを先に進めることもできないものね。
そう思って参考書を眺めていたら、興味深いことが書いてあった。「ステークホルダー特定は、プロジェクトのライフサイクル全てを通じた継続的なプロセスである」だって。そっか、当初は頭数に入ってなったけれど、プロジェクトが進んでいく途中で参加することになる人もいるし、プロジェクトに深く関わっていた人が突然配置換えになって関係なくなる、ということだってあるもんね。ステークホルダー特定を1回だけやっておしまい、ということではないのね。
あれ? 主なステークホルダーの例には、
って書いてある。
プロジェクト・チームやプロジェクト・マネジャーって、ステークホルダーの中には入らないのね。そりゃ、そうか。ステークホルダーって、プロジェクトに影響を与えたり、プロジェクトから影響を受けたりする人のことだから、そのプロジェクトそのものを回している、いわば「中の人」はステークホルダーには含まれないんだ。
とはいえ、プロジェクト・マネジャーは、プロジェクト・チームのメンバともきちんとコミュニケーションをとっていかないといけない。そうか、ステークホルダー・マネジメントと、コミュニケーション・マネジメントのプロセス群が分かれているのって、そういう意味もあるのね。
わたし で、立上げの後にくるのが「ステークホルダー計画」プロセスになるわけね。ここはきっと、他のプロセス群と同じかな。参考書にはなんて書いてあるかなぁ。あ、あった。なになに……、
「プロジェクトがステークホルダーへ影響を及ぼす方法を特定する」
……。ん? プロジェクトが? 影響を及ぼす? 主語はプロジェクト?! ちょっと、違和感を覚えるかも。
プロジェクトを円滑に進めることを目的として、ステークホルダーがどのようにプロジェクトに関わってくるのか、賛同者をどう鼓舞するのか、反対勢力をどう手なずける(?)のか、ということが、ステークホルダー・マネジメントじゃないの?
タイム・マネジメントは「タイム“を”マネジメント」するし、コスト・マネジメントは「コスト“を”マネジメント」するんだから、ステークホルダー・マネジメントは「ステークホルダー“を”マネジメント」するんだよね。
1人で悶々と悩んでいても仕方ないから、参考書を開いてみた。
読み進めると、「プロジェクトがステークホルダーへ影響を及ぼす方法を特定する」ことで、プロジェクト・マネジャーが、プロジェクトにおけるステークホルダーを効果的に関与させ、ステークホルダーの期待をマネジメントし、最終的にプロジェクト目標を達成へと導くためのさまざまな方法を考案することが可能となる――と書いてあった。むむむ、ちょっと整理しよう。
そもそも、プロジェクト・マネジャーに求められるのは、プロジェクトの成功のはず。「成功」の定義はいろいろあるけれどね。で、プロジェクトを成功させるためには、前述の通りステークホルダーに協力的に関与してもらわないといけない。
積極的に関与してくれる人はいいとして、反対勢力になりそうな人は説得したりお願いしたりして、(失礼な言い方だけど)少なくともプロジェクトを進める上での障害、障壁にならないようにするのよね。で、そのステークホルダーへの働きかけをプロジェクト・マネジャーがする……のよね?
実は「在宅ヘルプデスク業務開設プロジェクト」にも、少なからず反対勢力がいる。
Copyright © ITmedia, Inc. All Rights Reserved.