コンセプチュアル・マネジメント

プロジェクト（マネジメント）の議論をするときに、スコープを仕様というニュアンスで使っている人が多いが、ご存知の通り、これは正しくない。スコープというのは成果物と役務の相対を指す言葉だ。ＰＭＢＯＫではこれをさらに明確にし、

●プロジェクトスコープ：規定された特性や機能を持つプロダクト、サービス、所産等を生み出すために実行しなくてはならない作業

●プロダクトスコープ：プロダクト、サービス、所産に特有の機能や特性

と区別して使えと書いている。

ここまではいいと思うが、では、スコープマネジメントというのは何をすることなのか？問題はこちらだ。仕様管理、構成管理、変更管理だと思っている人が多い。これが冒頭の話。

実は、ＷＢＳがうまくかけない悩みを持つＰＭは極めて多いが、ＷＢＳは両方のスコープを統合するツールであるので、このスコープマネジメントの認識がないとまず、上手に作れない。

実際には、ここに工法（仕事の進め方）が絡む。建築プロジェクトを考えてみると分かりやすいが、ある仕様の建築物を作ろうとすれば、必ず、工法を決める必要がある。これがプロダクトスコープとプロジェクトスコープである。プロジェクトスコープとプロダクトスコープは１対１の場合も少なくない。

逆にソフトウエアなどでは自由度が高く、プロダクトスコープは厳密に管理する必要があるが、プロジェクトスコープはあまり真剣に考えない。プロジェクト見積の中でも、プロダクトスコープをベースにして見積もり、それにプロジェクトスコープの配慮を入れるというのが普通である。

実際にはプロダクトスコープとプロジェクトスコープはもっと微妙な関連にある。プロジェクトの目的を達成するためにプロダクトスコープだけを調整するのではなく、プロジェクトスコープを調整することを考える必要もある。つまり、工法の工夫だ（要員数の調整もこの中に含まれる）。

このマネジメントを一口でいえば、プロジェクトスコープで調整するか、プロダクトスコープで調整するかを工夫することより、プロセスをシンプルにし、それによって生産性を上げること。

プロジェクトスコープとプロダクトスコープの両方をマネジメントする方法を説明することは非常に難しいが、よい本を見つけた。経営工学の大家で、良い仕事をされている慶応大学の中村善太郎先生のご本だ。

この本は、仕事を「もの」と「こと」に分けて、整理し、調整することにより、プロセスがシンプルになり、生産性が上がることを書かれた本。

先生の言われている「もの・こと」分析は、例えば

　「素材」を「製品」に変える「こと」

　はじめの「もの」をおわりの「もの」に変える「こと」

として捉え、この変換過程を、「もの・こと」図として書くことによって、スコープがきれいに整理でき、仕事の最適なプロセスを見つけるという発想。これは非常に分かりやすい。

この問題、結構、重要なのに考えられていない。

計画することをデスクワークだと考えているプロジェクトはだいたい失敗する。

　計画をするとは段取りをすること

である。つまり、計画の対象になる作業を実施する準備をすることである。

こんな例を考えてみて欲しい。

システムの受注開発をする。「計画書」に顧客から仕様が出てくると書く。その計画に基づいて、顧客にそのように対応してもらえるようにお願いをする。当然、顧客には顧客の都合があるので、素直にはウンを言わないが、そこを何とかしながら計画を実行していく。これをステークホルダマネジメントだという。ステークホルダマネジメントの甲斐なく、顧客からはお願いした通りのアウトプットは出てこない。結果として、スケジュールが遅れる。

このような状況はよくあるだろう。どこに、問題があるのだろうか？おそらく、多くの人はステークホルダマネジメントの問題をいうのだと思う。

しかし、このトラブルの本当の問題は、「計画ができていない」ところにある。計画を作るというのは、計画書に書くことのすべてについて、裏づけを取るという作業である。

どうもリスクマネジメントを導入するようになって、裏づけを取らずに、書いたことが実行できないのはリスクだと扱いたがる傾向がある。これはトンでもない間違いだ。

例えば、上の例で、顧客との間で、顧客側の具体的なスケジュールも含めて、合意をし、その通りにやってくれるという確約を取る。これは計画作業に他ならない。段取りだといってもよい。それでも、顧客の方に不測の事態が発生し、できないかもしれない。これがリスクだ。

確かに、ステークホルダマネジメントだとか、コミュニケーションマネジメントだとかが必要だというのはその通りなのだが、本当に必要なのは、計画の実行の中ではなく、計画を作るところである。

このような考え方で、pmstyle のプロジェクトマネジメント（ＰＭＢＯＫ準拠）はコミュニケーション計画を立ち上げプロセス群の中で、ステークホルダ分析を行うと同時に策定すべきだとしている。

これがプロアクティブなプロジェクトマネジメントである。

コミュニケーションに関心を持ち、コミュニケーションをトレーニングしようと考える人は多い。自分の失敗を振り返ってみると、そこにコミュニケーションの失敗があるというのがその理由だと思う。

左の図を見てほしい。ある組織で行ったトラブルの分析結果である（クリックすれば大きくなります）。過去のプロジェクトに対して、プロジェクトで発生したトラブルを大きいほうから３つ抽出し、その主要原因を２つまで上げていき、結果をＰＭＢＯＫの知識領域とプロセスのマトリクスを作り、分析したものだ（原因はほとんど２つ上がった）。

見て戴ければ分かるとおり、コミュニケーションが圧倒的に多い。

理由は、表面上は他のトラブルなのだが、分析するとコミュニケーションの問題もあるというケースが圧倒的に多かったためだ。

「犯罪の影に女あり」と同じくらい、「問題の影にコミュニケーションあり」は確率が高い。

ここでいうコミュニケーションって何かという問題。例えば、「口べたで相手にうまく自分の考えを伝えることができない。それゆえに問題になった」。こんなケースは、そうそうあるものではない。

コミュニケーションというのは車の運転と同じ。下手な人が、下手な人とであったときに初めて問題が生じる。それが顧客とベンダーという立場であったにしろ、丸く収まるのがコミュニケーションである。

昔に較べてコミュニケーションが問題になるというのは確かにスキルが低い人間が増えているということは間違いない。したがって、交通事故の可能性も高くなる。

じゃあ、みんなで車の運転を上手になりましょうという方向にいくかというと、そうは行かない。車の運転なんか個人の資質の問題があって、どんなに練習しても下手な人は下手だ。

では、どうするか？交通ルールを作るのだ。車線、信号、標識などなど。作っても、無視する輩がいるという問題はあるものの、ない状態に較べると、ずいぶん、まし。

でも、交通ルールだけでは解消できないような微妙な状況もある。例えば、山道を下っている。対向車が上ってきた。さて、問題。どちらが道を譲るか。道路交通法では規則はないが、上り優先という規範を作り、警察とか安全協会がそれをドライバーコミュニティで常識化している。

ここでさらに問題。そのときに谷側が崩れ落ちそうとか、あるいは、山側から落石がありそうだったらどうするか？これにしても、実際に警察が配っている教則には

「片側が転落のおそれがある崖になっている道路で、安全な行き違いができないときは、崖の側の車は一時停止して道をゆずりましょう。」

「山道では、路肩がくずれやすくなっていることがあります。このような場合の行き違いでは、路肩に寄り過ぎないよう注意しましょう」

と書いてあるらしい。これも規範なのだが、「上り優先」という規範とはずいぶん質が違うことが分かる。ドライバーの判断力が試される。つまり、ここでスキルが必要になるのだが、逆にいえば、ここまでは規範を決めることによってカバーできるという言い方もできる。

今のプロジェクトコミュニケーションを見ていると、スキルにばかり目が言っているが、規範はせいぜい、会議体だけである。これは交通ルールでいえば、道路交通法だけを決めているレベルだ。山道では上り優先というレベルの規範は決めていないし、さらに、その上のレベルの規範はまったく決めていないケースがほとんどだ。

なぜそんな状態となっているかいうと、規範も含めてコミュニケーションスキルだと考えていて、マネジメントとスキルの区別がついていないからだ。これは、みんなＦ１ドライバーになって行動を走ろうといっているに等しい。ありえない。

ルール・規範として決めるべきことは決める。そして、その規範を守る風土を作る。その上で、まだ、コミュニケーションの問題が発生するようなら、スキルベースを上げる。

そんなシステマティックな取り組みが必要なのではないかと思う。これがコミュニケーションマネジメントだし、そこまでできて、初めてコミュニケーションがマネジメントの基盤になる。

コミュニケーションが問題だ、重要だといっている人にこの議論を吹っかけると、１０人中９人まではそこまでしなくてもという。複雑性、新規性の高いプロジェクトで成功するのは、１人である。

あまり、普段書かないことが、プロジェクト計画を作ること自体があまりにも無計画に行われているように思う。

プロジェクト計画書を作るというと何か書き物でもするイメージだが、実行可能な計画を作るためには、多くのアクティビティが絡む。少なくとも、計画書に書いてある内容は、稟議とかいったレベルではなくて、関係者が合意をしていなくては計画とはいえない。

関係者はメンバーに限らない。顧客もいれば、途中で作業的なかかわりが出てくるステークホルダなどである。

おそらく、このアクティビティはマイルストーンだけでコントロールしていくようなボリュームではないだろう。

計画を作って進めていく必要がある。少なくとも、コミュニケーション計画を作り、打ち合わせをしていくことは不可欠である。そのようなメタなマネジメントが必要ではないか？それがない限り、おそらく、計画に取れる時間は変わらず、相変わらず、間に合わせで作った計画に振り回されるプロジェクト運営は続くだろう。

コンサルタント「プロジェクトマネジャーにどのくらい権限を与えていますか」

部長「プロジェクト実行に関するすべての権限を与えています」

コンサルタント「すべてとは？」

部長「決済された予算の使い方、マイルストーンを実現するスケジュールの組み立て、調達の仕方などです」

コンサルタント「責任は？」

部長「もちろん、全責任はプロジェクトマネジャーにあります」

コンサルタント「何の全責任ですか」

部長「予算内で納期に間に合うように求めている成果物を作ることです」

コンサルタント「プロジェクトに対する部長の責任はなんですか」

部長「プロジェクトマネジャーを指導することです」

コンサルタント「部長がプロジェクトマネジャーの立場なら、その権限でその責任を果たせると思えますか」

部長「果たせる思えるとすれば、組織の意味がないじゃないですか。それはプロジェクトでもないと理解しています。果たせないと思えることをなんとかして果たすから組織なんです」

Fin

◆プロジェクトマネジメントにおけるコンプライアンス

米国のプロジェクトマネジメントの本を読んでいると「コンプライアンス」という言葉がよく出てくる（ちなみに、ＰＭＢＯＫにはコンプライアンスという概念は今のところない）。

この言葉は、一般的な用語としては法令遵守などの企業倫理という意味で使われるが、プロジェクトマネジメントの中では多少異なるニュアンスでも使われる（もちろん、企業倫理という意味でも使われるが）。

異なるニュアンスとは、「標準」などの組織内のプロジェクトマネジメントに関するルール遵守という意味で使われる。

◆監査

少し話が飛ぶが、コンプライアンスの基盤になるのは「監査」活動である。会計監査、システム監査、環境監査、技術監査、システム監査、セキュリティ監査、品質監査、プロジェクト監査など、いろいろなものに対して適用される活動である。

監査論の定番書である八田先生の

　「監査論を学ぶ」
　　http://www.amazon.co.jp/exec/obidos/ASIN/4495169734/opc-22/ref=nosim

によると監査は

=====
監査とは経済活動と経済事象についての主張と確立された基準との合致の程度を確かめるために、これらの主張に関する証拠を客観的に収集・評価するとともに、その結果を利害関係をもつ利用者に伝達する体系的な過程である
=====

と定義されている。監査というと会計というイメージがあるが、経済活動、経済事象の捉え方によっては、ビジネスの活動はすべて監査の対象になるといってもよい。

では、どうして監査が必要になるのだろうか？

これにはいくつかのポイントが言われているが、最も基本であり重要なものが

　「利害の対立」

である。

例えば、企業と株主の場合、情報（決算書）をめぐって利害の対立が発生する可能性がある。利益が多くなれば配当を多くせざるを得ないからだ（もちろん、これを対立にするかどうかはマネジメントの問題だが、本質的な対立要素を含んでいる）。そこで、発信側としては、できるだけ利益を少なく発信したい。粉飾決算といった一線を踏み越える組織も出てくる。

このように、情報の発信者（この場合企業）と受信者（この場合株主）の間に情報をめぐる利害の対立の可能性がある場合には、「第三者」が入って監査を実施し、その情報が適切なものかどうかを明らかにされる必要がある。これが監査の必要性であり、組織として発信する情報の健全性を確保することがコンプライアンスだといってよい。

◆プロジェクト監査とは

さて、このような基本的な枠組みを理解した上で、プロジェクトにおける監査というものについて考えてみたい。まず、この監査の枠組みになぞらえると、プロジェクトの場合は誰が情報発信者で、誰が情報受信者なのか。

　情報発信者＝プロジェクト（プロジェクトマネジャー）

は分かりやすい。問題は情報受信者である。情報受信者として真っ先に出てくるのは

　情報受信者＝プロジェクトの成果物を受け取る顧客（社内外）

ということになると思われる。また、エグゼクティブも情報受信者になるだろう。微妙なのは、上位組織のマネジャー（ラインでプロジェクトを行うならラインマネジャー）である。上位組織のマネジャーは多くの場合、プロジェクトスポンサーになることが多い。

　ラインマネジャーはプロジェクトスポンサー
　　http://pmos.jp/pmstyle/pmcoe/pmcoe4.html

従って、プロジェクトチームに片足突っ込んだ存在であるし、スポンサーとしてプロジェクトに対して何らかの統制を行うことも可能である。しかし、実際にはここが情報受信者になっているケースが多い。これはプロジェクトマネジメントの問題点の一つである。これについてはまた、いずれ触れる。

◆監査がプロジェクトマネジメントを成功させる

そのような環境の中で、プロジェクト監査は、プロジェクトマネジメントの状況を第三者的に分析する。その視点はいくつかある。

まず、最初は冒頭に述べたコンプライアンスの視点である。つまり、組織の標準として定められたとおりの手順、基準、ルール、ツールに従って計画が作られているか、進捗が報告されているかといった点である。また、マネジメント判断の中で、メトリクスが遵守されているかどうかも問題になる。ここを担保しなくては監査活動は成立しない。

その上で、プロジェクトマネジメント成果物（計画や進捗ドキュメント）が公正なものであるかどうかである。つまり、進捗報告が規則どおりに行われ、かつ、内容に虚偽がないかどうかをチェックする。

ここが担保されないとプロジェクトマネジメントはできない。プロジェクトの「前提条件」の一つは、プロジェクト作業の担当者が「正しく」にプロジェクトマネジャーに状況を報告し、また、プロジェクトマネジャーが「正しく」に上位マネジャーにプロジェクトの状況を報告することである。この前提条件も監査では分析視点になる。

これで、形式的な健全性は保証されたことになる。この先は標準化がどれだけ進んでいるかによって変わる。標準化の究極の姿は標準手法、ツール、ルール、メトリクスなどに準じて進めていれば健全性が保証されることである。品質など、特定に分野においてはこの形は実現されつつある。

しかし、マネジメント全般になると少し、難しい部分がある。そこで、ある程度、マネジメントの内容に踏み込んだ視点からプロジェクトマネジメントの健全性のチェックが行われるようになる。

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

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

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

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

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

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

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

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

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

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

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

◆リスクの扱い

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

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

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

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

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

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

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

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

　・目標とする収益率

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

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

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

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

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

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

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

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

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

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

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

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

◆リスクの扱い

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

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

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

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

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

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

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

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

　・目標とする収益率

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

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

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

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