« 2006年5月 | メイン | 2006年7月 »

2006年6月

2006年6月12日 (月)

【補助線】しい権限委譲

◆ガバナンスマネジメントは完璧なのか?

プロジェクトのガバナンスマネジメントとは、プロジェクトに対する各ステークホルダ(PMBOKで定義されている意味でのステークホルダ=プロジェクトマネジャー、プロジェクトメンバーも含むすべての関係者)の権限と責任を明確にし、その権限でプロジェクトにおける責任を果たしていくことである。

日本の組織にプロジェクトのガバナンスマネジメントの重要性を説いても、なかなか、理解してもらえないことが多い。例えば、プロジェクトガバナンスマネジメントの最も基本になるのはプロジェクトマネジャーにどのような権限を与えているかであるが、この点を聞いてみると、こういう答え方をする組織が多い。

 弊社ではプロジェクトマネジャーにプロジェクトマネジメントに関することは
 全面的に権限委譲している。プロジェクトマネジャーは全力を尽くして、
 プロダクトスコープを達成しなくてはならない

これには大きな前提がある。「制約条件を守る範囲において」という前提である。制約条件の中で共通の認識をしているケースが多いのは、利益(目標利益率)と納期である。プロジェクトマネジャーとしてはこれさえクリアすればあとは交渉ごとで基本的にそのイニシャティブはプロジェクトマネジャーにあると思いたい。

ところが、実は(プロジェクトの上位)組織はそうは思っていないケースが多い。一言で言えば、明確化されていないことはすべてガバナンスが組織側にあると思っていることが多い。

「権限委譲」をめぐるこの認識の違いはなぜ、起こるのだろうか?

◆プロジェクト憲章の位置づけ

一つはプロジェクト憲章の位置づけである。プロジェクトとはそもそも目的達成を第一義に、組織の規定(レギュレーション)を離れて実施するものである。ただし、まったく無法地帯では経営管理上の問題があるので、組織の規定に変わるルール(制約条件)をプロジェクト憲章で定め、それを以ってプロジェクトマネジャーを任命する。つまり、プロジェクトマネジャーを拝命するということは、プロジェクト憲章に書かれているレギュレーションを守ることを意味する。

例えば、組織の規定に「1社1000万円を超える取引は、口座を開設して行うこと」という規定があったとしよう。口座を開設するためには、なんやかんやで2ヶ月くらいの時間がかかる。これに対して、このプロジェクトでは「ひょっとすると」特殊な技術調達が必要になり、ベンチャー企業との取引が必要になる「かもしれない」とする。すると、プロジェクト憲章では、例えば、制約条件として「取引が1社3000万円以上になる場合には口座取引とする」という条件を決める。もちろん、最初の1社1000万円の規定は度返しである。しかし、プロジェクト憲章がこのように使われることはまずない。プロジェクト憲章は組織の規定より強く制約をした場合に使われることが多い。

組織の規定にしたがっていたのではうまく行かないからプロジェクトとして取り組む。しかし、プロジェクトには組織の規定を適用する。これでプロジェクトがうまく行くはずがない。

◆リスクの扱い

もう一つはリスクの扱いである。上の話も実はリスクの議論を含んでいるが、リスク対応策の実施の際に組織の規定が優先される。違う言い方をすると計画は承認するのだが、リスク計画は承認しない。実際にリスクが発生し、そのときに必要な対処の内容によって誰が意思決定するか考えようという取り決めにする。もっといえば、そんなことがあるとややこしいので、計画通りにやれという乱暴な議論をする。

今年度から開始した「プロジェクト計画書」セミナーで、プロジェクト計画書の段階的詳細化の話をすると以下のどちらかの反応が返ってくることが多い。

一つは、プロジェクトの計画段階で最後までの計画を策定して、承認を得ないと前に進めない仕組みになっているという話。もうひとつは、一旦、策定した計画はプロジェクト側に事情で変更できないという話。本質的には同じ話だが、なんとも考えさせられる話だ。

◆権限委譲の正しさをチェックする方法

Risk1 責任を全うするために必要な権限をといった議論をしだすと話は複雑になるが、実は権限委譲の適切さをチェックする方法はそんなに難しくない。

まず、プロジェクトのリスクに対して、プロジェクトで考えるべきリスクと、組織として考えるべきレベルのリスクに分ける。例えば、取引先の会社が倒産するといったリスクはこれはプロジェクトに大きな影響があってもプロジェクトで考えるべきリスクではない。このようなリスクというのは意外と多い。

その上で、プロジェクトレベルのリスクの対応策を検討する。そして、その対応策に必要な権限を分析する。すべての権限がプロジェクト憲章でプロジェクト(マネジャー)に与えられていれば、権限委譲は適切である。

実際にはプロジェクト憲章を発行する時点では、リスクが見えていないことも少なくない。そのような場合には、組織のレギュレーションで縛るのではなく、最低限、プロジェクトに課したい制約条件だけを決め、後は全面的に権限委譲する、つまり、組織のレギュレーションを無視する権限を与えることが望ましい。例えば、コスト関係でいえば

 ・目標とする収益率

だけを決めておき、組織のレギュレーションがどうなっていようと、決済なく支出できるようにする。これが権限委譲である。ここで組織のレギュレーションを生かしていると、例えば、調達でここが安いのでといった組織の不要な介入が入ることになる。これではプロジェクトマネジメントはうまく行かない。

◆ガバナンスマネジメントはPMOの役割

このようなガバナンスのマネジメントを行うには、組織がリスクに対して適切なマネジメントをしていることが不可欠である。組織が不必要にプロジェクトに介入しているのは、組織としてリスクが見えていない、扱いを決めていないといったリスクマネジメント不全が極めて多い。

組織側にたってこのようなリスクマネジメントとガバナンスマネジメントをするのはPMOの役割である。

【補助線】プロジェクトへの正しい権限委譲

◆ガバナンスマネジメントは完璧なのか?

日本の組織にプロジェクトのガバナンスマネジメントの重要性を説いても、なかなか、理解してもらえないことが多い。プロジェクトマネジャーにどのような権限を与えているかという質問に対して、こういう答え方をする組織が多い。

プロジェクトマネジメントに関することは全面的に権限委譲している

だから、ガバナンスマネジメントは万全であるという。ところが、実態はまずそうはなっていない。何かあれば、すぐにガバナンスはプロジェクトから組織に戻る。この認識の違いはなぜ、起こるのだろうか?

◆プロジェクト憲章の位置づけ

一つはプロジェクト憲章の位置づけである。プロジェクトとはそもそも目的達成を第一義に、組織の規定(レギュレーショ)を離れて実施するものである。ただし、まったく無法地帯では経営管理上の問題があるので、組織の規定に変わるルール(制約条件)をプロジェクト憲章で定め、それを以ってプロジェクトマネジャーを任命する。つまり、プロジェクトマネジャーを拝命するということは、プロジェクト憲章に書かれているレギュレーションを守ることを意味する。

例えば、組織の規定に「1社1000万円を超える取引は、口座を開設して行うこと」という規定があったとしよう。口座を開設するためには、なんやかんやで2ヶ月くらいの時間がかかる。これに対して、このプロジェクトでは「ひょっとすると」特殊な技術調達が必要になり、ベンチャー企業との取引が必要になる「かもしれない」とする。すると、プロジェクト憲章では、例えば、制約条件として「取引が1社3000万円以上になる場合には口座取引とする」という条件を決める。もちろん、最初の1社1000万円の規定は度返しである。しかし、プロジェクト憲章がこのように使われることはまずない。プロジェクト憲章は組織の規定より強く制約をした場合に使われることが多い。

組織の規定にしたがっていたのではうまく行かないからプロジェクトとして取り組む。しかし、プロジェクトには組織の規定を適用する。これでプロジェクトがうまく行くはずがない。

◆リスクの扱い

もう一つはリスクの扱いである。上の話も実はリスクの議論を含んでいるが、リスク対応策の実施の際に組織の規定が優先される。違う言い方をすると計画は承認するのだが、リスク計画は承認しない。実際にリスクが発生し、そのときに必要な対処の内容によって誰が意思決定するか考えようという取り決めにする。もっといえば、そんなことがあるとややこしいので、計画通りにやれという乱暴な議論をする。

今年度から開始した「プロジェクト計画書」セミナーで、プロジェクト計画書の段階的詳細化の話をすると以下のどちらかの反応が返ってくることが多い。

一つは、プロジェクトの計画段階で最後までの計画を策定して、承認を得ないと前に進めない仕組みになっているという話。もうひとつは、一旦、策定した計画はプロジェクト側に事情で変更できないという話。本質的には同じ話だが、なんとも考えさせられる話だ。

◆権限委譲の正しさをチェックする方法

責任を全うするために必要な権限をといった議論をしだすと話は複雑になるが、実は権限委譲の適切さをチェックする方法はそんなに難しくない。

まず、プロジェクトのリスクに対して、プロジェクトで考えるべきリスクと、組織として考えるべきレベルのリスクに分ける。例えば、取引先の会社が倒産するといったリスクはこれはプロジェクトに大きな影響があってもプロジェクトで考えるべきリスクではない。このようなリスクというのは意外と多い。

その上で、プロジェクトレベルのリスクの対応策を検討する。そして、その対応策に必要な権限を分析する。すべての権限がプロジェクト憲章でプロジェクト(マネジャー)に与えられていれば、権限委譲は適切である。

実際にはプロジェクト憲章を発行する時点では、リスクが見えていないことも少なくない。そのような場合には、組織のレギュレーションで縛るのではなく、最低限、プロジェクトに課したい制約条件だけを決め、後は全面的に権限委譲する、つまり、組織のレギュレーションを無視する権限を与えることが望ましい。例えば、コスト関係でいえば

 ・目標とする収益率

だけを決めておき、組織のレギュレーションがどうなっていようと、決済なく支出できるようにする。これが権限委譲である。ここで組織のレギュレーションを生かしていると、例えば、調達でここが安いのでといった組織の不要な介入が入ることになる。これではプロジェクトマネジメントはうまく行かない。

◆ガバナンスマネジメントはPMOの役割

このようなガバナンスのマネジメントを行うには、組織がリスクに対して適切なマネジメントをしていることが不可欠である。組織が不必要にプロジェクトに介入しているのは、組織としてリスクが見えていない、扱いを決めていないといったリスクマネジメント不全が極めて多い。

組織側にたってこのようなリスクマネジメントとガバナンスマネジメントをするのはPMOの役割である。

2006年6月 5日 (月)

続・PMOスタッフのスキルとキャリア

◆PMOスタッフのコンピテンシー

前回は、PMOのスタッフが持つべきコンピテンシーについて述べた。今回はそれをどのように育てるかを議論したい。

現業部門のスタッフというのは非常に難しいものがある。コーポレートスタッフはまさに組織を動かしている人であるが、PMOに限らず、現業部門のスタッフは支援業務的な色合いが濃い。支援というのは難しい概念である。自分が業務を実行するわけでもない。ラインマネジャーのように指示をして、任せるわけでもない。プロジェクトに対して、組織図の上には出てこない影響を与え続ける必要がある。

前回、重要なものを一つ挙げるとすればリーダーシップだと述べたが、同時に3つのスキルの重要性を指摘した。

一番目は対象業務スキルとしてのプロジェクトマネジメントスキルである。PMOのコンサルティング領域はいうまでもなくプロジェクトマネジメントであるので、このスキルがないことには前に進めない。

Leader1_1二番目はプロセスマネジメントのスキルである。標準プロセスを定義し、メトリクスを設定し、プロセス改善の指揮をしていく能力である。

三番目はマーケティングスキルである。つまり、プロジェクトやステークホルダがどのようなサービスを必要としているかを分析し、それらの情報に基づいて限られた資源をどのようにサービスに展開していくかを練り上げるマーケティングスキルである。

◆PMの経験は必須!

まず、最初の観点からはPMO人材には、小さなプロジェクトでよいので、プロジェクトマネジャーの経験をさせることが必要である。PMOの業務そのものを行うためには、PMP程度の基本知識があれば十分だと思われる。

また、実際に、品質管理の専門家などでプロジェクトマネジメントの経験なしにPMOの仕事をしている人も少なくないが、PMOの支援の中でどれだけ「リアリティ」、「現場感覚」がもてるかはサービスの質を決める重要な要素であるので、経験に越したことはない。

そのように考えると、キャリアとしてプロジェクトマネジメントのキャリアからPMOというのが望ましいと思われる。しかし、世間でよく言われるように、PMOとプロジェクトマネジャーのダブルキャリアというのは望ましくない。上に述べたように、プロジェクトマネジャーとPMOリーダーの共通点は基本的な知識と認識作りのための経験であり、一定のプロジェクトマネジメント経験ののちには、PMOとしての専門キャリアを歩んでいくべきである。

◆プロセスマネジメントスキルはトレーニングで

そこで問題になるのが、専門スキルである。これは一言でいえば上に述べたように、プロジェクトマネジメントに対するプロセスマネジメントのスキルである。これはある程度、トレーニングで身についていくと思われる。例えば、実テーマを題材にしたシミュレーション型の研修、ワークショップなどである。ただ、プロセスマネジメントのスキルの中で、論理的に割り切れないスキルがある。それは、人が絡んでくる部分である。

例えば、スケジュール遅れが目立っていれば、当然、生産性に関するメトリクスを入れるが、ここで注意する必要があるのは、メトリクスを入れることによって逆に生産性が下がってしまうことがある。計測負荷といった話ではなく、「やらされ感」が生じ、プロジェクトへの動機を下げてしまい、それが悪影響を及ぼすようなヒューマンファクターである。

このような問題は、トレーニングだけで解消するのは難しい。やはり、業務の中でしっかりと現場をみて、体感して、獲得していくしかないように思われる。

◆プロセスマネジメントスキルを本物にするマーケティングスキル

が、この問題に対するある程度の形式的なアプローチとしてマーケティングがある。闇雲に現場を見るよりは、マーケティングの基本知識を身につけた上で現場に出て、現場の声をマーケティング的な視点から分析していくことが重要だろう。

自分たちの施策をプロジェクトに対して受け入れてもらうためのリーダーシップはこれらの経験によって醸成されていく。同時に、トレーニングによって身に付けることができる部分もある。それはファシリテーションのようなコミュニケーションスキルである。これらに併せて取り組んでいくことが望まれる。

PMOのスタッフをどのように育てるか?

◆PMOリーダーのコンピテンシー

前の記事では、PMOのスタッフが持つべきコンピテンシーについて述べた。この記事はそれをどのように育てるかを議論したい。

現業部門のスタッフというのは非常に難しいものがある。コーポレートスタッフはまさに組織を動かしている人であるが、PMOに限らず、現業部門のスタッフは支援業務的な色合いが濃い。支援というのは難しい概念である。自分が業務を実行するわけでもない。ラインマネジャーのように指示をして、任せるわけでもない。プロジェクトに対して、組織図の上には出てこない影響を与え続ける必要がある。

前回、重要なものを一つ挙げるとすればリーダーシップだと述べたが、同時に3つのスキルの重要性を指摘した。一番目は対象業務スキルとしてのプロジェクトマネジメントスキルである。PMOのコンサルティング領域はいうまでもなくプロジェクトマネジメントであるので、このスキルがないことには前に進めない。二番目はプロセスマネジメントのスキルである。標準プロセスを定義し、メトリクスを設定し、プロセス改善の指揮をしていく能力である。三番目はマーケティングスキルである。つまり、プロジェクトやステークホルダがどのようなサービスを必要としているかを分析し、それらの情報に基づいて限られた資源をどのようにサービスに展開していくかを練り上げるマーケティングスキルである。

◆PMの経験は必須!

まず、最初の観点からはPMO人材には、小さなプロジェクトでよいので、プロジェクトマネジャーの経験をさせることが必要である。PMOの業務そのものを行うためには、PMP程度の基本知識があれば十分だと思われる。また、実際に、品質管理の専門家などでプロジェクトマネジメントの経験なしにPMOの仕事をしている人も少なくないが、PMOの支援の中でどれだけ「リアリティ」、「現場感覚」がもてるかはサービスの質を決める重要な要素であるので、経験に越したことはない。

そのように考えると、キャリアとしてプロジェクトマネジメントのキャリアからPMOというのが望ましいと思われる。しかし、世間でよく言われるように、PMOとプロジェクトマネジャーのダブルキャリアというのは望ましくない。上に述べたように、プロジェクトマネジャーとPMOリーダーの共通点は基本的な知識と認識作りのための経験であり、一定のプロジェクトマネジメント経験ののちには、PMOとしての専門キャリアを歩んでいくべきである。

◆プロセスマネジメントスキルはトレーニングで

そこで問題になるのが、専門スキルである。これは一言でいえば上に述べたように、プロジェクトマネジメントに対するプロセスマネジメントのスキルである。これはある程度、トレーニングで身についていくと思われる。例えば、実テーマを題材にしたシミュレーション型の研修、ワークショップなどである。ただ、プロセスマネジメントのスキルの中で、論理的に割り切れないスキルがある。それは、人が絡んでくる部分である。

例えば、スケジュール遅れが目立っていれば、当然、生産性に関するメトリクスを入れるが、ここで注意する必要があるのは、メトリクスを入れることによって逆に生産性が下がってしまうことがある。計測負荷といった話ではなく、「やらされ感」が生じ、プロジェクトへの動機を下げてしまい、それが悪影響を及ぼすようなヒューマンファクターである。

このような問題は、トレーニングだけで解消するのは難しい。やはり、業務の中でしっかりと現場をみて、体感して、獲得していくしかないように思われる。

◆プロセスマネジメントスキルを本物にするマーケティングスキル

が、この問題に対するある程度の形式的なアプローチとしてマーケティングがある。闇雲に現場を見るよりは、マーケティングの基本知識を身につけた上で現場に出て、現場の声をマーケティング的な視点から分析していくことが重要だろう。

自分たちの施策をプロジェクトに対して受け入れてもらうためのリーダーシップはこれらの経験によって醸成されていく。同時に、トレーニングによって身に付けることができる部分もある。それはファシリテーションのようなコミュニケーションスキルである。これらに併せて取り組んでいくことが望まれる。

PMstyle 6月~9月公開講座(★:開催決定)

PMstyle facebook

Twitterアカウント(PMstyle)

カテゴリ

Googleメニュー

  • スポンサーリンク
  • サイト内検索
    Google

最近のトラックバック

Powered by Six Apart

プロフィール

フォトアルバム

好川哲人

技術士&MBA 技術経営のコンサルタントとして、数々の新規事業開発や商品開発プロジェクトを支援、イノベーティブリーダーのトレーニングを手掛ける。「自分に適したマネジメントスタイルの確立」をコンセプトにしたサービスブランド「PMstyle」を立上げ、「本質を学ぶ」を売りにしたトレーニングの提供をしている。