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

【補助線】プロジェクトマネジャーのＩＯ比

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

今年度の仕事も一段落した。昔ほどではないが、新年度の仕事が立ち上がるまでのこの時期は貴重な充電期になる。

評論家の立花隆氏がよくＩＯ比という言葉をよく使う。インプット（Ｉ）とアウトプット（Ｏ）の比で、ＩＯ比が高ければ高いほど、情報がつまったいい仕事と評価することができるという話。立花氏が評論活動をする際に品質保証のために保っているＩＯ比は１００：１だという。

比のとり方はいろいろだと思うが、１００：１というと、例えば、１００冊の本を読んで１冊の本を書く。１０００時間の取材をして、１０分間の講演をする。こんな感じ。凄い密度である。

ＩＯ比は、知識労働のバランスシートといってもよいだろう。

１０年くらい前に立花氏の著作でＩＯ比の話を読んでそれ以来、ＩＯ比というのを結構気にしている。コンサルをやっている限り、せめて３０：１くらいのＩＯ比は保ちたいと思っている。３０：１を切ると、危険水域だと思う。

３０：１のイメージだが、例えば、

　１時間の話をするのに、最低３０時間の調査や取材をする
　１時間のコンサルをするのに、最低３０時間の類似経験をする

など。コンサルのインプットは、たぶん、経験と情報だと思う。できれば、経験２０、情報１０くらいのＩＯ比を保ちたいと思っている。

気をつけているのは、バランスだ。経験０、情報３０というのは論外だが、逆に、経験３０、情報０になってしまうと３０：１のＩＯ比でも別の意味で危険水域に入ると思っている。サスティナブルではなくなる。サスティナブルであるためには、何よりも、経験と情報のバランスが大切だと思っている。

ただし、経験というのは曲者で、仕事すべてが経験になるわけではない。十分の一もあればいいところではないかと思う。すると、３０時間の経験をしようと思えば、３００時間くらいの仕事をしなくてはならない。これは結構なものだ。

ちなみに、セミナーのようなパッケージものをつくる場合には、ＩＯ比をあげるようにしている。５０：１くらいを目標にしている。例えば、７時間のセミナーを作る際には、３５０時間の調査、経験をベースにするように心がけている。

さて、マネジャー。日本の平均的なマネジャーのＩＯ比というのはどのくらいだろうか？まず、目立つのは１：１、あるいは、せいぜい、２：１くらいのＩＯ比でやっている人が多いことだ。マネジャーやシニアマネジャーになってくると、仕事をしても、ほとんどアウトプットだ（それでなくては給料分の仕事はできない）。従って、仕事はほとんど経験（インプット）にならない。そこで、１は情報を中心にほそぼそという感じになる。どこかで断片的な話を聞いてきたら、そのまま試してみるの繰り返しっていう感じか？

ただし、これでいいかというと要注意。大企業だと問題が顕在化しないが、中小企業だとこのタイプの社長がやっている企業はまず成長しない。大企業でもこのようなマネジャーは確実に組織を蝕む。

ここで、プロジェクトマネジャーについて考えてみよう。ＩＯ比はどのくらいでありたいか？専門職であることを考えると、５：１とか、可能なら１０：１のＩＯ比は保ちたい。あなたのＩＯ比はどのくらいだろうか？一度、計算してみてほしい。

ちなみに、プロジェクトマネジャーにとって、インプットになる経験（プロジェクト）は以下のようなものである。

組織にとって新しい課題解決となるプロジェクト
火消しの仕事
大規模化、クライアントの多様化したプロジェクト
見本となる人との出会いの中でやるプロジェクト
同じ価値感、異なる価値観の人とやるプロジェクト
失敗プロジェクト
プロジェクトマネージャーの交代が起ったプロジェクト
メンバーの業績に問題のあるプロジェクト

ＭＢＡフェロー

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

先週、土曜日に、母校神戸大学の経営学部の大学院で、「ＭＢＡフェロー」というボランティア活動をした。

この活動は、ＯＢの中から２０名ほど選ばれたフェローが現役の学生さん（ほとんど社会人）のゼミに参加して、いろいろとアドバイスをしたり、意見を交わすという活動だ。

神戸大学のＭＢＡコースは発足してもう２０年近くになるが、比較的古い世代のＯＢから選ばれたようで、みんな、卒業後、１０年以上といった感じ。

好川が参加してきたのは、松尾博文教授のゼミで、ＳＣＭとか、製品開発を中心にやっているゼミ。

好川がＭＢＡのコースに行ったのは９５年だが、この当時は学生のほとんど中堅・中小企業だった。大企業は、欧米のＭＢＡコースに留学に出すからだ。

ところが今回、参加してまずびっくりしたのは、大企業ばっかりだったということ。関西を代表する大企業は一通り来ているような様相だ。聞けば、最近では、海外留学はほとんどなく、国内留学が主流になってきたとのことで納得。

これがいいかどうかはともかくとして、まあ、学生の質は高く、議論は刺激があって面白かった。

フリーディスカッションをする機会があって、プロジェクト組織の作り方で激論になった。特に、武田製薬、松下電器、任天堂の方との議論が印象深かったが、なんにしても、ＭＢＡコースに来ている人がこれだけプロジェクトマネジメントに興味をもっていることが分かったのは収穫だった（製品開発のゼミというバイアスがあるが、、、）

日本のＭＢＡコースにもプロジェクトマネジメントの講義を入れるべきですね。

ＭＢＡフェローについてはこちら。

【補助線】事前の責任と事後の責任を区別する

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

以前、メルマガで書いたことがあるが、プロジェクトマネジメントにおける責任には、アカウンタビリティとレスポンシビリティがある。

第１３１回　アカウンタビリティとレスポンシビリティ
http://www.pmos.jp/honpo/note/note131.htm

問題は、どこで責任を明確にするかだ。

例えば、リーダーが自分のチームのメンバーの設計作業の成果物をきちんとレビューしていなかった。そのため、その設計を受けた後段の作業が少し混乱してしまった。ミーティングでは責任追及が始まった。メンバーが悪いだとか、リーダーが悪いだとか。

結局、「組織だからリーダー」がきちんとチェックすべきだという結論になった。

この例で本当に悪いのは誰か？

プロジェクトマネジャーである。事前にリーダーやメンバーの責任を明確にしていない。最低でも、マネジャー　－　リーダー　という体制であれば、リーダーのマネジメントＲＡＭだけでも明確にしておく必要があるのにそれを怠った。ここに問題がある。

プロジェクトでは責任を明確にしなくてはならない。しかし、問題が発生したときに犯人探しをしても問題解決にはならないという。犯人探しをしている時間があれば、その時間で問題の収拾にかかった方が賢明である。そういう教訓である。

どこに間違いがあるかというと、事後に責任を明確にしようとしていることだ。プロジェクトマネジメントで責任をはっきりしなくてはならないのは、事前の責任である。事前の責任をあいまいにしておいて（というか、何かあったらみんなで協力してことに当たろうと誓っておいて）、何か起ったら責任追及をする。

熱さに懲りて膾を吹くではないが、責任追及をしていると、雰囲気が悪くなるので、コトが起きても責任を追求しない。こうなると最悪だ。

ＰＭＢＯＫにプロアクティブという概念がある。ＰＭＩ流プロジェクトマネジメントの根幹をなす概念である。プロジェクトマネジメントの根幹を成すといってもよいかもしれない。

アカウンタビリティについてはステークホルダマネジメント、レスポンシビリティについてはその名のとおり、ＲＡＭといった優れた責任定義のツールがある。このようなツールを使って、必ず、計画段階で責任を明確にしておく。これがプロジェクトマネジメントの本質である。

ちなみに、事後の責任は「連帯責任」が正しい。明らかにあるメンバーのミスでも連帯責任であるし、プロジェクトマネジャーのミスもメンバーとの連帯責任である。事前の責任の明確化の必要性と、事後の連帯責任という認識があって初めて、チームマネジメントというのが必要になってくる

ＰＭサプリ６９：なぜが見えなくなったときが危ない

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

「なぜが見えなくなったときが危ない」（ミシガン大学教授　ジェフリー・ライカー）

【効用】
・ＰＭ体質改善
　　リスク管理力アップ、自信をつける、顧客感度アップ、問題解決能力向上、
・ＰＭ力向上
　　ピープルマネジメント力向上、チームをまとめる力の向上、リスク対応力向上
・トラブル緩和
　　モチベーション向上、チームの士気向上

【成分表示】
◆「なぜが見えなくなったときが危ない」は組織文化
◆非定型業務での「なぜが見えなくなったときが危ない」
◆「なぜが見えなくなること」を防ぐには
◆なぜを理解せずにノウハウを使うのは危ない

このサプリを服用したい方はこちら。

【補助線】プロジェクトと計画

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

先日、リカバリーについて述べたが、もうひとつ、リカバリーに関連してはっきりさせておきたいことがある。

プロジェクトと計画というのを分けて考える必要があることだ。リカバリーという言葉は、

　・プロジェクトのリカバリー
　・計画のリカバリー

という両方の意味で使われるが、この２つは全然意味が違う。前者は目標変更であり、後者は計画変更である。

実は、この区分が必要なのはリカバリーだけではなく、リスクである。リスクにはプロジェクトリスクと計画リスクがある。プロジェクトリスクはプロジェクトのゴールに影響を与えるリスクであり、計画リスクは計画の実行に影響を与えるリスクである。

例えば、技術リスクを考えてみよう。製品の構成技術が実現できないかもしれないというリスクはプロジェクトリスクである。これに対して、設計を効率化する技術に問題が生じるかもしれないというリスクは計画リスクである。

ＰＭＢＯＫでいえばプロジェクトリスクが存在している場合には、そのリスクは回避しないとプロジェクトを開始することはできない。プロジェクトリスクの多くは、プロジェクトに責任はなく、プロジェクトスポンサーが解決すべきリスクが多い。ちなみに、よく、「リスクをとる」という言い方をするが、これはプロジェクトリスクをとることを意味する場合が多い。リスクはどこまで行ってもリスクであり、リスクが起らないことにかけるわけだ。このような場合、リスクモニタリングをいくらしても仕方ない。この手のリスクが運悪く発生した場合には、プロジェクトリカバリーが必要になる。

これに対して、計画リスクは、可能性が大きい、あるいは、計画に対する影響が大きければ、計画の見直しという形で着手前に対応するが、それ以外の場合には、軽減措置をとった上で受容することが多い。しっかりとモニタリングすれば、マネジメントで解決できる範囲にあるからだ。これがリスクマネジメントであり、発生した場合には計画のリカバリーを行うことになる。

実際のプロジェクトを見ていると、プロジェクトリスクはかなり慎重に検討しているが、計画リスクはあまり考えていないケースが多い。計画そのものがそんなにクリティカルではないのでこれで済んでいるが、はやり、ここを何とかし、脂肪のない計画を作りたいものである。

それはそうとして、このプロジェクトと計画の区別がきちんとできることが、大局観の第一歩であることをよく認識しておきたいものだ。

【補助線】プロジェクトの安定性を見極める

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

先日、ＰＭＯリーダー養成講座の中のリカバリーマネジメントのセミナーを行った。このセミナーは、かれこれ、５回くらいやっているのだが、初めて満席になった。

PMstyleが提案しているリカバリーマネジメントは、「安定化」と「そのあとの計画変更」を明確に分けている。

安定化の話をするには、どのような場合にマネジメントが必要かということを整理しておく必要がある。プロジェクトのある時点で、ベースライン計画との差異があるという状態は、代表的には２つのケースがありうる。ひとつは、徐々に差異が大きくなっているケース。もうひとつはどこかでドンと差異が生じてしまって、それをそのまま引きずってしまっているケース。

例えば、スケジュールを考えてみてほしい。プロジェクト期間の３分の１が終わった時点でベースラインと１０％の差が出てきたとしよう。前者であれば、結構、大変な状況である。ほっておくと、おそらく、１５％、２０％とだんだん、差が大きくなってくると考えるのが自然である。このようなクリープ的状態では原因すら分からないことが多い。あるいは複合原因であることが多い。

これに対して、後者である場合、例えば、初期のリソース調達の問題で、着手が１０％遅れた。そして、それがそのまま残っているような場合だ。この場合はそんなに心配するような状況ではない。

この区別をせずに計画変更をしようとするとどうなるか。前者の場合は、計画変更をしてもまず、うまく行かない。スケジュールが遅れているからといって、要員の追加投入をして失敗するようなケースはほとんどこれ。

例えば、このケースの一因に必ずといってよいくらいあるのはコミュニケーションや人間関係の悪さである。そこに、追加要員を投入したらどうなるか。言うまでもないだろう。

これに対して、後者では、適切な時期に、予定通り納期を達成するための手を打てばよい。この場合、コストに対する自由度が出てくる。状態として問題であることは問題なのだが、その中でも回復コストを最適化する余地があるのだ。

このように考えると、まず、最初にすべきことは、プロジェクトが安定か、不安定化を判断することだ。安定な場合には、問題があってもその問題を解消する方法を考えていけばよい。不安定な場合には安定化が必要になる。

ところがプロジェクトマネジャー側の問題というのがあって、状況をよいように解釈したがるのだ。プロジェクトが不安定な状況で、例えば、これから３ヶ月の間にリカバリーしますといってみても信用できるはずはないのだが、そういうことを言う。「ひとつ上のプロマネ。」はなぜそうなったかは別にして、プロジェクトが安定か、不安定かの判断をしっかりとできるようになる必要がある。

どうするかって？セミナーにお越しください！（笑）

プロジェクトリカバリーマネジメント

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

ＰＭサプリ６８：重要な仕事を選択する

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

重要な仕事を選択することのほうが、仕事のやりかたよりも重要である（リン・スニ
ード、ジョイス・ワイコフ）

【効用】
・ＰＭ体質改善
　　アカウンタビリティ向上、実行力向上、問題解決能力向上
・ＰＭ力向上
　　プロ意識の向上
・トラブル緩和
　　チームの士気高揚

【成分表示】

◆価値観に基づく時間管理
◆やるべきことの選択ができるとプロジェクトの成功確率があがる
◆ステークホルダが共通の価値観を持つ

このサプリを服用したい方はこちら。

【補助線】セーラー服と機関銃

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

３月８日にプロジェクトプロの峯本さんをお招きして、第２回のPMstyleスペシャルセミナーを実施した。今回のテーマ「内部統制とプロジェクトマネジメント」は、あまり、食いつきのよいテーマではなかったが、それでも、３０名近くの方にご参加頂いた。お越しいただいた方、本当にありがとうございました。

食いつきの悪かった理由で、何人もから指摘されたのは、「内部統制プロジェクト」の話、あるいは、内部統制プロジェクトのマネジメントの話だと思ったというもの。ある知人が言った言葉が印象に残った。「プロジェクトマネジメントと内部統制」って「セーラー服と機関銃」みたいな印象を受けるテーマだとか。。。むう

だれもプロジェクトマネジメントで内部統制ができるとは思っていない。でも、、、

これは今後の反省点になった。確かに内部統制プロジェクトでもプロジェクトマネジメントは重要だが、内部統制としてのプロジェクトマネジメントはその数十倍重要なテーマだろう。

それはそれとして、峯本さんの話は、今まで僕が聞いた話の中ではもっともプロジェクトマネジメントの話に具体的に言及した話で、主催者としてだけではなく、一受講者としても満足なセミナーだった。

今のブームともいえるような内部統制への関心の高まりの原因になっているのは、いうまでもなく、来年の春から施行される日本版のＳＯＸ法である 。なぜ、ＳＯＸ法という財務会計のシステムの健全性を規制する法律がこんなに関心を集めているかというと、実施基準（評価対象）の中に
　（１）財務報告に関する業務プロセス
　（２）事業目的に大きくかかわる勘定科目に至る業務プロセス
というものに並んで、
　（３）質的に重要な業務プロセス
という一項目があるためである。つまり、いくら財務関連の業務プロセスがきちんとしていても、それ以外の業務プロセスがきちんとしていない限り、問題になるからだ。

先日、ついに、日本での実施基準が明確になった。全般的な印象としては、米国の実施基準と比べて（３）が重視されている印象がある。これは日本人の考え方や、これまでの仕事のスタイルを考えてみると、非常に現実的だし、ある意味で、競争力の源泉になっていくことが予想されるので、評価できる。

中でも注目されるのが、非定型業務が（３）の中でも重視されていることである。非定型業務とはいうまでもなくプロジェクト業務である。言い換えると、Ｊ－ＳＯＸ法が施行されると、プロジェクトマネジメントをきちんとやらないとまずいという状況が発生したわけだ。

いよいよ、日本のプロジェクトマネジメントも正念場を迎える。今までのように、形を作っておけばよいといった状況からの一段の飛躍が必要になる。このテーマは、今後、PMstyleの重要課題として扱っていきたいと思うので、ひとつ上のプロマネ。を目指す方は、ぜひ、押さえておいてほしい！

ＰＭサプリ６７：リーダーシップを共有する

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

「高い業績を誇るチームではリーダーシップが共有される」（ジョン・カッツェンバ
ック、ダグラス・スミス）

【効用】
・ＰＭ体質改善
　　ＰＭ体質の全般に対して効果があります
・ＰＭ力向上
　　ＰＭ力向上の全般に対して効果があります
・トラブル緩和
　　モチベーション向上、チームの士気向上

【成分表示】

◆ホットグループで引用されたカッツェンバックの名言
◆管理も一つの仕事に過ぎない
◆ＰＭＩ流のプロジェクトマネジメントでの考え方
◆楽しく仕事ができるプロジェクトを創るには

サプリを服用したい方はこちら。

【補助線】顧客に対応することは義務、それとも権限

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

ＰＭＯマガジンにプロジェクトマネジャーの権限についての記事を書いていて、ちょっと迷ったこと。

それは顧客に直接対応することは権限か、義務か？という点。ベンダーに対応することは明らかに権限のように思うが、顧客に対してはどうかといわれると、権限だと思っている人はほとんどいないし、実際に権限化していないようにも見える。

プロジェクトマネジャーの権限というのは多くの人が言うが、そもそも、義務と権限というのは何かという議論もある。プロジェクトマネジャーの権限とは、プロジェクトを成功させる上でプロジェクトマネジャーに意思決定をさせるべきものである。義務とは組織のガバナンスを維持するために行う仕事である。この話を組織ガバナンス（業務ガバナンス）の議論がごちゃまぜになっているので、話がややこしくなっている。

例えば、調達の決裁を考えてみよう。大雑把にいえば、調達内容に関する意思決定と調達方法に関する意思決定がある。一概には言えないが、調達方法によってプロジェクトの成功に大きな影響があるケースは珍しい。ところが、調達内容の意思決定は成果物に大きな影響があるし、成果物そのものだといえるケースも少なくない。

このような場合、調達内容の決定に関する権限委譲はするが、調達方法に関する権限委譲はしないというのが妥当な線だろう。ところが、このような整理をせずに、調達に関する権限委譲をするかどうかを議論するので話がややこしくなる。

さて、では、顧客に直接対応することは権限か、義務か。僕は権限だと結論したのですが、みなさんはどちらだと思いますか？

お客様がいない場合には、仮想顧客になるステークホルダで考えてみてください。