プロジェクトの「補助線」

【補助線】正しい権限委譲

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

◆リスクの扱い

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

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

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

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

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

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

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

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

　・目標とする収益率

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

◆ガバナンスマネジメントはＰＭＯの役割

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

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

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

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

◆リスクの扱い

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

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

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

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

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

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

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

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

　・目標とする収益率

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

◆ガバナンスマネジメントはＰＭＯの役割

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

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

続・ＰＭＯスタッフのスキルとキャリア

本ブログは移転しました。こちらをご覧ください。

◆ＰＭＯスタッフのコンピテンシー

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

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

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

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

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

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

◆ＰＭの経験は必須！

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

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

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

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

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

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

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

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

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

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

ＰＭＯのスタッフをどのように育てるか？

◆ＰＭＯリーダーのコンピテンシー

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

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

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

◆ＰＭの経験は必須！

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

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

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

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

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

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

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

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

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