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

【補助線】プロジェクトのインテグリティ

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

◆リーダーの人間力

最近、人のインテグリティについて体系かつ、分析的に述べれた名著、ヘンリー・クラウドの「Integrity」の翻訳が出た。ビジネス書の杜にも紹介記事を書いたが、プロジェクトに関わるすべての人にとって、とても大切なことが書いてある本なので、ぜひ、一読をお奨めする。

リーダーの人間力
http://people.weblogs.jp/books/2010/02/integrity.html

さて、この記事で書こうとすることは、人のインテグリティの話ではない。人に人間性というインテグリティが必要であるように、プロジェクトにもインテグリティが必要である。プロジェクトをインテグリティという目で見ていると、インテグリティのないプロジェクトは「大きな失敗」をすることも多いし、失敗しないまでも大きな成果は得られにくい。

ヘンリー・クラウドの本の解説を借りながら、プロジェクトのインテグリティについて考えてみたい。

ＰＭサプリ２００：管理メカニズムと哲学を混乱してはならない（フルバージョン）

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

管理のメカニズムを、本質や哲学と混乱してはいけない（フレデリック・テイラー）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆テイラーの科学的管理法

ＰＭサプリもおかげさまで、今回で２００話になる。２００話ということで、少し、重みのある言葉を探して、見つけたのがこれだ。フレデリック・テイラーが１９１１年に著した「科学的管理法」からのフレーズである。

現代では、科学的管理法の評判は決してよいものではない。もっとも批判されているところは、人間を機械として扱っているという点だ。テイラーは科学的管理法の父と呼ばれるが、マネジメントの父と呼ばれるピーター・ドラッカーは著書「マネジメント」の中でテイラーを以下のように称している。

テイラーは、労働の生産性を押し上げ、それによって労働者たちにまずまずの暮らしをさせたいと願ったわけだ

管理のメカニズムの本質とは労働の生産性の向上であり、労働によって得られる対価
を引き上げることであった。日単位の出来高払いの仕事の中で、労働者はテイラーの
科学的管理法の指導を受けて作業方法を変えることによって、生産性を向上すること
ができ、それによって従来よりははるかに多い報酬を手にすることができた。

【補助線】プロジェクトマネジメントエグゼクティブ

◆プロジェクトマネジメントエグゼクティブとは

企業（組織マネジメント）には、エグゼクティブと呼ばれる人たちがいる。

エグゼクティブとは、組織運営に関して、「重要かつ決定的な意思決定を行っている人たち」で、一般的には上級管理職、経営幹部、重役などを指す言葉である。

これと同じようにプロジェクト（プロジェクトマネジメント）にもエグゼクティブと呼ばれる役割の人がいる。

プロジェクトマネジメントエグゼクティブの役割は

「プロジェクト運営に関する重要かつ決定的な意思決定を行っている人たち」

である。これは一体誰だろうか？

プロジェクトマネジャー？
プロジェクトマネジメントオフィス？
上位管理者？

【補助線】プロジェクトにおける例外管理

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

◆例外管理は基本中の基本

当たり前すぎて、今ではあまり語られることのなくなってきたマネジメントの原則に「例外管理（Manegement By Exception）」という原則がある。

金井 壽宏、岸良 裕司「過剰管理の処方箋 自然にみんながやる気!になる」、かんき出版（2009）

では、

=====
組織には、それまでの経験から、マニュアルや標準業務手順などの形で知識が蓄積されている。管理者はそれをうまく活用して人を動かす。マニュアルは曖昧さがないほど望ましいとされ、それを管理者は部下に渡しておく。「あとは任せた」でいければ、うまくいっている証拠で、管理者は介入しない。うまくいかないとき、つまり、マニュアルに書いていない例外的事象が起きたときだけは、管理者は「俺の指示を聞け」という。
=====

と説明されている。この本では、さらに、最近では例外が多すぎたり、また、例外に対して、経験が常に役立つとは限らない時代になってきたので、例外管理という考え方は現実的ではなくなり、経営学の教科書にすら、あまり出てこなくなった、でも、イロハのイとして、意識しておくべきことだと指摘されている。

【補助線】プロジェクトの数字は生きているか？

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

◆生きた数字と形骸化した数字

あるビジネス書を読んでいたら、「生きた数字」という表現が出てきて、はっとした。

内閣府が１７日に２００９年４―６月期国民所得統計を発表した実質国内総生産（ＧＤＰ）は前期比プラス０．９％、年率換算プラス３．７％である。この数字を見て、景気は回復したんだと思う人は少ないのではないかと思う。

なぜだろうか？おそらく、リーマンショックからこの１年、毎日のように景気対策、景気対策と繰り返し報道され、４回も予算を組んでいる。

国の補正予算というのは、企業でいえばリストラと同じ位置づけである。普通、リストラというのは一度やって、短期間に二度目のリストラをやるときには経営指標がいくら上向いていても、その企業は危ないと思われても仕方ない。

そんなことを連想させる景気対策があり、いくら、ＧＤＰが上がっても、その数字を額面通りに受け取れない。形骸化とまではいわないが、生きている数字だとは思えない。この数字を生かすためには、この数字の背後にある情報が必要である。

【補助線】支援プロジェクトは顧客

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

◆前回の復習

前回は、プロジェクトマネジメントに対して適切な支援をしようと思えば、プロジェクトマネジャーの価値観を理解し、その価値観を考慮した支援が必要であるという話をした。

プロジェクトマネジャーの理解
http://people.weblogs.jp/ppf/2007/12/post-ce7f.html

◆支援「してあげる」？！

この意見に対して、「そもそも、支援するのに、なぜ、プロジェクトマネジャーに媚を売るようなことを考えなくてはならないのか」という意見を頂いた。この議論は、ＰＭＯの在り方の本質的な議論だと思う。トップダウンでＰＭＯを作った組織は、確かに、ＰＭＯにそれなりの権限を与えていることが多いし、この方の言われるように、「そもそも」支援をしてあげているのにという考え方もあると思う。

しかし、この考え方は、一昔前の官が民間企業を支援するときの発想である（実は意見をくれた人は準公務員である；笑）。何が言いたいかというと、支援する側に成果がいらなければそのとおりだということ。実は民間企業でも僕がいた頃には業務支援部門はこういう発想だった様に思う。変わってきたのは成果主義になってきて、業務支援にも成果が求められるようになってきたためだ。

成果を上げるためにはどうすればよいかを考えることを求められる。自分の業務がどのように事業や企業経営の業績に結び付くことが一人ひとりに求められるようになってきた。

◆支援先は顧客である

違う言い方をすれば、支援部門も支援先を顧客だと考えないとつじつまが合わなくなってきているのだ。プロジェクトマネジメントでいえば、プロジェクトマネジャーは明確な成果責任を負っているのだから、それに役に立たない支援など受けたくもないし、実際に断る人も少なくない。これに対して、無理強いをするのは、役に立たない商品を売りつけているのと同じだ。役に立つ商品を売ろうとすれば、相手を理解しなくてはならないというのが前回の議論の前提である。

一言でいえば、ＰＭＯは提供するサービスがプロジェクトマネジャーに受け入れられて、それでプロジェクトマネジャーからの支持を受けることによってはじめて前々回に議論した互恵関係が成立する。そのやり取りの手段がカレンーなのだ。

脱線ついでにもうひとつ脱線するが、ＰＭＯの評価で悩んでいる組織は多いが、基本はこれだと思う。要するにプロジェクトマネジャーから支持されないＰＭＯは必要ないという単純な話だ。

◆ＰＭＯのジレンマ

こういうと、現実のニーズは、リカバリー支援とか、マネジメント作業労働力の提供とかに偏ってしまうという人がいる。これが現実であることは認めるが、なぜ、そうなるのかというと、プロジェクトマネジメントのやり方に問題があるからであり、それに対して責任を持つべきなのはＰＭＯに他ならない。

決めたことをやってくれないという悩みを持つＰＭＯも少なくない。これは、やらないからプロジェクトがうまくいかない、ゆえに、ＰＭＯの決めたことは非現実的で、だからやらないという悪循環になっていくパターンだ。

これに対する楔は一つしかない。プロジェクトを成功させることのできる手法なり、標準を提案していくことだ。ただし、どんな優れた手法であっても適用効果を出すためにはプロジェクトマネジャーの協力が不可欠である。したがって、ＰＭＯはすぐれた手法という楔を準備する一方で、互恵関係を構築していかなくてはならない。そのためには、真剣にカレンーを考えることが必要だ。

◆カレンシーの種類

さて、「影響力の法則」という書籍で自らの方法をモデル化しているコーエン＆ブラッドフォードによると、カレンシーには、５つの種類があるという。

（１）気持ちの高揚や意欲を喚起するもの
（２）仕事そのものに役立つもの
（３）立場に関するもの
（４）人間関係に関するもの
（５）個人的なもの

の５つだ。コーエン＆ブラッドフォードは、一般的な例として、それぞれに対して、

（１）気持ちの高揚や意欲を喚起するもの
　　ビジョン、卓越性、道徳的／倫理的な正しさ
（２）仕事そのものに役立つもの
　　新しいリソース、チャレンジ（成長）の手伝い、組織的な支援、素早い対応、情報
（３）立場に関するもの
　　承認、ビジビリティ、評判、所属意識／重要性、接点
（４）人間関係に関するもの
　　理解、受容／一体感、私的な支援
（５）個人的なもの
　　感謝、当事者意識／参画意識、自己意識、安楽さ

といったカレンシーがあるとしている。これはプロジェクトマネジャーがメンバーに対して提供するカレンシーとしてはそのまま使えると思うが、ＰＭＯがプロジェクトマネジャーとの互恵関係を構築したい場合にはどのように考えればよいだろうか？

この話は次回。

【補助線】プロジェクトマネジャーの理解

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

◆前回の復習

前回、ＰＭＯがプロジェクトの支援をうまくできなかったケースを紹介した。

前回、価値観が違うという問題を指摘した。今回は、もう少し、このあたりを考えてみたい。

◆価値観以前の問題～相手が味方になると考えるか？

価値観の違いというのがどこから起こるかという議論をしなくてはならないのだが、それ以前の問題としてスタンスの問題がある。プロジェクトマネジャーとＰＭＯの間の関係において意外と重要なのが、「味方になると考える」ことができるかどうかだ。

プロジェクトマネジャー側から見れば、ＰＭＯを味方だと考えている人はそんなに多くないのではなかろうか？理由はいろいろある。いろいろな対応が面倒だと思うプロジェクトマネジャーもいるし、上位組織の代理人だと思っている人もいる。

一方で、ＰＭＯがプロジェクトマネジャーが味方になると思っているかというと甚だ疑問であ る。たぶん、多くの人は、自分たちは味方なのに、敵対視していると思っているのではないだろうか？これも理由はいろいろある。

このような状況の中において、味方になると考えない限り、相手の価値観を理解し、相手のために何かするということはできないように思える。結局のところ、前回述べたように、自分の価値観で何かをしてそれで終わってしまう。終わるだけならまだよいが、お互いに仕事の本質とかかけ離れたところで手間を取るという最悪のケースになることもある。相手を味方だと思う努力をし、もし、思えないようなら下手に支援をしない方がお互いのためだ。

◆目的を明確にし、付き合う範囲を限定する

プロジェクトマネジャーを味方だと思えたら、次に考えるべきことは、目的を明確にすることだ。ＰＭＯで勘違いしている人が多いのはここだ。ＰＭＯの活動の目的は「プロジェクトの成功です」と考える人が多い。以前にも述べたがＰＭＯの機能体系はいろいろなものがあるが、その中で、標準化／コンサルティング／ナレッジマネジメント／人材育成の４つに分けるという考え方がある。このうち、コンサルティングについてはＰＭＯの活動目的はプロジェクトの成功であるが、それ以外は違う。少なくとも一義的な目的ではない。
たとえば、標準化を主活動とするＰＭＯであれば、よい標準を提供することが目的であり、プロジェクトが成功することは結果にすぎない。ここを混乱し、目的を「プロジェクトの成功」としてしまうと、おのずと便利屋、マンパワーお助け部門の道をたどることになる。また、標準化ＰＭＯがプロジェクトの成功という目的を掲げた場合、プロジェクトマネジャーからすれば、互恵関係の構築のために何をすればよいかを明確でなくなることも問題である。

いずれにしても、目的を明確にし、自分が何のために活動するのか、そして、どういうことをしてもらうとうれしいかを明確にすることは極めて重要なポイントである。

◆プロジェクトマネジャーを理解する

その上で、プロジェクトマネジャーを理解することが必要である。理解のポイントは３つある。ひとつはプロジェクトマネジャーがどういう仕事かということだ。これが理解できていないＰＭＯスタッフはいないと思うが、逆に本当に理解できているＰＭＯスタッフもそんなに多くはないだろう。要するに、自分のＰＭ経験の中で理解しているだけというケースが多く、ここはあらためていく必要がある。

二つ目は、ステークホルダからどういう期待を受け、また、どういうプレッシャーを受けているかである。この点は支援の際には丁寧に聞いていく必要がある。

もうひとつ重要なのは、「プロジェクトマネジャーが何をもとに評価されているか、報酬を受けているか」である。ＰＭＯスタッフでも比較的組織キャリアの長い人はこの点をよく理解できているのだが、若いスタッフがうまく支援できていないケースを見ると、この点に対する理解不足がきわめて多い。単にプロジェクトの成功という業績だと思っていると、日本の組織ではまずうまくいかない。

いすれにしても、これらを中心にして、相手の価値観はできている。

◆交換手段が必要

ここまでくれば価値観が明確になり、価値観に訴えるにはプロジェクトマネジャーとどのような価値交換の構想はできてくるだろう。そこで、具体的な関係構築に入る。

関係構築において、重要なのは「カレンシー」と呼ばれる概念である。カレンシーとは通貨のことで、お互いに相手の価値観に適合した価値の交換をするための手段である。たとえば、あなたがよりよい人事評価を得るために、一生懸命働いているとしよう。この場合、一生懸命働くことがカレンシーになっている。

実は、前回紹介した事件が問題なのは、価値観であるとともに、カレンシーがうまく交換できていない点にある。

カレンシーについては、また、次回。

【補助線】角を矯めて牛を殺す

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

◆最近のプロジェクトの特徴

最近のプロジェクトによく見られる課題がある。

・スケジュールにチャレンジ要素がある
・リソースにチャレンジ要素がある
・仕様があいまいである
・新しい技術へのチャレンジにより、技術的不確実性がある
・今まで全く知らない人とチームを作って取り組む
・チームが分散している
・プロジェクトの中間的なスコープが変化する
・・・

などだ。このような課題がまったくないプロジェクトは珍しいだろう。

米国では、こういった課題のプロジェクトに対して、ＰＭＢＯＫに代表されるような「確定的な」プロジェクトに対して有効なマネジメントが本当に有効なのだろうか？という議論がある。アジャイルプロジェクトマネジメントやライドブレーンプロジェクトマネジメントといった手法が登場してきている。

◆手法ありきの傾向が強い日本

ところが、日本の企業をみていると、このような要素を含むプロジェクトに対して、ＰＭＢＯＫを適用するには何をすればよいかを考えている組織が多い。もちろん、手法を導入するというのはそういうことだから、頭ごなしにそれが悪いということではない。

問題はバランスである。

ＰＭＢＯＫは基本的には上位組織がプロジェクトを「管理」するには、プロジェクトはどのようにマネジメントされていればよいかという発想で作られている。しかし、すべてを管理しようとしても定型業務ではないのだから難しい。そこで、与える権限を明確にして、権限委譲をするようになっている。これに使われるツールがたとえば、プロジェクト憲章である。

ただ、権限委譲というのはそんなに簡単にできることではない。任せるだけであれば「丸投げ」ということで簡単だが、多くのプロジェクトはプロジェクトマネジャーやプロジェクトのエンパワーメントをしなくてはうまくいかない。

結果として、プロジェクトマネジメントを導入してもうまくいかなかった。その分析をしてみると、明らかになったのが冒頭に述べたようなプロジェクトではうまくいっていないという現実だった。

◆２つのアプローチ

ここで多くの組織は２つのアプローチをとることにした。ひとつはこのようなプロジェクトに対応できるようなプロジェクトマネジャーの育成である。一言でいえば、コンピテンシーやヒューマンスキルを持ったプロジェクトを育成しようとした。これは、今でも盛んに行われているが、そんなに短時間でできるものではない。

そこで現実策として出てきたのが、組織のマネジメントによりプロジェクトの性格を変えてしまうことだった。まず、リスクマネジメントと称して、チャレンジ要素を最小限に抑えてしまう。これがもっとも多い。また、不確実性の回避として、ゲート（レビュー）を設けたフェージングを導入した組織も多い。さらにはスコープマネジメントとして、変更管理を中心に行うのではなく、変えないということを前提にした運営を始めている組織も少なくない。

つまり、プロジェクトを定型業務化する方向に走っている。この効果は大きい。プロジェクトの失敗が減ってきた。

◆弊害と対策

これだけであれば、ハッピーエンドなのだが、弊害も見られるようになってきた。競争力の低下だ。商品の機能を落としてみたり、ＳＩサービスの顧客満足を低下させるということがかなり、目につくようになってきた。もちろん、クオリティとチャレンジのどちらが組織の競争力になるかは事業の性格や組織文化によって異なるので、チャレンジをあきらめたすべての組織がそうなっているというわけではないが、競争力を落とすというのが特殊ケースという状況でもない。

この問題の根底にあるのがスポンサーシップである。スポンサーが管理主義に陥ってきて、市場や顧客のニーズに十分な対応するものができない組織が増えてきた。結果として、そんな仕事に対してやりがいを見失っている人も少なくない。

こうなってくると、ＰＭＢＯＫの適用だという話ではなくなってくる。明らかにバランスを失い、手法に合わせて業務を変えるという状況になってくる。

このままでいくと、角を矯めて牛を殺すことになりかねないことをよく認識しておく必要がある。

【補助線】ＰＭＯとＰＭのレシプロシティ

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

前回は、ＰＭＯが作る標準というのは、その通りにやればプロジェクトマネジメントがうまくいくというものでなくてはならないということを述べた。ただし、マネジメントである以上、それは現実的に難しい。そこで、標準化のプロセスそのものを考え直す必要があることを指摘した。

◆ＰＭＯとプロジェクトマネジャーの関係の基本は「互恵関係」

今回は、少し、視点を変えて、この議論の本質を考えてみたい。この議論の本質にあるのは、「レシプロシティ」だと思う。日本語では「互恵関係」という。簡単にいえば、「よい行動には見返りが、悪い行動には報復が戻ってくる」というものだ。

ここで、多くのＰＭＯスタッフが頭を悩ますのは、何がよい行動かということである。

たとえば、あなたが

「上位組織のマネジャーが入る定例のレビューミーティングで、プロジェクトマネジャーの進め方に賛成の態度を示す」

と、その見返りとして、プロジェクトマネジャーは

「プロジェクトであなたが提唱する標準的な手法を使って、成果を作ってくれる」

といった行動をすることを期待するだろう。このような価値の交換が生じるのはレシプロシティである。

何でもない話のようだが、これは以外と難しい。その理由は、価値であるので、決めるのは相手であり、自分である。つまりは主観である。思いつきや、自分の価値感で行ったのでは、相手はそれを評価しない。

相手に評価されないと、人間だれしも、「なんだ、あいつ」という感情が芽生える。

こんな事件があった。

◆ある事件

プロジェクトマネジャーがプロジェクト計画書をなかなか出さない。プロジェクト計画書を出さなければ建前上はプロジェクトは承認されず、作業に着手することはできない。このプロジェクト担当のＰＭＯスタッフは時間がないので、苦労しているのだと思い、そこで、良かれと思って、代わりに計画書のたたき台を作って渡した。プロジェクトマネジャーは一応受け取った。

そこまでしてやったのだから、当然、すぐに計画書が出てくると思っていたが、依然として出てこない。後でわかったのは、このときに顧客側が経営陣の異動があり、計画がひっくり返りそうになっていた。落札はしたもののまた、入札はしていない。プロジェクトマネジャーは、まず、この問題をなんとかするのが先決だと考え、顧客の社内提案の支援をしていたのだ。この時点で、プロジェクトマネジャーは計画書を書いてもらってもありがたくもなんともかなったので、当然、ほったらかしにしていた。

一方、ＰＭＯスタッフは顧客の問題に立ち入っていくのはＰＭＯとしては行き過ぎだと考え、できる範囲で最善を尽くしたと思っている。にも関わらず、プロジェクトマネジャーは何もしない。最初はやんわりと言っていたが、だんだん、攻撃的になってきた。計画書も出していないのに、契約前に顧客に入り込んで仕事をしているというのはどういうつもりだといったことを言い出した。

不幸にもこの企業のＰＭＯは結構強く、最終的にこの声は通ってしまった。事業部長が出てきて、プロジェクトマネジャーに対して、顧客の内部の問題に首を突っ込むな、それよりは提案通り（内示通り）の内容という前提で社内の準備をしろという裁定をした。

どれだけの因果関係があるかは分からないが、結果としてこのプロジェクトは顧客側で中止になった。

この事件における、ＰＭＯ側の問題は何だろうか？これは理屈をいうのは簡単である。たぶん、まっ先に出てくる答えは状況を理解していなかったという答えだろう。ただ、理解していなかったわけではない。プロジェクトマネジャーとも話をしていたし、顧客側の状況も知っていた。

この問題の本質は、価値観にある。ＰＭＯスタッフは、自分たちは間接部門であり、プロジェクトマネジャーが稼いでいる。プロジェクトマネジャーの仕事を助けて利益が出るということを分かっていたにも関わらず、本当にそうは思っていなかった。社内ルールを守るということと、顧客へのサービスをすることを比較したときに前者が勝っていたのだ。えてしてこんなものだ。

では、どうすればよかったのだろうか？これは次回。

【補助線】ＰＭＯが標準を提示する意味

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

◆何のために標準化するのか

前回、問題提起だけしたが、みなさんの結論は出ただろうか？

前回述べたように、標準とは、メソドロジーが適切に適用されるためのルールである。目的とは、なぜ、わざわざ、そのようなルールを作りたいのか？という問題に他ならない。

論理的な答えは簡単だ。標準を作る目的は

　組織としてプロジェクトの成功を予測すること

に他ならない。標準は、組織としてのプロジェクトマネジメントの共通的なアプローチであり、メトリクスとして指標化されたり、あるいはマネジメントプロセスとして具体化され、それが標準としてドキュメント化される。

つまり、標準として決められたメトリクスを守り、決められたプロセス通りにメソドロジーを実施すれば、プロジェクトの成功は保証されるというのが標準なのだ。

◆ＰＭＯが標準を提示する意味

もっと正確にいえば、プロジェクトマネジメントの標準はプロジェクトの成功を保証するわけではなく、プロジェクトマネジメントの成功を保証するだけだ。そして、プロジェクトマネジメントの成功がプロジェクトの成功を生み出す。この因果関係が成り立つためには、メソドロジーが正しい（妥当な）ものであることが必要である。

たとえば、ＰＭＯが標準を示すということは、ＰＭＯとしてその通りにやればプロジェクトの成功を保証することに他ならない。それができるから、プロジェクトマネジメントのオーナーシップを持ちうるのだ。

しかし、現実にそう言われてみてももう一つピンとこないだろう。というよりも、プロジェクトを確実に成功させる方法などないとみんなが思っているといった方がよいかもしれない。では、何が適切ではないのか？メソドロジーなのか、標準なのか？

◆ＰＭＢＯＫの価値

ここでＰＭＢＯＫを導入することの意味が出てくる。ＰＭＢＯＫは膨大なプラクティス集である。つまり、うまくいったプロジェクトでやっているプロジェクトマネジメントのやり方を、９つの知識領域に分けて、プロセスとプロセスを実行するための手法ということで整理したのがＰＭＢＯＫである。

ということは、常識的に考えて、メソドロジーには問題はないと考えられる。現に、そう考えるからＰＭＢＯＫを導入しているともいえる。ということは、うまくいかないとすれば、それは標準の問題だということになり、ついては、ＰＭＢＯＫを導入することは、導入先の組織のプロジェクトの特性に合わせて、ＰＭＢＯＫに適用に当たって標準を策定するという作業を行うことを意味する。

◆現実的な標準化の考え方

実は、これがなかなかできない。つまり、メソドロジーを導入するのは簡単である。しかし、標準を策定するのは至難の技である。

そこで、よく行われるのが、アカウンタビリティというよりも、透明性、可視性を高めるために共通的なアプローチを決めるという方法である。この方法は、プロジェクトや問題を可視化することによって、ＰＭＯや上司組織、あるいは組織全体が知恵を集結することによってプロジェクトをうまく進めていこうという発想に基づいている。このようなアプローチを標準とみなすべきかどうかは別にして、

　組織が常にプロジェクトにかかわっておくことにより、成功を予測できる

といえ、標準の目的を達成するひとつの考え方であることは確かだ。

◆なぜ、標準に対する抵抗があるのか

最後にこの問題について一言触れておきたい。ここまでの議論ではっきりしたと思う。

その標準通りにやったときに、プロジェクトが成功するということが保証されていないからだ。

ただし、プロジェクトマネジメントがマネジメントである以上、万人が納得するメソドロジーなり、標準を発見するのは難しいだろう。

そうすると、標準化のプロセスそのものについて考えなおす必要がある。それが、プロジェクトマネジメントの成熟度を上げることにもなっていく。