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

【補助線】価値観はあるか

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

◆クールビズはなぜ、難しいか

チェンジマネジメントの難しさを例えるのによく使われる例がある。みなさんの会社でもクールビズをやっている会社は多いと思うが、「冷房を入れる」のと、「冷房を切る」という２つの行動の違いである。単純な話だが

　暑い
　　→　冷房を入れる
　　　　　　→　涼しくなって気持がよい
　　　　　　　　　⇒　【繰り返し行われる】

　涼しい
　　→　冷房を切る
　　　　　　→　暑くなって能率が下がる
　　　　　　　　　⇒　【やらなくなる】

という話で、冷房を入れる習慣（？）はすぐに身につくが、冷房を切る習慣はなかなか身につかないということを示す例だ。チェンジマネジメントとは、冷房を切るような習慣を作るマネジメントであることが多い。

このためには「クールビズ」といったルール（仕組み）を作ることも必要だが、ルールだけでは不十分で、地球環境を守ろうといった「価値観」が定着されて始めて冷房を切る習慣ができるという話だ。この価値観の定着にこそ、チェンジマネジメントの本質がある。

◆プロジェクトマネジメントが定着しない２つの理由

これをプロジェクトマネジメントに例えてみると、なぜ、定着しないかがよくわかる。大きな理由は２つある。

一つ目は、繰り返しが行われるループの経験、つまり、成功経験がないことだ。プロジェクトマネジャーのＡ氏は、プロジェクトマネジメント批判の先鋒だった。しかし、あるプロジェクトでしぶしぶやったリスク識別と、リスク対策の策定が、窮地を救った。この中で、リソース調達のリスクについて言及しており、その計画をレビューした上司が密かに根回しをしていてくれた。これで、実際にショートし、相談したら、すぐに「Ｂさんに相談しろ」といわれ、簡単にリソースが確保できた。これまでだと、期待せずに一応相談はするといった感じだったのだが、目からウロコだったそうだ。これを契機にＡさんは、計画の共有を主眼にきちんとした計画を書き、いろいろな人の意見を聞くようになった。

もう一つはやらなくなるループがあること。例えば、「作っても使わない」というのが多い。苦労して計画書を作るにも関わらず、自らも含めてほとんど計画書を使うことはない。実際にスケジュールがずれてもマイルストーンでつじつまを合わせればよいし、上司もそれ以外のタイミングではプロジェクトの状況を聞くくらいで、進捗として計画を使うことがない。それでも最初はルールがあるので形式的にも計画書を作っているのだが、顧客の都合ですぐにプロジェクトを立ち上げたいといった状況に遭遇するのを機に、計画を作るのをやめてしまった。

◆問題を解決するには

うまく一番目のような成功経験ができれば、二番目の問題は解決する。というか、実際に計画を使っていることが実感できる。しかし、成功経験がないと、二番目の問題を解決するのは冷房の例と同じくやっかいである。プロジェクトマネジメントを行うことへの価値が必要だ。

このためにはまず、価値観を明確にする必要がある。プロジェクトマネジメントを行うことが自社や自組織にとってどういう意味があるかを明確にし、それをやらないと何が起こるかを明確にする。

できれば、これを支持するストーリーなどがあるとよい。

その上で、７月９日のコラムで述べた定着化のサイクルの中で、「教育」と「奨励」の中で、価値観を実感できるような工夫をしていく。教育では、特にトラブルマネジメントの教育を価値観を埋め込んで行うことが効果的である。奨励では、価値観に沿った行動をとった人を誇らしい気持にさせるような報奨を与えるといった方法が考えられる。

【補助線】定着化サイクルの作り方

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

◆定着化サイクル

前回、プロジェクトマネジメントの普及においてマーケティングの発想が重要だと述べた。今回は、もう少し、話を進めて、どのようなマーケティング活動を行い、定着化サイクルを構築していくかを考えてみたい。

ＰＭＯによる定着化のサイクルはどこでもやっているように

　通知　→　教育　→　奨励

という３つのステップが基本になる。程度の差はあっても、これはどこの組織でもやっていることだろう。おそらく多くの方は、サイクルを見て、

　標準やツールの開発　→　通知　→　教育　→　奨励

という流れを思い浮かべられたのではないかと思う。

◆プロダクトアウトでは標準は定着化しない

前回も述べたが、手法や標準の展開をする際に、まず、作って、それを組織内のプロジェクトやあるいは機能組織に知らせていくというやり方はあまり適切とはいえない。製品でいえばプロダクトアウトというやり方である。これでは関心が高まらないばかりか、「また、勝手にやることを増やした」などということで反感を買うのが関の山である。

通知や教育は標準を開発する中で展開していく。つまり、

　通知　→　教育　→　奨励
　↑　　　　↑↓
　標準やツールの開発

という進め方をしていくことが必要である。これはマーケットインの発想である。

◆タウンミーティングで通知と教育を行う

もっとも重要なのは通知を行うタイミングと内容である。これは、開発をすることを決めた段階で第一報を行うことが望ましい。この段階で、なぜ、その開発アクティビティを行うのか、それがどのようにメリットをもたらすのかといったことを明確にしておく。

と同時に、その段階から教育を行う。ここにもうひとつのポイントがある。ここでいう教育は標準の使い方そのものではない。この段階では、その標準が入ったときにプロジェクトマネジメントがどのように変わって行くかを教えるような教育である。従って、長時間をかける必要はない。１時間でもいいので、プロジェクトマネジャーに集まってもらい、背景説明を行い、また、方向性について意見を求める。このためには「タウンミーティング」を開催するとよい。

日本では、タウンミーティングというと小泉内閣のときに開始されたが、やらせ問題や不適切な経費使用であまりよいイメージがないが、タウンミーティングは米国のニューイングランド地方で実施されている

各州によって形態は異なるが、概ね「町」単位で1年に1度開催され、住民の参加により予算、法律、その他自治体に関わる今後1年間の事項を採決する（Wikipedia）

という地方自治体の意思決定方式である。

◆自己決定の形を作ることがポイント

つまり、プロジェクトマネジメントに関する標準を策定することは組織ガバナンス上はＰＭＯの仕事であるが、その定着や効果を考えた場合には、特にプロジェクトマネジャーの「自己決定」の形を作ることが極めて大切である。

従って、もし社内にコミュニティがあればコミュニティを徹底的に利用することが重要であるし、なければタウンミーティングのような場を作る。これにより、通知と教育を行うと同時に、パイロット実施も含めて標準の評価をして、洗練させていく。このサイクルをまわしていかない限り、いくらツールを準備しても、いくらレギュレーション化をしても、その標準が有効に機能する ことはないだろう。

◆マーケットアウトを目指して

このような仕組みが定着してくれば、継続的改善の仕組み作りの可能性も見えてくる。継続的改善の仕組みを作るためのポイントはマーケットアウトの発想にある。これは次回。

◆マーケティング用語の説明
プロダクトアウト：自分たちが持っている技術などでできる商品をつくり、市場に出す
マーケットイン：市場の声を聞いて商品にして市場に出す
マーケットアウト：自分たちが顧客の立場で一般顧客が想像しない商品を考え、市場に出す

【補助線】プロジェクトマネジメントの定着化

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

◆問題を複雑に考えていないか？

仕事柄、多くのＰＭＯとお付き合いをしている。その中で常々感じているのが、プロジェクトマネジメントの導入という問題を複雑に考えすぎているのではないかということだ。

導入した手法や標準が使われないという問題と、マネジメントとして何をすればよいかという問題を混乱していため、どんどん深みにはまっているようなケースをよく見かける。

典型的パターンに

　手法を導入した
　　　→　なかなか実践されない
　　　　　→　原因を分析すると確かに一理ある
　　　　　　　→　では、その原因を解消する手を打とう

というパターンがある。例えば、

　見積もり標準を作った
　　　→　あまり使われていないようだ
　　　　　→　精度がイマイチだというのがプロマネの評判
　　　　　　　→　もっと精度の高い方法を取り入れよう、ツールも準備しよう

というような感じ。

◆確認すべきこと

このパターンは山ほどあるのだが、だいたい、この手の話を聞くと、プロマネに以下の２点を確認することにしている。

・標準を知っているか
・標準の使い方（内容）を知っているか、あるいはマニュアルの存在を知っているか

最初の方はだいたい、６０～７０％は知っているというケースが多い。ところが、後者の方はせいぜい３０％である。最近、ちょっとかかわりのあったある企業などは１０％に満たなかった。だから、いくら標準の質を上げたところで、使われないという状況が変わるはずがないのだ。

これはある種の思考の罠みたいなところがある。問題分析の仮定で、デリバブルズ（ＰＭＯとしての成果物、標準など）の品質にしか、関心が行っていない。標準の質がよければみんなが使ってくれるという仮定を持って展開している。だから、そのような問題解決思考に入ってしまうのだ。

◆仮定の間違い

これは明らかに仮定が間違っている。いくらよいものを作っても、その存在が知られない限り、その標準は使われることがないという自明の理を前提にしなくてはならない。

そうすると、「使われない」という問題の分析として上のような分析を真っ先に行うだろう。仮に、使い方を知っているにも関わらず使われなかったら、これはデリバブルズの問題である。あるいは、一度、使って二度と使わないというのも同じ。

速やかに改善しなくてはならない。しかし、知らなければ、まず、知らしめるために何をすればよいかを考えなくてはならない。次に、今のものを使わせるために何をしなくてはならないかを考えなくてはならない。当たり前の話である。問題は単純なのだ。

この単純な問題を、「知らない」という単純な事実を無視して、こねくり回して複雑にしている。こんなことが起っているのではないかと思う。ストレートにいえば、単純な問題を複雑にしている。

◆プロジェクトマネジメントの導入は難しくない

こんな言い方をすれば、投げやりに聞こえるかもしれないが、プロジェクトマネジメントの導入が難しいのは、マネジメント手法そのものが難しいからではないし、また、何をすればよいかが難しいからでもない。ほとんどのケースはそれ以前の問題で引っかかっている。「知られていない」という問題だ。この問題をプロジェクトマネジメント手法の問題に転嫁している点に最大の問題がある。

これをやっている限り、どんな手法を入れようと定着しない。これは、チェンジマネジメントの問題の中核である定着化の問題だ。

よいプロセスを作ればみんなが使う。みんなが使えば、よい製品ができる。よい製品ができれば顧客が買ってくれる。今、買ってくれない顧客も製品を改善すれば買ってくれるだろう。

こんなマーケッティングレスな発想から早く抜け出したいものだ。

【補助線】ＰＭＯモデル

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

◆プロジェクトマネジメントオフィスの３つのモデル

プロジェクトマネジメントオフィスの役割にはどういったものがあるのだろうか？この議論は２つの視点からする必要がある。ひとつは、プロジェクトマネジメントに対して、どのようなスタンスをとるかという議論である。もうひとつは、どのような機能を果たすかである。今回、したいのは前者に対する議論である。

プロジェクトマネジメントオフィスのプロジェクトに対する関わり方は一般に、ＰＭＯモデルと呼 ばれれ、２種類、あるいは３種類ある。

◆ストロングモデル

ひとつは、ストロングモデルと呼ばれる強い関わり方である。ストリングモデルでは、組織のプロジェクトマネジメントの実行そのものにＰＭＯがコミットする。場合によっては、プロジェクトが行うプロジェクトマネジメントにコミットする場合もある。

一般にはストロングモデルのＰＭＯは、標準化や機能の導入以外に、バーチャルチームの形成、計画書のレビューや、プロジェクト監査、リカバリーマネジメントなどの形で、プロジェクトの外部からプロジェクトマネジメントを支援していくことが多い。

また、いわゆるプロジェクトオフィス機能としてプロジェクトマネジャーの行うプロジェクトマネジメントの一部を引き受けるケースもある。例えば、プロジェクトマネジメント計画書の作成、上位組織への報告書の作成、会議体の運営、ファシリティの手配などを行う。また、プロジェクトマネジャーに代わって、メンバーの教育・指導などをすることもある。

◆コンサルティングモデル

これに対して、コンサルティングモデルと呼ばれるモデルはプロジェクトマネジメントに対してあくまでもコンサルティング的な立場で接していく。自発的に何かサービスを提供するということより、あくまでもプロジェクトや組織から相談があったときに出動し、相談された問題を解決していくというスタンスだ。支援内容的にはストロングモデルと重複する部分も多い。例えば、計画書のレビューをしたり、監査を行ったり、リカバリーを行う場合もあり、スタンスの違いだと考える方が分かりやすい。

ストロングモデルと異なるところは、自らが計画を作ったり、あるいはリカバリーに入ったり、あるいは、プロジェクトマネジメントをしたりということはない点である。

ＰＭＯの戦略の中でもっとも重要な部分はこのどちらのスタンスをとるかであり、これによって、ＰＭＯの性格も変わるし、必要なリソースも大きく変わってくる。

◆ブレンドモデル

ストロングモデルとコンサルティングモデルの折衷で、ブレンドモデルというスタンスの取り方もある。これは、例えば、プロジェクトトラッキングとリカバリーについてのみ、ストロングモデルを採用し、それ以外の部分ではコンサルティングモデルを採用するというようなものだ。

ＰＭＯとしては、もっとも力量が必要になるのが、ブレンドモデルであろう。

このようなスタンス（タイプ）分類でキーになっているのは、前回述べたプロジェクトマネジメントのオーナーシップである。ストロングモデルは基本的にはオーナーシップを持とうとするスタイルであり、コンサルティングモデルはオーナーシップを持たないスタイルである。どちらを選ぶかというのはプロジェクトマネジメントの成熟度によっても変わってくるし、また、企業の姿勢によっても変わってくるだろう。

プロジェクトマネジメントに人間的要素を強く求める企業はコンサルティングモデルを採用し、オーナーシップを重視しない傾向がある。プロセスや標準を重視する企業は、オーナーシップを重視し、ストロングモデルを採用する傾向がある。

特に、企業の姿勢の中で、押さえるポイントだけは押さえたというのがブレンドモデルということになる。日本企業では、ブレンドモデルが多いようである。

【補助線】ＣＰＭＯとプロジェクトマネジメントのオーナーシップ

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

◆はじめに

ゴールデンウィークで少し間があいたが、前回のコラムでは、ＰＭＯのマネジメントについて、最低限でも

（１）ＰＭＯ活動の成果の定義と測定
（２）ＰＭＯの戦略と役割の見直し
（３）ＰＭＯの機能の評価と見直し
（４）ＰＭＯスタッフのローテーションと育成

の４つは実施する必要があることを述べ、（１）のＰＭＯ活動の成果の定義と測定について説明した。今回から（２）について説明する。その前に、前回の記事について「ＰＭＯはひとつしかおかないのか？弊社では、プロジェクトの中にもあるし、事業部にもある。会社としてのＰＭＯもある」という質問を戴いたので、これに回答しておきたい。

◆ＰＭＯの種類

ＰＭＯといっているものにはいろいろなものがある。例えば、米国では以下のような分類が一般的である。

（１）CPMO（Corporate Project/Program Management Office）
　あとで説明する
（２）PMO（Project Management Office）
CPMOによって確立されたプロジェクトのマネジメントの標準の適用による効果を見ながら、事業部、BU、リージョンなどの範囲で、戦術的なマスタープランに対する責任を持つ
（３）PSO（Project Support Office）
CPMOによって確立されたプロジェクトマネジメントの標準の監視をし、オペレーショナルなマスタープランに対する責任を持つ
（４）PO（Project Office）
ミッションクリティカルなプロジェクト、大規模＆複雑なプロジェクトの直接的な支援を行う責任を持つ

これらは、ひとつの組織の中に共存する。

◆ＣＰＭＯの役割

この中で、注目すべきなのは、ＣＰＭＯである。日本でもエンタープライズＰＭＯとか、コーポレートＰＭＯといった位置づけのＰＭＯがある企業は少なくないが、ＣＰＭＯというのは

全社のビジネス機能の一つに位置づけられる。財務、マーケティング、営業、エンジニアリング、製造などと同様に、プロジェクトマネジメントに対するオーナーシップを持ち、プロジェクトのマネジメントのベストプラクティスを全社に展開することを目的とする組織

をいう。つまり、プロジェクトマネジメントというのは組織機能の一つである。メルマガの記事に何回か書いたように、最近、「正しいプロジェクトを正しく行う」ということに関心が高まってきている。しかし、実は、これだけでは不十分である。

「正しいプロジェクトを行う」ことと、「正しく行う」ことは組織の中では自動的には結びつかないことが多い。例えば、正しいプロジェクトを正しく行うためには、組織がプロジェクトをやる意味が十分にプロジェクトに伝わり、反映される必要がある。プロジェクトマネジメントにはプロジェクト憲章というツールがあるが、これだけでそのプロジェクトを実施する組織としての意味が十分に伝わるものではない。この部分は人間系（組織）の課題になる。

◆「正しいプロジェクトを正しく行う」ためにはＣＰＭＯが必要

つまり、「正しいプロジェクトを正しく行う」ためには、「正しいプロジェクトを行う」ことと、「正しく行う」ことをコンバインする必要があるのだ。これはシニアマネジャーの役割であるが、シニアマネジャーが個別にやるには横通しの問題からおのずと限界がある。

そこで、プロジェクトマネジメントのオーナーシップという話が出てくる。プロジェクトマネジメントのポリシーを明確に定め、そのポリシーに従って、シニアマネジャーがうまくプロジェクト選定とプロジェクトマネジメント実行を結びつけてやるのだ。このようなオーナーシップを持つためには、ＰＭＯを戦略組織とし、「ＣＰＯ（Cheif Project Management Officer）」とでもいう役職を設置する必要がある。

最後にひとつ、日本の企業のＣＰＭＯの特徴に触れておく。日本の企業では、ＣＰＭＯがプロジェクトマネジメントに対するオーナーシップをもてないケースが多い。ぜひ、考えてみて欲しい。仮に、あなたのＰＭＯが全社標準を作っているとすれば、以下の３点をチェックしてみて欲しい。

【簡易診断】

（１）全社のプロジェクトマネジメントポリシーを作っている
（２）標準の運用で、プロジェクトスケジュールを無視して、計画書の書き直しを命じることができる
（３）プロジェクトマネジャー以外の部門のプロジェクトマネジメントに対する責任を明確にしている

【補助線】ＰＭＯのマネジメント機能

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

◆ＰＭＯのマネジメント機能とは

前回のコラムでは、プロジェクトマネジメントの組織成熟度を上げていくにはＰＭＯというのは単にプロジェクトマネジメントの支援をするだけではだめだという指摘をした。今回はもう少し、この問題に踏み込んでみたい。

ＰＭＯというのも組織である。従って、マネジメントされなくては、望まれるパフォーマンスを出すことは難しい。ＰＭＯに組織のマネジメントとして求められることには、以下のようなものがある。最低限でも

（１）ＰＭＯ活動の成果の定義と測定
（２）ＰＭＯの戦略と役割の見直し
（３）ＰＭＯの機能の評価と見直し
（４）ＰＭＯスタッフのローテーションと育成

の４つについてはマネジメントとして実施される必要がある。少しずつ説明していこう。

◆ＰＭＯ活動の成果の定義と測定

ＰＭＯを設立する、あるいは、運営するに当たって最も頭を悩ますのがこの問題である。ＰＭＯ関係のセミナーを開催すると必ずといってよいくらい出てくる質問でもある。

このような問題が出てくる背景には、（２）と関係があるが、ＰＭＯを設立する際に、戦略がなく、それゆえに、役割が熟考されていないケースが多いことがあげられる。プロジェクトマネジメントを標準化するために作る、プロジェクトマネジメントがうまく行っていないので作る、メンタルケアがうまく行っていないので作るという風に、当面の問題解決でＰＭＯを作っているケースが少なくない。

成果の定義の基本的な考え方は２つある。ひとつはあくまでもＰＭＯは間接部門であり、直接部門、つまり、プロジェクトの成功の度合いによってＰＭＯの評価に変えるというものである。もうひとつは、ＰＭＯも完結した活動組織であり、ＰＭＯ活動そのものの成果を評価するという考え方である。

◆評価指標の例

前者の場合によく使われる指標は
　・プロジェクトの成功率（ＱＣＤＳの目標達成率）の改善
　・プロジェクトのトラブルによる損失額の減少
である。また、もう少し、大きく見ると
　・プロジェクトのＲＯＩの改善
といった指標で見ることもある。このような考え方はＰＭＯの活動はあくまでも支援活動であり、必要な支援を適切に、タイムリーに提供することにより、プロジェクトの成功確率、あるいはＰＯＩが上がるという考え方に基づいている。

これに対して後者のような捉え方をする際によく使われる指標は
　・標準ツールやテンプレートの利用プロジェクト数（率）
　・プロジェクトマネジメントノウハウやテンプレートの登録件数
　・成熟度アセスメント結果の向上
　・プロジェクトマネジャーの数や認定制度があればシニアＰＭの割合の増加
　・プロジェクトマネジメント教育の受講者数や、受講時間
　・プロジェクトマネジャーの平均コンピテンシー
　・計画レビューによる不適合計画率
　・メンタリング活用者数
などがある。また、これらの指標よりは少し、上のレベルの指標として、プロジェクト監査を行い、

　・監査結果における不適合指摘項目数

などを指標として評価することもある。

◆どちらが適切か

どちらがより適切な評価かという問題があるが、これについてはその組織のプロジェクトマネジメントの成熟度によると思われる。成熟度が低い組織では、プロジェクトの成功は偶発的なものであったり、プロジェクトマネジャーの属人的な能力に依存する場合が多い。言い換えると、プロジェクトを開始する時点でほとんど成功するという予測はつかない。このような組織においては、まずは、後者のような評価をすべきだろう。前者のようにプロジェクトの結果を評価してみても、それがＰＭＯの姿を的確に表現している評価だとは考えにくい。ＰＭＯの立上げの段階では、このような評価が望ましい。
逆にプロジェクトマネジメントが成熟してくれば、結果を問うべきである。ＰＭＯの仕事は、定義しにくいものがある。例えば、ステークホルダ間の調整を行い、プロジェクトマネジメントの円滑な運営を図るというような仕事は、機能としては定義しにくく、結局、ＰＭＯの総合的な活動だと考えることが自然である。すると、そのような活動によってステークホルダがどう変化したかということより、プロジェクトの成功に結びついたかという方が実態を適切に反映すると考えられるためである。

（２）以降については次回説明する。

【補助線】マーケッティングしよう！

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

◆ＰＭＯの機能はプロジェクト支援機能だけではない

ＰＭＯの機能というと

「社内標準やテンプレートを作ってプロジェクトマネジメントの支援をする」、「トラブルに陥ったプロジェクトをレスキューする」、「プロジェクトマネジメント計画書のレビューや計画策定の指導をする」

などさまざまなものがある。ただ、ＰＭＯがこれらの機能を実行しようとしてみても、なかなか、うまく行かないのが現実である。なぜだろうか？

今回のコラムは少し視点を変えてこの問題を考えてみたい。

◆使われるまでに必要なプロセス

ＰＭＯがどんな標準やツール、仕組みを作ろうと、それらは使われてはじめて意味がある。これは誰もが認めることだろう。そして、使われるためには、まず、

（１）知られること

が必要だ。そして、

（２）プロジェクトマネジャーが使おうという気になる

ことが必要である。

そして、使われるようになったときには

（３）使っているものがメンテナンスされ、活用がきちんとサポートされる

ことが不可欠である。

プロジェクトマネジメントの仕組みや道具をいろいろと作って入れてみたが、なぜか、プロジェクトマネジャーが使ってくれないという悩みを抱えるＰＭＯのほとんどは、（２）が抜けている。もちろん、存在すら知らないというケースは珍しいが、どのような場面で使えるか知らないとか、それを使うことによって何が期待できるか知らないとかいったケースは珍しくない。

◆使おうという気にならない

このようなことが起っている一因は皮肉なことにプロジェクトマネジメントブームである。ブームにのっかり、組織としてプロジェクトマネジメントの導入を決定した。このため、ＰＭＯの提供する支援に乗っかることが義務化されている会社が多い。

それで、形はできているのだが、いまひとつ、実態が伴わず、実りが少ないと悩む企業が多いのだ。これらの企業に共通している問題は（２）である。「ベテランのＰＭには自分のやり方がある」、「仕組みが重いので、忙しいＰＭにすべてやってもらうのは難しい部分がある」といった悩みを持っている企業が多い。

ここで問題なのは、ＰＭＯサイドの「いいもの、便利なものを作れば使ってくれる」という錯覚である。ちょっと脱線するが、皆さんの会社のビジネスを考えてみて欲しい。（開発者の考える）いいものを作ることから使ってもらうまでには、最低でも

・その存在を知ってもらう
・その価値を認めてもらう
・導入してもらう
・使い方を理解してもらう

という４つの壁がある。

プロジェクトマネジメントの支援を見ていると、意外にも価値を知ってもらう前で止まっているケースが多い。ここをクリアしても、導入してもらうまでに時間がかかっているケースが多い。

この２つがクリアできてはじめて、使い方を支援するという段階にたどり着く。ここは結構できている（というか、やとうしている）企業が多い。

◆マーケティングしよう！

これらはひと言でいうと、マーケティング活動である。日本ではＰＭＯの書籍そのものが少ないが、米国のＰＭＯの本を見ると、必ず、ＰＭＯの活動の中にマーケティング活動が入っている。

日本企業のＰＭＯの人と議論をすると、サービス（標準の内容とか、ツールとか）の議論に終始することが多い。これではおそらく、いくらプロジェクトマネジメントに関する知恵を絞っても今の状況が改善される期待は薄い。

実は、日本企業のＰＭＯがきちんとやっていない活動はマーケティングだけではない。そもそも、マネジメント活動というのがろくにできていない。これについては次回。

【補助線】プロジェクト監査のタイミングと内容

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

前回のコラムでは、プロジェクトモニタリングという観点から、プロジェクトマネジメント活動やプロジェクト支援活動を整理してみた。コラムでは、できるだけ手法に入らないようにしているが、読者の方からプロジェクト監査のイメージがよく分からないので、教えて欲しいというメールを戴いたので、イメージを説明するために、少しだけ、具体的な内容に踏み込んでみよう。

◆プロジェクト監査の種類

まず、一口にプロジェクト監査といっても、目的やタイミングに応じていくつかの種類に分かれる。もちろん、目的が違うのでタイミングが違うという見方も見ることもできる。

プロジェクト監査を大きく分けると、プロジェクトマネジメントやプロジェクトの監査を一義的とするものと、周辺状況からこれらに対する分析を加えるものの２種類がある。前者はプライマリー監査、後者はセカンダリー監査などといわれることがある。

プライマリー監査には

・プロジェクトマネジメント監査（プロジェクトの任意のマネジメントプロセス）
・プロジェクトパフォーマンス監査（実行・統制プロセス）
・プレプロジェクト監査（計画プロセス）
・ポストプロジェクト監査（終結プロセス）
・プロジェクトマネジメントメソドロジーレビュー

などがある。（）内が一般的な実施タイミングである。プロジェクトマネジメントレビューは特にこの時期というのはないが、マネジメント手法の評価は結果に依存する部分が大きいことを考えると、終結プロセスで行うのが妥当だろう。

◆プロジェクトマネジメント監査の実際

まず、最初にイメージを掴んでもらうために、プロジェクトマネジメント監査についてPMstyleの内容の一部を例示する。

プロジェクトマネジメント監査のレビューの対象としては、

１．プロジェクトマネジメントの効果を生み出せるプロジェクト作業計画と支援計画
２．プロジェクト作業計画と支援計画策定の有効性
３．プロジェクト資源管理と作業成果の監視
４．ベンダー管理と作業成果の監視
５．顧客に対する契約上の義務の実行

などを設定している。これに対して、監査視点を設定しておき、その視点から監査を実施するという方法をとっている。例えば、２．の「プロジェクト作業計画と支援計画策定の有効性」という対象であれば、

（１）適用可能な計画に従ってプロジェクト作業が完遂しているか
（２）作業計画に対してプロジェクト実績のトラッキングが示されているか
（３）作業計画の変化の見極めと対応がタイムリーに行われているか
（４）計画変更に当たっては承認された手続きが使われているか

といった監査視点が設定されている。

◆監査視点のボリューム

ちなみに、PMstyleでは、

・プロジェクトマネジメント監査（７対象２２視点）
・プロジェクトパフォーマンス監査（５対象１９視点）
・プレプロジェクト監査（６対象２５視点）
・ポストプロジェクト監査（３対象１２視点）
・プロジェクトマネジメントメソドロジーレビュー（３対象１１視点）

が設定されている。

◆セカンダリー監査の種類

これ以外にセカンダリー監査がある。セカンダリー監査としてPMstyleが行っているものには

・顧客満足度監査
顧客が望む目的がどの程度達成されているかをレビューすることにより、顧客とのビジネスリレーションシップを検査

・プロジェクトリカバリー監査
プロジェクトマネジメント監査とプロジェクトパフォーマンス監査であるが、不適合度に監査焦点を置いた検査を行う

・プロジェクト支援計画監査
個々のプロジェクトに対して、事前に策定されたプロジェクト支援計画をレビューする

・プロジェクトリソース活用監査
リソース配置の充足度を、特定のタスクに対する配置実行のタイムリーさの観点を中心に検査する

・プロジェクトチームパフォーマンス監査
プロジェクトチームメンバーに対して、プロジェクト作業の担当と、技術的能力、専門能力の整合をレビューする

・ベンダー監査
ベンダーやコントラクターが適正なプロジェクトマネジメントを行っているかをレビューする。検査は、プロジェクトにおけるプロジェクトマネジメント監査と同じ視点で行う。

などがある。これらはいずれも、必要に応じて、ＰＭＯが中心になって行うことが現実的であるが、プロジェクト支援計画監査については、ＰＭＯ自身の問題になるのでＰＭＯが指揮をして、第３者の監査人を立てて行う方がよいだろう。

【補助線】プロジェクトのモニタリングについて考える

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

プロジェクトのモニタリングというのは単純明快なようで、結構、深い話である。

◆進捗報告

モニタリング活動の種類でみれば、３種類ある。

もっとも単純明快なのは、スケジュール、コスト、品質、リソースなど、ベースラインの設定（定量化）ができるもので、これに対しては進捗というモニタリング指標がある。進捗に対するモニタリングは、通常、進捗報告として、ボトムアップ式に行われる（ただし、これにしても、ＥＶに代表される計測方法などの課題があるので、単純明快とはいえないかもしれない）。

これらは目標に対するプロジェクトの状態を評価であり、コアプロセスとして行われるマネジメントである。

これに対して、目標に対する状態のモニタリングではなく、マネジメントの状態を知りたいという目的のモニタリングがある。ＰＭＢＯＫでいえば、マネジメント計画に対する実行状況を知りたいという場合だ。

◆トラッキング

ひとつの例として、進捗に大きな影響を与えるリソースパフォーマンスを考えてみよう。プロジェクト作業計画を作る際に、ある生産性を基準にして作った。すると、この生産性を引き出すことがマネジメントの重要課題になるし、その方策はマネジメント計画書においてきちんと計画されている必要がある。

ところが、こちらはベースライン（プロジェクト目標）のような形で定量的にモニタリングしていくことは相当難しい。例えば、残業時間のような間接的に推定する指標を持ちこんで定量化することができないわけではないが、最終的には値を解釈して評価すべきものであり、その意味で、本質的に現象を直接観察して、モニタリングすべき性格のものだ。

このように現象を直接観察するタイプのモニタリングはトラッキングと呼ばれる。トラッキングには、チームのパフォーマンス、主要なコミュニケーション、課題管理などが上げられる。

トラッキングの中で多少、特殊な位置づけにあるのが、リスクである。リスクマネジメントではリスク事象をトラッキングする。これは計画通りに言っているかどうかをトラッキングしているわけではないが、プロジェクトで発生する事象をモニタリングしているという意味ではトラッキングである。

◆監査

このようなトラッキングに対して、トラッキング自体が難しい、あるいは、個別事象をトラッキングしているとマネジメントコストが爆発的にかかるようなものがある。

例えば、コミュニケーション計画の中で、プロジェクトメンバーは毎日、当日の作業を正確にＰＭＳにインプットすると決めたとしよう。インプットしているかどうかは把握できるが、正しく入力されているかどうかはほとんどフォローできないだろう。トラッキングできなくはないが、凄いボリュームになるだろう。

あるいは、些細であっても問題が発生した場合には、関係者を集めてミーティングを行うという計画を作ったとする。この計画が計画通りに行われているかどうかをモニタリングするのは非常に難しい。

このような場合には監査というモニタリング方法をとる。

監査は個別の事象に注目するのではなく、視点を変えて、大局的に、全体的な傾向や、計画通りに行われた場合あるべき結果、インシデントなどに注目して、情報収集し、分析することによって状態が計画通りに行われているかどうかを判断する方法である。ある意味でサンプリング検査のようなものである。

【補助線】ガバナンスマネジメントは大丈夫？

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

◆ＰＭＩのガバナンスフレームワーク

ＰＭＩの示した組織ガバナンスのフレームワークでは、上位に戦略的計画があり、それを支える形で

・業務のマネジメント
・プロジェクトによるマネジメント

の２つが位置づけられている。そして、さらに、プロジェクトによるマネジメントの中は、

・ポーフォリオマネジメント
・プログラムマネジメント
・プロジェクトマネジメント
・プロセスツールメトリクス

から構成される構造になっている。つまり、組織のガバナンスは業務管理だけではなく、プロジェクトによるマネジメントによっても実現されている。その割合は組織によって異なるが、ＳＩ企業などの中には、組織ガバナンスのほぼ１００％近くをプロジェクトによるマネジメントにゆだねている組織もある。

◆内部統制とプロジェクトマネジメント

一方で、今、ガバナンスが大きな問題になろうとしている。内部統制が法的に規制される時代がやってきている。大半の注目はなぜか業務マネジメントに向いているが、実際には現在ではプロジェクト型の業務運営がない企業は皆無に近い。その意味で、コーポレートガバナンスをきちんと統制していくには、プロジェクトによるマネジメントを行っている業務のガバナンスのマネジメントが大きなポイントになる。

プロジェクト型業務のガバナンスとしては、業務マネジメントのルールをそのまま適用しているケースが多い。例えば、プロジェクトの予算内でも、プロジェクトからの支出の決済は通常の業務と同じく金額に応じて相応な職責のもの（プロジェクトの統括組織のラインマネジャー）が管理するという方法だ。

このような方法は一見、合理性があるように見えるが、実態としてはプロジェクトガバナンスの混乱の一因になっていることが多い。このような制度の運営の実態としてはいくつかのパターンがある。代表的には、

（１）ラインマネジャーは形式的に決済をする（プロジェクトに意思決定を委譲する）
（２）ラインマネジャーが内容に立ち入った判断をする（プロジェクトマネジャーの決定をラインマネジャーがひっくり返す）

の２つを上げることができる。

◆プロジェクトガバナンスと組織ガバナンスを両立させるには

前者の場合、プロジェクトガバナンスの所在は明確になるが、組織ガバナンスの混乱を招く。また、プロジェクトマネジメントの立場から不要な仕組みだといえる。後者の場合、組織ガバナンスの強化の立場からは望ましいが、プロジェクトガバナンスの所在が非常にあいまいになる。特に、お金と時間は相関性の強いものだが、お金に関するガバナンスを組織側に残して、時間やその他のマネジメントイシューのガバナンスをプロジェクトに委譲するというのはある意味でナンセンスであり、プロジェクトマネジメントをやりにくくする一因となる。

このように考えていくと、今のプロジェクトガバナンスは決してきれいにマネジメントされているものではない。もともと、プロジェクトは組織的にはマトリクス組織であり、リソースに関するコンフリクトはある意味で宿命である。しかし、このことと、ガバナンスの所在を明確にすることは別の次元の問題である。リソースに関するコンフリクトがあったとしても、ガバナンスは明確にプロジェクト側に渡されるべきであり、それがプロジェクトマネジメント成功の第一歩である。

一方でプロジェクトマネジメントはガバナンスを渡された限り、プロジェクトの内部と透明化し、組織の統制ニーズに応えていく義務がある。これがアカウンタビリティである。プロジェクトガバナンスマネジメントとアカウンタビリティの確保の２つが揃って初めてこれからのプロジェクトマネジメントのあるべき姿である。

これらを実現していくことこそ、プロジェクトマネジメントオフィスの最大のミッションだといえよう。