プロジェクトマネジメントオフィスの秘密 Feed

2007年11月26日 (月)

【補助線】「標準」再考

◆標準とは何か

前回は、プロジェクトマネジメントの標準は現場のプラクティスを吸い上げていき、構築していくべきだという話をした。

このノートでは、標準については第17回から6回にわたって、「戦略的PMOの標準化への取り組み」と題して議論している。まずは、こちらを改めて読み直してみてほしい。

第17回 戦略的PMOの標準化への取り組み(1)
http://pmos.jp/pmstyle/pmcoe/pmcoe17.html

さて、今回は、この記事も踏まえつつ、標準とは何かということを改めて考えてみたい。

上記の記事でも定義したが、標準とは

 メソドロジー(方法論)の適正な適用を保証するためのルール

である。表現形式は様々である。これについても上の記事を参考にしてほしい。

◆「適正な適用」とは?

ここで考えたいのはこれはどういう意味かということだ。もっと的を絞っていえば、「適正な適用」とは何を指しているのかということだ。

みなさんの組織でスコープ定義をするときに、WBSを作り、中間成果物に対するマイルストーンを設定する、いわゆるマイルストーン管理をすることを「標準」として定めている組織は多いだろう。これは標準といえるだろうか?

実際に、マイルストーン管理をしようとすると、プロジェクトマネジメントの初心者がよく悩むように、WBSでワークパッケージの規模はどのくらいにすればいいのか、あるいは、マイルストーンはどのくらいのスパン(あるいは数)を設定すればよいのかという問題が出てくる。

ここで勘違いしてはならないのは、WBSとか、マイルストーン管理というのは、メソドロジーである。標準とは、これらが適正に適用されるためのルールである。そう考えると、たとえば、上のような問題(ワークパッケージの規模とか、マイルストーンのスパン)の決め方を明示しない限り、メソドロジーが適正に適用されるのは難しいかもしれない。すると、それらのルールが標準だということになる。

◆コンピテンシーを標準化するという考え方

あるいは、発想を変えると、これも、以前の記事で述べたが、「コンピテンシー」を標準化するという考え方もある。プロジェクトマネジメントもマネジメントであるので、適正といってみたところで、一律に決めれるものではないという考え方は当然ある。

すると、メソドロジーを適正に適用するために一律に決めることができるものは何かと考えたときに、プロジェクトマネジャーの能力であり、また、その能力を使った行動であると考えるのだ。実は、マネジメントの中ではこちらの発想の方がマジョリティである。

プロジェクトマネジメントであれば、PMコンピテンシーを入れるものがこれに該当する。同じようなPMコンピテンシーをもった人が2人いたとしよう。その2人がWBSを作ったときに、結果として、WBSのワークパッケージのサイズは違うかもしれない。これはこれで、同等なPMコンピテンシーを持つプロジェクトマネジャーのマネジメント行動なので、両方とも適正な適用をしていると考えましょうという考え方である。

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

ちょっと、違和感を感じる方もいるかもしれない。実は、ここでもう一つ考えるべきことがある。それは、何のために標準化するのかという問題である。

この問題については次回に議論するので、ぜひ、みなさんの方でも考えてみてほしい。

2007年11月19日 (月)

【補助線】続・PMOリーダーに求められるリーダーシップ

前回、PMOはプロジェクトに対してサーバントリーダーシップを発揮すべきだということを書いたところ、プロジェクト(マネジャー)の召使になれというならまだわかるが、理由が分からいし、イメージが持ちにくいという意見を頂いた。また、別の方からはそれはリーダーシップというよりもプロパガンダではないかという意見も頂いた。さらに、別の方からは、そんなユルイことを言っていないで、強権的なリーダーシップを持つべきではないかという意見を頂いた。まあ、記事としてそれなりに響いたということだろう。

プロパガンダという話はある程度、当たっている部分もあるのだが、本質的には違うと思うので、今回、もう一度、この問題を考えてみたい。

◆サーバントリーダーシップが必要な背景(1)

まず、この話の背景はどこにあるのだろうか?この点から考えてみたい。

この話の背景は2つあると思っている。ひとつは今年の5月7日のコラムに書いた話であるが、PMOはその組織のプロジェクトマネジメントのオーナーシップを持つということだ。つまり、プロジェクトをどのように行うかということは事業組織の戦略の問題だとしても、そのプロジェクトのマネジメントをどのように行うべきであるかについては、PMOは決めるべき立場にいる。

実は、5月7日の記事についても、その後、お会いした人と議論したり、メールでご意見を戴いたりしたが、プロジェクトマネジメントのオーナーシップを持つことと、プロジェクトのオーナーシップを持つことは違う次元の話であることを混乱している人が多い。

プロジェクトのオーナーシップを持つことは、プロジェクトの作業をどのように進めるか、顧客にどのようなスタンスで対応するかといったようなことであり、成果物を生み出すことについて、責任と権限を持つということである。これに対して、プロジェクトマネジメントについてオーナーシップを持つというのは、プロジェクトが責任と権限が果たせるようにするために行う管理(マネジメント)に対して責任と権限を持つということである。これは全く異なるものである。

◆サーバントリーダーシップが必要な背景(2)

もう一つの背景は、プロジェクトマネジメントの導入はマネジメントの変革であるということだ。変革であるので、基本的にはPMOがああしろ、こうしろと言える類の問題ではなく、どうすればよいかを当事者が一番よく知っている。知らないのであれば、考えるべき問題である。

PMOがオーナーシップを持ち、強権的にプロジェクトマネジメントのやり方を決めていくというのであればわかりやすいのだが、PMOとしては

・オーナーシップを持つ
・現場(プロジェクトマネジャー)の意見を重視する

という二律背反を実現しなくてはならない。そこで、ポイントになるのが、「変革」であるということだ。

セミナー「PMOによるプロジェクトマネジメントの定着化のポイントと事例」
http://www.pmstyle.biz/smn/pmo_startup.htm

でも基本コンセプトしているが、プロジェクトマネジメントの定着化は変革マネジメントである。したがって、PMOが細かなやり方を指示していくことは適切とはいえばい。むしろ、PMOはプロジェクトマネジメントの方向性、方針、取組のスタンス、導入後のビジョンなどを明確に示し、その範囲で各プロジェクトでプロジェクトマネジャーが工夫したやり方を考える。PMOはプロジェクトマネジャーが実際にそれを実行できるように支援をしていく。そして、うまくいったやり方(プラクティス)を組織に吸い上げていき、調整をしながら、最高のやり方(ベストプラクティス)を作り上げていくことが望まれる。

◆PMOがすべき支援はサーバントリーダーシップを以て可能となる

ただし、プロジェクトマネジャーに一から考えよというのは現実的とはいえない。そこで、プロジェクトマネジャーが「PMOが示したビジョンに対して、マネジメントのやり方を工夫することを支援する」という位置づけで、標準を提供していくことはある意味で不可欠である。

すると、その場合の標準は守らなくてはならないルールという位置づけではなくなる。むしろ、たたき台であり、また、プロジェクトマネジャーたちのこういう風にやっていこうという考えを集約したものになるのだ。その意味で、自己決定であり、プロジェクトマネジメントの導入はスムーズに進んでいくだろう。

このように、決して表にでるわけではなく、といって、裏方だからといって意思決定を逃げるわけでもない。このようなやり方をサーバントリーダーシップという。少しは理解が進んできただろうか?

さて、こういう話をすると違和感がある人がいると思う。そう、組織としてはそんなつもりでプロジェクトマネジメントを入れているわけではない、組織として管理したいのでプロジェクトマネジメントを入れているんだ。プロジェクトマネジャーがレポートをしないというルールをきめたらどうするんだという意見が聞こえてきそうである。

2007年11月13日 (火)

【補助線】リスクマインド

◆リスクマインド

リスクマネジメントの環境整備が進んでいる。たとえば、IT系だと日本プロジェクトマネジメント協会(PMAJ)が標準的なリスクマネジメントマニュアルの頒布をはじめているし、企業独自でリスクチェックリストを準備している企業も増えている。PMOのメインの役割がリスクのチェックだという企業も少なくない。

さて、そんな中で考えておきたいことがある。それは、リスクマネジメントというのは統制では実現できにくということだ。統制というのは確定的なことがらに対して威力を発揮するものである。

◆リスクマインドがあって初めてリスクマネジメントが活きる

一例としてこんなことを考えてみよう

(1)スケジュールが遅れそうであれば、できるだけ早く申し出てくれ
(2)スケジュール遅れが、各アクティビティに対してベースラインの10%を超えたら、その日のうちに報告してくれ

いずれも、プロジェクトマネジャーがメンバーに対して出す指示としてはありそうな話だ。ところが、(2)は実効的であり、統制しているといえるのに対して、(1)はほとんど実効力がなく、統制しているとは言い難い。聞き流して終わりだろう。リスクマネジメントというのは本来は(1)のようなことをやりたいのだ。

もし、メンバーがこのスケジュールが遅れたら、仲間に迷惑をかけるとか、顧客に迷惑をかけるといった「危機感」を持っていたとしたらどうだろうか?まずいことが起こったらちょっとでも早く相談しようと考えるだろう(もっともプロジェクトマネジャーの対応の仕方にもよるが)。

これがリスクマインドである。メンバーやステークホルダがリスクマインドを持っていなければ、リスクマネジメントは機能しない。

◆リスクマインドの診断

さて、では、あなたのプロジェクトリスクマインドの診断をしてみよう。

プロジェクトマネジャーの方は今、あなたがプロジェクトマネジメントを担当しているプロジェクトを思い浮かべて欲しい。PMOの方は、あなたの組織の代表的なプロジェクトを思い浮かべてみて欲しい。

そして、「あなたのプロジェクトにどのくらい当てはまるか?」について、以下の点数をつけていただきたい。

まったく当てはまらない 1点
しばしばあてはまる 2点
かなりあてはまる 3点

(1)計画を無視して作業をすることはまずない
(2)直面する状況、課題はこのプロジェクトでも他のプロジェクトでも起こっているものだ
(3)作業に必要な情報の全てはメンバーの手に入りにくい
(4)プロジェクトマネジャーやメンバーは業務遂行にあたり、特定の方法の遵守を求められる
(5)納期、予算、収益において厳しい計画が課せられる
(6)メンバーは計画の達成のためにしばしば近道となる案を採ろうとする
(7)プロジェクトにミスの報告を躊躇させる雰囲気がある
(8)リスク事象が発生した際に、メンバーに対策を実行する権限を与えられていない
(9)リスク事象に対処するのに必要なスキルや専門知識に欠けるメンバーが多い
(10)問題の討議の中で、議論の前提に疑問を投げかける発言がメンバーからでくることはほどんどない
(11)ミスをすると責められる
(12)他のメンバーに助けを求めにくい雰囲気がある

12の質問の合計点数はいくらになっただろうか?

[1]13点以下の場合
あなたのプロジェクトは高いリスクマインドがある。リスク計画を十分に立てれば、リスクをうまくコントロールすることができる

[2]14~23点の場合
あなたのプロジェクトはリスクマインドが十分とはいえず、リスク計画を作っていても、リスク事象の発生により、致命的なダメージを負う可能性がある。リスクトラッキングをしつこく実行する必要がある

[3]24点以上の場合
リスク計画を作ってもあまり効果がない。リスクマネジメント以前に、リスクマインドの向上策をとるべき。

2007年11月12日 (月)

【補助線】PMOリーダーに求められるリーダーシップ

◆PMOリーダーの定義

PMstyleでは、数年前から「PMOリーダー」という言葉を使っている。ご承知のように、昨年からはPMOリーダー養成講座という連続講座を始めた。PMOブームと相俟って、多くの方に受講して頂いているが、以前として、PMOは本当にリーダーシップを持つ必要があるのかという質問をいまだに受ける。

プロジェクトマネジメントの導入、実施、成熟という一連のミッションに対してリーダーシップを発揮するのがPMOリーダー

というのが答えなのだが、なかなか、理解していただけない。

◆PMOリーダーのリーダーシップ

プロジェクトマネジャー、あるいは組織とPMOの関係からすると、PMOが決めたようにプロジェクトマネジメントを行うことを命令することはもちろん、PMOがプロジェクトの中に入って率先してプロジェクトマネジメントをする、あるいはするように仕向けて行くことは、PMOとしての本務の範囲を逸脱していると考えている人が多いからだ。

実は、このようなリーダーシップをPMOに求めているわけではない。PMOリーダーが発揮すべきリーダーシップはリーダーシップである。サーバントリーダーシップはリーダーとしてフォロワーに奉仕することを基本とするリーダーシップである。ただし、サーバントになるわけではない。

◆PMOの仕事はプロジェクトに奉仕すること?!

仕事がら、PMOの人との付き合いは多いが、PMOがプロジェクトに奉仕すべきだという人は多い(支援という言い方をする人が多い)。しかし、奉仕といった場合に、微妙な、しかし、決定的な温度差がある。プロジェクトマネジャーやプロジェクトが困っていればとりあえず支援しなくてはならないと思っているPMOもいれば、もう少し、支援の目的を明確にして支援しようとしているPMOもいる。

トラブルプロジェクトのサポートという同じ活動を行う2つのPMOを考えてみよう。ひとつのPMOは、プロジェクトでトラブルが発生したときに、経緯はともかくサポートをし、そのプロジェクトを予定通りに終わらせることに全力を尽くして支援する。

これに対して、自分たちが定着させようとしているプロジェクトマネジメントの進め方をしているプロジェクトに対してのみ、トラブルの場合にサポートするPMOがある。こちらはプロジェクトに奉仕するのではなく、「プロジェクトマネジメントに奉仕」しているのだ。

◆PMOの影響力

みなさんのPMOはどちらのタイプだろうか?PMOにリーダーシップはいらないと思っているPMOは前者であることが多い。この場合、如何に尽くせるかというのが問題になる。ちょっと、言葉が過ぎるかもしれないが、このタイプのPMOはなくなってもその組織のプロジェクトマネジメントへの影響は小さい。

ところが後者のPMOの場合、仮にそのPMOがなくなれば、組織のプロジェクトマネジメントは崩壊してしまう可能性すらある。なぜか?

仮に、PMOのミッションが導入、実施、成熟だとしたとすれば、後者のPMOは自ら(あるいは組織としての)ミッションを達成するために支援をしている。これに対して前者のPMOはお助けPMOである。

あえていえば、前者のPMOは、組織としてプロジェクトをきちんと終わらせるというミッションがあって動いているといえなくもないが、このミッションはどちらかというとプロジェクトスポンサーのミッションである。

◆PMOリーダーのリーダーシップはサーバント型リーダーシップ

話を元に戻そう。PMOリーダーは

プロジェクトマネジメントの導入、実施、成熟というミッションに達成のために、プロジェクトやプロジェクトマネジャーの支援を行う

人である。そして、このような奉仕活動はリーダーシップに他ならないことをよく認識しておく必要がある。

リーダーシップには「俺についてこい」型だけではなく、このようにリーダーが考えるミッションを達成するためにフォロワーに奉仕するというタイプのリーダーシップもある。一般的にはこのようなリーダーシップはサーバントリーダーシップと呼ばれる。

サーバントリーダーシップの詳細は、PM養成マガジンの「戦略ノート」に2002年に書いているので、こちらを参考にして頂きたい。

リーダーシップ考(4)~サーバントリーダーシップ
http://pmstyle.jp/honpo/note/note25.htm

2007年10月29日 (月)

【補助線】プロジェクトマネジメント組織のRRAA

◆RRAA

前回、PMOがプロジェクトマネジメントのオーナーシップを持つべきであるという話をしたが、今回は、この点も含めて、PMOがどのような権限と責任を持つべきかを議論してみた。

日本ではあまり使われないが、組織のガバナンスを定義する方法として、RRAAというフレームがある。

 Role(役割)
 Responsibility(実行責任)
 Accountability(説明責任)
 Authority(権限)

である。ステークホルダ分析などの場合にも使われることがある。このフレームに従って、PMOを定義してみよう。

◆PMOのRRAA

最初はいわゆるPMOのRRAAについて考えてみよう。「いわゆる」という書き方が気持ち悪ければ、この後で述べるCPMO(全社PMO)によって確立されたプロジェクトのマネジメントの標準の適用による効果を見ながら、事業部、地域などの範囲で、プロジェクトマネジメント推進の戦術的なマスタープランに対する責任を持つPMOである。

PMOのRRAAは

・Role(役割):PMO
・Responsibility(実行責任):プロジェクトマネジメント遂行の戦術的なマスタープランとリソースマネジメント
・Accountability(説明責任):CPMOと事業部マネジャーへの報告
・Authority(権限):年次の全社マスターポートフォリオ、および、プロジェクト資源予算計画の策定と調整

と定義できる。

◆CPMOのRRAA

次に、CPMOについては

・Role(役割):CPMO
・Responsibility(実行責任):全社におけるビジョン、ミッション、ゴール、目的など、戦略的マスタープラン
・Accountability(説明責任):CEOへの直接報告
・Authority(権限):年次の全社マスターポートフォリオ、および、プロジェクト資源予算計画のレビューと承認

と定義できる。

基本的には、CPMOとPMOでほぼガバナンスが決まってくるが、もうひとつ、PSOの定義を決めておくと混乱が少なくなる。

◆PSOのRRAA

PSOのRRAAは

・Role(役割):PSO
・Responsibility(実行責任):プロジェクトマネジメント遂行のオペレーショナルマスタープランとプロジェクトポーフォトリオマネジメント
・Accountability(説明責任):PMOとラインマネジャーへの報告
・Authority(権限):プロジェクトポートフォリオのオペレーションプランと予算要求の承認

と定義できる。

2007年10月23日 (火)

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

◆活動のオーナーシップという概念

前回まで、PMOマーケティングの話をしてきたが、この問題を議論するために不可欠な要素がプロジェクトマネジメントのオーナーシップである。財務、マーケティング、営業、エンジニアリング、製造など、会社の中で組織管理や製品プロセスで行われているさまざまな活動には、オーナーシップがある。財務であれば財務部門がオーナーシップであり、そのトップ(例えばCFO)がオーナーになる。マーケティングであれば、マーケティング部門がオーナーであり、そのトップ(例えば、マーケティング部長)がオーナーになっている。

オーナーシップは基本的にその分野の活動に対して、すべての権限を持つと同時に、すべての責任を負うことになる。その意味合いは、財務や、マーケティングなどのビジネスシステムやビジネスプロセスを構築し、そのシステムの運用やプロセスの実行に対して責任を持つということである。当然ながら、誤った運用や実行がされた場合には指導する義務が生じる。

◆日本でもこれからはオーナーシップの確立が不可欠になる

さて、米国の動向を見ていると、日本でもこれから、プロジェクトマネジメントも財務やマーケティングと同じようにオーナーシップが生じることが予想される。。つまり、オーナーシップが存在し、そのオーナーシップのもとに、権限と責任を持ってプロジェクトマネジメントの展開が行われるようになるだろう。オーナーシップを持つ部門はいうまでもなくプロジェクトマネジメントオフィスであるPMOである。

今、多くの企業でプロジェクトマネジメントの定着化・普及に苦労している理由のひとつはこのオーナーシップの欠如にあると思われる。PMOマーケティング以前の問題として、プロジェクトマネジメントの実施についてPMOが責任も権限も持たない。単なるプロジェクトの支援部門やプロセス標準部門として位置づけられ、プロジェクトマネジメントに関する社内における権限はプロジェクトマネジャーや組織マネジャーより小さいというのが一般的な姿である。

◆オーナーシップのないという現実

例えば、プロジェクトマネジメント標準の実施を求めたところで、例えば

 ・顧客が異なるやり方を求めている
 ・標準どおりのやり方をするには、スケジュール的にも厳しいし、納期的にも厳し

といった理屈がまかり通っている。こういう書き方をするとそんなことはないと思われるPMOの方も多いと思う。例えば、プロジェクト計画書は組織レビューの対象になっており、そこでは標準に則ったものが求められるという反論がありそうだ。

しかし、そのような組織でも、最終的な「プロジェクトマネジメント成果物」としての体裁は整えられるが、それが厳しく運用されている企業は決して多くない。たとえば、レビューはする。仮に、計画書の内容に問題があれば差し戻しがある(これもそんなに多くない)。ところが、計画書の記載方法に問題があっても指摘だけで、対応してくれで終わる。このような仕組みを持っているある企業の話だが、作業着手時に計画書の監査を実施したところ、作業着手前に計画書が組織レビューされており、指摘事項があったものの中のなんと95%が未対応で作業に着手していた。こんなものだ。これは本来許されるものではないが、上に述べた(実質的な)権限の問題で、プロジェクトマネジメントを実行することに対するオーナーシップがない状況になっているわけだ。

さて、では、このような現状を踏まえてどのようにオーナーシップを確立していけばよいのだろうか?この点については次回議論してみたい。

2007年10月15日 (月)

【補助線】PMOマーケティング

◆定着化サイクルのコラムに戴いた意見

7月9日のコラムでプロジェクトマネジメントの定着化サイクルとして

通知 → 教育 → 奨励

というサイクルが必要だという話をした。この中で、プロジェクトマネジメントの定着化にマーケティングの手法を持ち込んで話をした(実際に、弊社はそういうコンサルティングを行っているのだから当然!)。これに対して、この3ヶ月くらいの間に何人ものPMOの方から懐疑的な意見を戴いた。このメルマガは読者数は2000名弱と少ないのだが、しっかり読んで戴いている方が多く、うれしかった。実は、このような状況に対する偽りのない第一印象はこれ。ただ、僕にも思うところがあるので、今回は意見を整理し、それに対する意見を書いてみたい。

戴いた意見を整理するとおおよそ、以下の3点に集約される。

(1)まず、PMOの顧客は、プロジェクトマネジャーなのか、組織なのか

(2)プロジェクトマネジャーを顧客だと考えた場合、組織としてこうしてほしいというのが入ってくるので、100%顧客のニーズにこたえるということにはならない

(3)組織のニーズの入った標準やツールである限り、彼らがもろ手を挙げてそれを使うということにはならないし、プロジェクトマネジャーにとってのメリットも出しにくい。

◆そもそも、プロジェクトマネジャーとはどういう立場か

まず、基本的な認識として、プロジェクトマネジャーは経営組織の中でどういう立場なのかを考えてみる必要がある。9月7日にブログに以下のような記事を書いた。

プロジェクトマネジャーになるということ
http://mat.lekumo.biz/ppf/2007/09/post_1c25.html

この記事に書いていることが著者の考えである。一口でいえば現場を代表するリーダーではなく、経営を代表するリーダーである。

もちろん、これが一致するのがもっとも望ましいし、このような認識をすることはあまり望ましいものではないという考えも同時にもっているが、現場の立場でものを考えればよい立場ではないということを明確にするために、敢えてこういうものの言い方をしたい。

と同時に、プロジェクトマネジャーの標準やツールありきで、このサイクルを回していっても効果は薄く、自分たちがプロジェクトマネジャーの立場で彼らでは発想できない標準やツールを提供していくことが成功の秘訣であることを述べた。

ただし、現場にいて、現場を取りまとめていくという立場はある。したがって、マネジメントだけではすまない部分もあり、リーダーシップの発揮が求められる部分もある。

まず、これが一点目。

◆PMOにとってはプロジェクトマネジャーも組織も顧客

次にそのように考えた場合、プロジェクトにおいては、プロジェクトマネジャーが経営側の利益代表であり、そもそも、顧客がプロジェクトマネジャーか、組織かという命題の立て方そのものがおかしいのではないかと思う。顧客はいうまでもなくプロジェクトマネジャーであり、その背後には顧客としての組織があると考えるのが正しいだろう。

言い換えるとこの命題は、プロジェクトマネジャーを現場の利益代表だと考えているので発想するわけで、PMOはそこを改めていくべきだ。

さて、そこで、どうすればつかってもらえる標準やツール(以下、サービス)が提供できるかという話だ。7月9日のコラムで書いたマーケティングの話になる。このコラムで3つのサービス開発の方法があると説明した。プロダクトアウト、マーケットイン、マーケットアウトである。

◆PMサービスにおけるプロダクトアウトとは

説明が不十分だったようなので、具体的な例で説明する。プロダクトアウトという方法は、PMOが普段の活動の中で必要だと感じているサービスを提供していくという方法である。組織側の立場に立っていろいろなサービスを提供していくというのはほとんどプロダクトアウトになると思われる。これでは、ほとんど、受け入れられるサービスができないと思われるが、PMOのサービスというのは本質的にそういうものだと思っている人も少なくない。

つまり、自分たちは組織の代理人であり、組織の代わりにプロジェクトマネジメントに関するガバナンスを持っており、それを行使することが使命だ。要するに、ごちゃごちゃ言わずにいうことを聞けという考え方。

これは一理あるのだが、必ずといってよいくらい、事業ガバナンスとのコンフリクトが起こる。つまり、言うことを聞くのはよいが、もし、それで儲からなかったら誰が責任と取るのかという議論の中で、いろいろな問題が起こる。

◆PMサービスにおけるマーケットイントとは

次に、マーケットインという考え方。これはプロジェクトマネジャーのニーズを十分に聞き、それに対して、応えていくことを基本としたサービスの提供方法である。これは一見正しいように見えるかもしれないが、プロジェクトマネジャー自身が現場の利益代表であるとそんなに話は単純ではない。当然、ニーズに応えることができないケースが出てくるだろう。

◆マーケットアウトがすべてを解決する

最後がマーケットアウト。実は、申し訳ないことにこのコラムで次回説明するといってしないままになっている。マーケットアウト戦略は、PMOがプロジェクトマネジャーの立場でプロジェクトマネジャーが発想しない手法や標準を創り、それをサービスとしてプロジェクトマネジャーに提供していくことを意味する。

実は、上に述べたいろいろな問題を一挙に解決する秘訣はここにある。PMOがマーケットアウト戦略をとり、プロジェクトマネジャーの立場で、組織が満足する方法を考案し、サービスとして提供していくことこそが、PMOの成功要因である。

弊社ではこのようなマーケティングをPMOマーケティングと呼んでいる。PMOマーケティングができれば、(1)~(3)の問題が一挙に解決するだろう!

2007年9月30日 (日)

【補助線】プロジェクトマネジメントコストの問題

9月27日で第3期のPMOリーダー養成講座が終わり、懇親会の席でPMOのコストの議論になった。この問題について考えてみたい。

◆そもそもプロジェクトマネジメントコストは誰が持つべきか?

PMOのコスト以前に議論されているようで、本気で議論されていないのがプロジェクトマネジメントのコストをどう考えるかだ。この話はたいへん難しい話であるが、PMOとしてきちんと整理しておかなくてはならない話である。

プロジェクトマネジメントは本来、そのプロジェクトの目的を達成するために行うべきものである。その意味で、何をやって、何をやらないかということはプロジェクトマネジャーが判断すればよい。

しかし、実際にはそうはならない。標準を作る組織が多い。なぜだろうか?

◆アンケートに見る標準化の効果

以前、翔泳社のPMマガジンという雑誌の連載でこのアンケートをやったことがある。この結果で出てきた効果ベスト3は以下のとおりである。

(1)初心者にとって有効 45%
(2)ナレッジの蓄積に有効 35%
(3)プロジェクトマネジメントがうまくできる 10%
http://pmstyle.jp/honpo/survey1/survey4.htm

これからわかるようにプロジェクトマネジメント標準がそのプロジェクトに対して、「直接的なメリット」をもたらしていると感じている人は全体の1割程度に過ぎない。これに対して、組織にメリットがあると思っている人は80%いることになる。

◆標準化の本来の目的は

このアンケートの選択肢には明確な形で書いていないが、標準化というのは本来

 組織として成功を計画をできるようにするため

に策定するものである。言い換えると、このやり方をしていればうまくいくだろうという指標として標準がある。

であるとすれば、その組織の標準のプロジェクトマネジメントは、そのプロジェクトを成功を成功させるために欠かせないものであり、そう考えると、マネジメントコストはプロジェクトが持つというのが筋が通っている。

こういう建前がある。しかし、現実にはそのような筋書きにはなっていない。PMOから、自分たちの策定した標準どおりに行えば、プロジェクトはうまくいくという自信に満ちた言葉を聞いたことはない。標準を策定している側からの言い分は、だいたい、上のアンケートのものに近い。

まず、誰でも同じプロジェクトマネジメントをできるようになる。これは組織としては意味のあることだ。という言い分。確かにプロジェクトの成功率は上がるだろうが、シニアなプロジェクトマネジャーにとっては標準的なプロジェクトマネジメントを行う理由にならない。

そこで出てくるのが、ノウハウの蓄積という話。これはシニアなプロジェクトマネジャーにとっては自分のノウハウを組織に還元させていくという意味で標準を遵守する動機にはなる話だ。ただし、マネジメントコストをプロジェクトが持ってやるべきことではないという但し書きが着くだろう。

◆アカウンタビリティのための標準化という発想は正しいのか?

そこで、PMO側の奥の手が出てくる。アカウンタビリティの確保である。つまり、上司や組織にプロジェクトの状況を説明し、必要とあれば指示を仰ぐのは組織人の義務であるという理屈だ。これを言われればプロジェクトマネジャーはやらざるを得ない。ただし、この場合もプロジェクトがコストを持つという話は成立しにくい。確かに、問題があれば組織として支援するので報告は必須であるというともっともらしいのだが、そもそも、そのような事項は組織がすべきプロジェクトマネジメントであり、それをプロジェクトマネジャーにマルナゲしているのがおかしいのだ。

このように考えると、プロジェクトマネジメントのコストはプロジェクトが持つべきだという論理は分が悪いのだが、あなたは、どう整理すればよいと思われるだろうか?

皆様の意見をお待ちしています。上の記事はブログ記事にしてありますので、こちらにコメントをください!

2007年8月14日 (火)

【補助線】PMBOKはハコモノ、PMOが魂を入れる

◆PMOブーム!?

PMI東京事務局の永谷裕子さんに聞いた話だが、永谷さんがJUAS(日本情報システムユーザ協会)で初めてPMOのセミナーをやったところ、あっという間に100名の応募があったそうだ。

この話を聞いてもそんなにびっくりしないくらい、PMOへの関心は高まっている。PMstyleでも昨年からPMOリーダー養成講座というPMOスタッフ育成の体系的講座(全6回)をやっていBume る。今年4月からの第4期ではほとんどのセッションが満席になっている。

◆米国のある企業@1996

なぜ、こんなにPMOが注目されるようになってきたのだろうか?プロジェクトマネジメントは米国から10年遅れているといわれる。「プロジェクト的な性格を持つ業務の管理方法の唯一解がプロジェクトマネジメントだ」というのは少し違うと思うので、これがそのまま「プロジェクトのマネジメント」が遅れていることと意味しないが、「モダンプロジェクトマネジメント」ということであれば、10年以上だと思う。僕はちょうど、1996年は米国の企業と一緒に仕事をしていたが、今のSI企業と較べると、たぶん、その企業のプロジェクトマネジメントの方が進んでように思う。

この会社にはかなりしっかりとしたPMO組織があった。プロジェクトマネジメントのオーナーシップを持つだけではなく、プロジェクトへの支援活動も実践的なもので、我々のプロジェクトもずいぶん助けられた。特に、米国の拠点にプロジェクト本体があって、日本にも部隊がいるようなバーチャルチームだったが、チームのコミュニケーションの支援はまさに、「プロフェッショナルの業」だったような印象がある。

◆定着に10年かかる

実は最近、PMOの仕事をするようになって、改めて、この企業のPMOマネジャーとコンタクトをしていていろいろなことがわかったが、設立は80年代前半だそうだ。10年くらいはうまく機能しなかったそうだ。ただ、うまく行きだしたら、加速的にうまくいくようになったそうで、このあたりは定着化の話としてたいへん、興味深い。

さて、日本の企業はプロジェクトマネジメントに関心を持つようになってきて、まず、何をやったかというと多くの会社がPMBOKの導入を行った。そして、多くの企業がうまく行かずに苦しんでいる。理由ははっきりしている。PMBOKというのは多くの企業がやっていることを標準化したものだが、その背後にはPMBOKそのものではあまりフォーカスされていないプロジェクトマネジメントの推進体制というのがある。

◆PMBOKはハコモノ、PMOで魂を入れる?

つまり、多くの企業は「ハコモノ」としてPMBOKを入れている。まあ、ハコモノを入れて、後で中身をつめていくというのは日本型マネジメントの特技だといえるので、失敗だとは言い切れないが、あまり感心したことではない。

それはそうとして、我々がPMBOKの導入コンサルティングをやったクライアントのPMOは例外なく、「これだけのことはできないし、プロジェクトマネジャーにやれとも言えない。できる範囲でやればいいよね」という。できなくて当たり前である。プロジェクトマネジャーにやらせることを前提にしているからだ。もちろん、PMOとしても何らかの支援はしなくてはならないと考えるが、そもそも、前提が間違っている。

PMBOKはプロジェクトマネジャーのやることを示したものではない。プロジェクトマネジメントとしてすべきことを示したものだ。

PMBOKを採用する、しないに関わらず、プロジェクトマネジメントはプロジェクトマネジャーだけがやるものではないことに多くの企業が気がついてきた。そこで、とりあえず、PMOを作ってプロジェクトマネジメントの一端を担うようにし始めた。ハコモノにやっと少し、中身ができてきたわけだが、これが、今、PMOが注目されている理由である。

2007年8月 6日 (月)

【補助線】チェンジモンスター

今日はちょっと軽めの話題。

松本人志の初監督作品「大日本人」を見られた方は多いと思う。ビジネスの世界にも、怪獣とその怪獣の退治方法を書いた本がある。

ジーニー・ダックが書いた「チェンジモンスター」にチェンジモンスターという本だ。変革を実現しようとしたときに、抵抗する、新しい動きをぶち壊すといった「活躍」をするモンスターの退治方法を書いた本だ。日本語でいえば、さしむき、「抵抗勢力」といったところだろう。

パロディーではないが、プロジェクトマネジメントの導入、定着化をするときに登場してくるチェンジモンスターの行動を整理してみた。

Monster PMOがプロジェクトに対して、支援、指導をしようとしたときに、こんなチェンジモンスターに出会うことはないだろうか?ちなみに、ジーニー・ダックはボスコンのコンサルタント(出版当時)。論理的なアプローチの一方で、感情的・心理的なアプローチもしなくては変革は成し遂げられないということなのだろう。

■タコツボドン
得意技:自分の担当を超えた視野を持つことを拒否し,「よそ者」の関与を否定する
叫び声:「プロジェクトマネジメント自体がプロジェクトの仕事ではない」、「標準を使えというご忠告はありがたいですが、我々もプロジェクトの成功を第一に検討してみますので、後はお任せください」

■ウチムキング
得意技:社内で何が評価されるかを重視し,顧客等の外部ではなく社内にすべての行動の焦点をあわせ,社内外のズレに目を閉ざす
叫び声:「顧客はいろいろと言っていますが、社内の雰囲気は悪くないし、協力的ですので、このままでうまく行きます!」

■カコボオウレイ
得意技:従来のやり方はどんなに効率が悪くても中止をできない,決断できない
叫び声:「これまでのやり方で、うまくやってきたのだから、直すべきところは直し、このやり方でやるほうが顧客も社内も安心だよ」

■ミザル・キカザル・イワザル
得意技:3匹セットになって,見ざる,聞かざる,言わざるを通し,嵐が過ぎるのを首をすくめてやり過ごす
叫び声:「また、PMOが新しい仕組みを作ろうとしているけど、どうせ今回もまた掛け声だけだ。しばらくすれば、忘れてしまう。動くだけ損に決まっている。様子見だ」

■ノラクラ
得意技:様々な言い訳を使いあの手この手で変革を回避しようとする
叫び声:「顧客の進捗を管理するというのは前例がない。前例のないやり方をすると、社内も顧客も混乱するだけだ。それで協力を得られなくなったらどうする。百歩譲って、社内や顧客が受け入れるとしても、うちのプロジェクトは人手がたりない」

■マンテン
得意技:すべての可能性をリスクを潰して100点満点の報告書がないと動き出せず,結局,具体的なアクションは取れない,あるいは遅れてしかとれない
叫び声:「本当にリスクはこれだけだろうか?まだ検討不足じゃないだろうか?プロジェクト開始前にもう少しじっくり検討しなくては!」、「この計画で絶対に失敗しないといえるだろうか?やるからにはパーフェクトでなければ!」

■カイケツゼロ
得意技:課題の指摘やできない理由の説明は巧みだが,解決策の提言は出せない
叫び声:「協力会社以外からのリソースの調達は何度も検討したが無理なんです。その理由は5つあって...」

【参考資料】
モンスター名は「チェンジモンスター―なぜ改革は挫折してしまうのか? 」が出典。
得意技は「チェンジモンスター―なぜ改革は挫折してしまうのか? 」を一部編集。

PMstyle 1月~3月公開講座(★:開催決定)

PMstyle facebook

Twitterアカウント(PMstyle)

カテゴリ

Googleメニュー

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

最近のトラックバック

Powered by Six Apart

プロフィール

フォトアルバム

好川哲人

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