PMstyle 2024年4月~6月Zoom公開セミナー(★:開催決定)

カテゴリ

Powered by Six Apart

« 2006年1月 | メイン | 2006年7月 »

2006年3月

2006年3月24日 (金)

PMBOKは本当にグローバルスタンダードなのか?

◆PMIの貢献はすばらしい!

PMBOKの勢いは衰えるところを知らない。十数年前に財政危機だったPMIが世界戦略に出て、それが功を奏し、今は本当に飛ぶ鳥を落とす勢いである。すばらしいV字回復である。

PMIの運営の仕方についてはいろいろと批判もあるようだが、昨年末(2005年12月)で

 会員数 208,660人
 PMP数 184,461人(日本人12,977人)

という数字は批判のしようがない数字である。そして何よりも、11カ国語でPMBOKという自らの標準を出版していることはすばらしい文化貢献である。

◆PMBOKは日本人のメンタリティにあうか?

ただ、PMBOKというのはよくも悪くも米国的である。

著者は1995年くらいからPMBOKの導入支援を始めて、相当な数をこなしているが、導入の際に問題になるのは必ずといってよいくらい、アカウンタビリティとレスポンシビリティに対する考え方である。

PMIが定めるプロフェッショナル責任に

(1)個人の健全性(真摯さ)とプロフェッショナリズムの確立
(2)個人の能力(コンピタンス)の増進
(3)専門領域の知識集積への貢献
(4)利害関係者間の調整
(5)チームや利害関係者との協調関係

の5項目がある。(1)~(3)はよいのだが、(4)、(5)はそんなことを言われたくないというメンタリティを持っている国は結構多いのではないかと思う。たとえば、日本だと、こんなことをプロフェッショナル責任として表に引っ張り出されるとこそばゆい部分もあるし、逆にこれが責任だといわれると、抵抗があるという人も結構多い。必要性を否定しているわけではない。

もっといえば、責任だとか、権限だとかを明示的に扱っていくことへの違和感がある。

たとえば、PMBOKで推奨されている、RAM(Responsibilty Assignment Matrix)というツールを導入する。チェックリストとしては便利だし、よく使う。Responsibleが誰かということになるとはっきりしないケースが多い。「責任」という言葉を使うと、みんなの責任であるということになるのだ。そこで、体制については責任にせずに、スコープ区分を応用して定義していく方が現実的だという話になる。

これは、日本企業の強みであるし、現場力の源泉でもある。そして、RAMを作らなくても、スコープ区分で仕事ができるというのは、「アメリカ人」のあこがれる「自律型チーム」であり、そこでは、プロジェクトマネジャーだけでなく、チームとして(4)や(5)の責任を果たしていると思われる。

したがって、(4)や(5)は、わざわざ言われたくないし、明示的に実行することは得意ではないということにもなる。

◆日本人は最強のネゴシエータ

これを日本的だと否定してしまうのは容易であるが、ここで、ジム・トーマスという弁護士・実業家でありながら、世界的著名なネゴシエータの交渉術の本で、日本人の交渉術について指摘されていることを紹介しておく。詳しくは僕のブログの記事

 面目と調和を保つ交渉
 https://mat.lekumo.biz/pm/2006/03/post_c789.html

を読んで欲しいのだが、とりあえず、結論は

 日本人の交渉術には非の打ちようがない!

と絶賛している。その背景にあるのが、(あえてこのような表現をするが)、日本流のアカウンタビリティとレスポンシビリティの扱い方であるのは間違いない。交渉がプロジェクトマネジメントのひとつの柱であるのを否定する人はいないだろう。

このような意見を持つ米国人もいる。米国流の方法がよいと簡単に日本を切り捨ててしまえるだろうか?答えを出す前に、では、他のプロジェクトマネジメント標準はどうなっているのか?

戦略ノートでは今回が91回である。実はこの問題は最近感じている問題ではなく、戦略ノートを始めたときから持っていた問題である。これから100回のカウントダウンに向かって、この問題を考えてみたい。

◆プロセスを考えるか、システムを考えるか?

この問題を考えるキーワードは、プロセスを考えるのか、システムを考えるのかである。

それだけをインプットしておき、まずは、いろいろな標準を分析してみたいと思っている。とりあえず、最初は、PMBOKでは十分ではないという人が、なぜか、一様に取り上げるIPMA(International Project Management Association)のICB(International Competency Baseline)を取り上げてみたい。次回をお楽しみに

プロジェクトマネジメントOSは開発できるか?(1)

◆プロジェクトマネジャーK氏

何回か、プロジェクトマネジメントOS、つまり、PMコンピテンシーは開発できるのか?この問題を考えてみたい。本論に入る前に、PM Magazineの連載に書いたのだが、あるプロジェクトマネジャーの話をしてみたい。

仮にK氏としておこう。K氏は印刷機器の商品開発のプロジェクトマネジャーである。
著者がK氏とであったのは、あるプロジェクトのコンサルティングしたときだ。K氏は15年くらいPMの経験があり、過去にすばらしい業績を残しているらしい。社長表彰も何度か受けている。

新しい知識の習得にも積極的で、最近ではPMBOKを独学で勉強して、自分の経験で説明できるというレベルまで理解していた。当然、組織からの信頼も厚く、今回、戦略商品のプロジェクトのPMに選ばれたのも信頼があればこそだった。

コンサルティングをすぐに、考え方は適切であることがわかり、その能力は見当がついた。おそらく、能力だけでいえば、著者が知っているプロジェクトマネジャーの中でもトップクラスだと思う。経験も、知見もある。

ところが、しばらく様子を見ているうちに、あることに気づいた。確かに、メンバーの動き方や、自分のとるべき行動まで、的を得たことを言うのだが、それに対して、メンバーの行動を支援する行動、あるいは自分自身がこうすべきだと言った行動を実際にしない。たとえば、リスクはチームの主要メンバーが集まってきちんと分析しようとキックオフミーティングで宣言したにもかかわらず、実際には自分だけでリスク分析シートを作ってそれをメンバーに「周知」して終わるといった対応をしていた。

リーダーにこっそりと話を聞いてみたところ、最近、PMを担当したプロジェクトでも同じような傾向があり、メンバーからもそのように見られているとのこと。

あなたの回りにKさんはいませんか?

◆スキルが向上したが、PMコンピテンシーは向上していない

IT系を中心にして、ここ数年で、急速にプロジェクトマネジメント担当者のPMスキルというのは向上してきたように思う。PMBOKに関する理解も進んできたし、また、活用という点でも多くの人が活用している。しかし、一方で、PMコンピテンシーはあまり向上していないように思える。

この連載でしつこいくらい言っているが、PMコンピテンシーというのは能力を表しているわけではない。行動、実践を問うている。つまり、「~できる」かどうかではなく、「~しているかどうか」を表すのがPMコンピテンシーである。どちらが重要かというのは組織、プロジェクト、個人(キャリア)などいくつかの視点があるので、簡単には結論できないが、プロジェクトマネジメントの立場からは、能力では不十分である。行動しているかどうかが問題である。

ここで、曲者概念がある。それは、「実践力」なるものだ。これは非常に扱いが難しい。本来はプロジェクトマネジャーの評価は行動で行うべきものだが、実際にはプロジェクトマネジメント行動は機会がないとできない。たとえば、ITスキル標準でよく問題になるように、ピーク時要員50~100名のSIプロジェクトをマネジメントしているといった場合に、じゃあ、そんな規模のプロジェクトがない企業のプロジェクトマネジャーはどのように評価するのかという問題になる。そこで、実践についてもポテンシャルを表現する概念がほしくなり、それが実践力となる。

ちょっと脱線したが、実践力ではなく、実践でPMコンピテンシーを捉えるとすると、上のK氏はかつてはPMコンピテンシーがあったが、現在はPMコンピテンシーがないということになる。後日談であるが、彼がそのようになっていったのは、実はキャリア的な問題があったためのようだ。ということは、もし、一念発起してがんばると、きっと彼は適切なマネジメント行動をとるようになるだろう。つまり、PMコンピテンシーを持っていることになる。

PMの世界では、PMコンピテンシーはスキルに近い捉え方をされることが多いが、HRMの世界では、キャリアとか、目標管理との関連性が必ず出てきている。K氏の事例を見ていると、やはり、PMの世界でもスキルだけでコンピテンシーを捉えるだけでは不十分ではないかと思う。このあたりに、開発可能かどうかという議論の根底があるように思える。

PMを失敗させる7つの「悪習慣」

◆はじめに

久々のプロジェクトマネジメントOS原論である。このシリーズではPMコンピテンシーを向上させ、プロジェクトを成功させる7つの習慣を取り上げ、その強化策について議論してきた。また、昨年度は5回にわたり、習慣化のセミナーを行ってきた。
また、多くの企業で実践して戴いた。

これらの活動のフィードバックを得て、7つの習慣をバージョンアップした。経験が加味されて、持論がリファインされたという感じである。OS原論で、ご披露をしようと思っているのだが、ある方とお話をさせて戴いている中で、面白いことを指摘されて、今回はちょっと回り道というか、脱線をするが、

  プロジェクトを失敗に陥れるプロジェクトマネジャーの7つの「悪習慣」

というのを書いてみる。

この中には、組織の論理を否定しているものもある。しかし、そこで否定されている組織の論理は、組織がプロジェクトをやるということにとってはマイナスになるものである。『PMOマガジン』で議論をしていく予定だが、組織マネジメントと整合するプロジェクトマネジメントなどありえないと思っている。目的と結果が違うからだ。

組織マネジメントにとって成果は結果に過ぎない。しかし、プロジェクトマネジメントにとって成果は目的である。まあ、そんなことも念頭に置きながら読んで戴けると幸いである。

◆プロジェクトマネジメントを失敗させる7つの「悪習慣」

1’プロジェクトの目的を考えない
プロジェクトの目的が何かを考えず、顧客の言うとおり、上司の言うとおり、計画通りにやるやろうと腐心する。そして、その結果、何か問題が起こった場合には、他人のせいにして、自分は責任をとろうとしない

2’常に受身で行動する
求められるまで報告はしない、求められるまで提案はしない、メンバーから頼まれるまでは動かないなど、常に相手からのアクションがあるまでは自分からは行動しない。

3’ステークホルダとの間で常に勝ち負けを考える
交渉や、トラブル対応の場面では、常に自分が相手より有利な成果を得ることが出来ることを重視し、常に、勝った、負けたを考える。その結果、自らのプロジェクトはスムーズに進み、相手が不本意な状況に陥っても気にしない。

4’チームを使い捨てる
チームはプロジェクト実行のための手段だと割り切り、チームやチームメンバーとはそのプロジェクトが終わるまでの付き合いだと考え、メンバーの成長や、チームの団結などには無関心で、メンバーの持っている能力を使うことだけに関心を示す

5’リスクから逃げ回る
自分の失敗につながる可能性のある意思決定は、確実にうまくいく答えが見つかるまで先送りする。その結果、プロジェクトのスケジュールが遅れても、突っ込んでいたらもっとひどいことになっていたかもしれない、仕方がないと考える。

6’ステークホルダと形式的なコミュニケーションを重視する
顧客にはちゃんと言ったはずだ、上司にちゃんと報告しているという風に、情報伝達をしたという事実にのみ関心をもち、自分の伝えたいことを相手がどのように理解したかには関心を持たない。また、相手から聞いたことに対しても、相手が何を言っているかよりは、自分がどのように解釈しているかを重視する。

7’自分たちの考える品質が達成できれば満足する
お客が欲しいと思うものより、その道のプロフェッショナルである自分たちが価値があると思うものの方が重要だと考え、顧客の意見に耳を貸そうとせず、自分たちの考えを顧客に押し付けようとする。

◆よい習慣を身につけ、悪習慣を追放しよう!

さて、そのような悪習慣に陥らないためにはどうすればよいか?よい習慣を身につけることである。

【プロジェクトマネジメントを成功させる7つの習慣】
・プロジェクトの目的を常に意識する
・ステークホルダとのWin-Winを考える
・チームを成長させる
・リスクをコントロールする
・ステークホルダと共通認識を形成する
・主体的に行動する
・顧客視点で品質を考える

お気づきの方もいらっしゃるかと思うが、冒頭に述べたように、ここに示した7つの習慣2006は、7つの習慣2005から進化している。

◆セミナーもリニュアル

これに併せてセミナーもリニュアルしました。今まで半日(5時間)であったセミナーを、受講者の声を参考に、2日間のセミナーに拡張しました。習慣化のきっかけ作りも、単にワークショップだけではなく、ケーススタディ、ロールプレイと多様化してします。まだ、PMコンピテンシー強化術を受講していらっしゃらない方は、ぜひ、受講してみてください!また、旧・PMコンピテンシー強化術を受講された方で、物足りなさを感じた方にも自信を持ってお奨めします。

新・PMコンピテンシー強化術(習慣編)
   ~プロジェクトマネジメントを成功させる7つの習慣

 http://www.pmstyle.biz/smn/compnew.htm

プロジェクトを手の内に入れる(3)

◆プロジェクトマネジャーの責任

今回はもう少し、プロジェクトを手の内に入れることについて本質的な話をしてみたい。それは、そもそも、プロジェクトをコントロールするとはどういうことなのか、プロジェクトをコントロールするためには何が必要なのかという点だ。

著者は「プロジェクトを成功させるリーダーのスキルとマインドを知る」という定番セミナーの中でプロジェクトマネジャーの責任を

1.計画への落とし込みと共有をする責任
2.計画実行を動機付ける責任
3.計画実行状況を管理する責任
4.状況を説明する責任
5.予想外の状況で判断をする責任

の5つだと定義しているが、この中でより本質的な責任は3.と4.だと考えている。
他のものは、この2つの責任を全うするためにあるといってよい。

◆プロジェクトをコントロールする目的

プロジェクトをコントロールする目的というのはいろいろな見方があるかもしれないが、突き詰めれば

 常にプロジェクトの状況を説明でき、状況に応じた適切な判断をし、プロジェクトの目標を達成すること

である。プロジェクトマネジメントを導入した企業は後半のプロジェクトの目標を達成することには関心が高くなるが、成果責任を果たすというのは実はそちらではない。
前半の部分である。なぜか?

プロジェクトにはステークホルダがいるからだ。例えば、無人島で自分の住む家を建てるのであれば、話は別だ。とにかく家が建てば文句はない。しかし、ビジネスの多くのプロジェクトではそのプロジェクトに関連するビジネス要素はたくさんある。例えば、商品開発であれば、できた商品の広告や売込みをしなくてはならないし、流通の整備もしなくてはならない。ITのプロジェクトであれば、作ったシステムを業務に使うユーザがいる。

このような中で、とにかく、商品やシステムを開発できたというだけでは不十分である。それでも約束した納期内であればともかく、納期を遅れてしまえば全くもって不十分である。

納期に遅れること自体が問題なわけではない(もちろん、遅れないに越したことはないのだが)。プロジェクトをコントロールしているとは、常にプロジェクトに対する見通し、つまり、今どういう状況にあり、ゴール達成が予定通りできそうかどうか、できないとすれば、いつ達成できるのかといったことである。これが計画をベースにして行われなくてはならない。

◆根拠と仮説が重要

そして、常に計画通りに行うためにはどうすればよいかという判断ができ、資源を投入したり、そのほかもろもろのマネジメントが「根拠」を以ってできなくてはならない。これがコントロールである。

この際に注意しなくてはならないことは、この根拠はプロジェクトの不確実性の中で決定されるので、正しいかどうか分からない。論理的であることは求められるが、正しいことは求められない。その根拠に基づいてやってみないと分からない部分が多々あるからだ。いわゆる仮説である。

多くのプロジェクトマネジャーが陥っている問題は、「やってみないと分からない」という部分だけが一人歩きをしていることである。繰り返しになるが、それではステークホルダとのコミュニケーションができない。

例えば、IT系のプロジェクトによくあるが、リソース能力にばらつきがあるので、正確な議論ができないという指摘がある。この問題は難しい部分がある。本当にばらつきが大きい場合には、スケジューリングの基礎をなす手法であるPERT/CPMが統計的な手法なので、そもそも手法の適用ができないという問題が生じる。ただ、統計的に取り扱いが可能な範囲のばらつきであれば、仮説を作ってきちんとコントロールしながら進めていくべきである。

◆別の視点

以上は、計画をベースにコントロールをするという議論であるが、実はコントロールの方法にはこれ以外のものもある。一つは遅れである。遅れの部分にだけ注目してコントロールをしていくような手法がある。これがCCPM(クリティカルチェーンプロジェクトマネジメント)である。もう一つは、「モノ(成果物)」に注目してコントロールをしていく方法がある。これがAPM(アジャイルプロジェクトマネジメント)などの手法である。2月27日に行うセミナーはこのような議論になると思う。

 「売れる製品を作るプロジェクトマネジメント」
  日時:2月27日13:20-17:50
  詳細・お申込 http://www.pmstyle.biz/smn/20060227.htm

プロジェクトを手の内に入れる(2)

◆プロジェクトを手の内に入れる3つの条件

プロジェクトを手の内にいれるには、まず、プロジェクトがどのような特性を持っているか、そして、どのような状態にあるかをよく知る必要がある。そして、うまく変えられる必要がある。この3点である。

◆プロジェクトの特性を知る

プロジェクトの特性を十分知るにはプロジェクトの分析が必要である。プロジェクトの特性とは

・戦略的な重要性
・市場的な重要性
・技術的な新規性
・プロジェクトリスク、あるいはビジネスリスクの大きさ
・期間の長さ

といったものを指す。プロジェクトマネジャーからみれば、これらは既にそのプロジェクトを任された時点で決まっていることの方が多い。しかし、仮に決まっていたとしてもプロジェクト憲章などのドキュメントを分析し、自らの認識を作っておく必要がある。

重要なことはこの点も踏まえて、プロジェクトの収益構造をよく理解しておくことである。最も単純な話は、そのプロジェクトのROI (return on investment) である。請負プロジェクトの場合には収益そのものになる。ROIを踏まえて、プロジェクトに許可された予算の意味を理解することが重要である。ROIを理解していてはじめて、計画から逸脱した場合に適切な判断を行うことが可能になる。

◆プロジェクトの状態を知る

第2は、プロジェクトがどのような状態にあるかを知ることだ。プロジェクトの状態を知るには、しっかりとした計画があり、計画に対してどのような状態にあるかをきちんと計測できる必要がある。プロジェクトの状態として把握しておきたいものはいくつかある。一つはQCDであり、二つ目はスコープである。そして、3つ目はリスクである。いずれも、計画に対してどうだという視点で現在の状態を理解できる。

◆プロジェクトのダイナミックスを知る

3つ目はうまく変えられることである。つまり、計画変更を適切に行うことだ。そのためには、前に述べた2つの点がきちんとできていることが条件になる。つまり、プロジェクトの特性を知り、状態を知っていること。

その上で、プロジェクトのダイナミックスをよく理解しておくことが必要である。例えば、スケジュールを例にとれば、スケジュールが徐々に遅れている場合と、いきなり遅れ始めた場合には、当然、原因的なものが違うし、対処(変え方)も変わってくる。例えば、PMBOK概念に是正という概念があるが、是正をするかしないか、あるいは計画変更をするかは、単に閾値を超えたかどうかというような視点だけでは判断できない。上に述べたようなダイナミックスをきちんと把握した上で判断し行動できてはじめて手の内にいれているといえよう。

このように考えてみると、プロジェクトを手の内にいれる、つまり、適切にコントロールしようと思えば、そのプロジェクトに本気にコミットメントしないと難しいことが分かる。プロジェクトに限らず、自分の仕事に対して、このような対処ができることはプロフェッショナルとしては当たり前のことかもしれない。

◆プロジェクトを手のうちに入れるには

製品開発プロジェクトをフォーカスし、プロジェクトを手の内に入れるというテーマのセミナーを行います。

 売れる商品を作るプロジェクトマネジメントとは
  http://www.pmstyle.biz/smn/20060227.htm