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

【戦略ノート254】プロジェクトの上位管理者考（１）～混乱を極めるその役割

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

◆混沌を極めるプロジェクト上位管理者の役割

プロジェクトマネジメントはなんとか形になってきた組織が多いが、プロジェクトの上位管理者の役割や機能については、まだまだ、混沌としている企業が圧倒的に多い。大きな理由は２つあるように思う。

一つは、責任分担が不明確なことである。もう一つは、上位管理者がプロジェクトマネジメント（ロール）をあまり理解していないことである。このスレッドでは、プロジェクトの上位管理者の役割や機能を整理してみたい。戦略ノートでは、２００８年に１７６回から８回かけて、一度、この議論をした。しかし、消化不良の部分もあり、また、当時とは考え方も変わっているので、異なる枠組みで改めて、議論をしてみたいと思っている。

第１７４回（2008.01.29）
組織が行うべきプロジェクトマネジメント（１）～責任のフレームワーク

【戦略ノート253】場としてのプロジェクト（2）～ユーザエクスペリエンス

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

◆１０年間使い続けることのできる情報システムは作れるか？

前回、商品開発にしろ、ＩＴにしろ、顧客がもう少し、積極的な参加を望むようになってきた。その中で、プロジェクトマネジメントはどうあるべきかを考える必要があるというところまで話しが進んだ。これから、少し、個別の領域でどうあるべきかを議論していきたいと思っている。まずは、著者がこの議論を考えるきっかけになったＩＴの分野から。

ＩＴの分野でこの問題意識を持ったのは実はもう２０年以上前である。きっかけは、あるコンピュータメーカのユーザシンポジウムで、偶然、聞いたＧＭＳのの情報部門の人の話。おそらく、コンピュータメーカのＳＩ部門に対する要望として、「システムの開発はせいぜい１年だが、我々はそのシステムを１０年間使い続けることになる。そのことを意識して対応をしてほしい」という趣旨のものだった。もっともな話なのだが、その話を聞いた瞬間に思ったのは無理だということだった。

たとえば、ＮＣマシンを調達し、１０年どころか、１５年、２０年使うということは珍しくない。ところが、１０年間使える情報システムの基盤というのは想像できない。自社のビジネスにおける位置づけが違うからだ。もし、１０年間使えるとしたら、情報システムの作りの問題ではなく、その企業のビジネスシステムやビジネスモデルがよほど卓越しているからだろう。実際に、その後、償却期間の設定も短くなり、情報システムのライフサイクルは短くなってきた。

【戦略ノート252】場としてのプロジェクト（１）～プロジェクトとステークホルダ

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

◆プロジェクトという活動

ＰＭＢＯＫでは、プロジェクト・ステークホルダを、プロジェクトという活動に関与する人と定義している。プロジェクトマネジャーもプロジェクトメンバーもみんなステークホルダである。

プロジェクトに対してプロジェクトマネジャーを指名し、そのプロジェクトマネジャーの行う活動というイメージを持つ人が多いが、実はそうではない。プロジェクトには、プロジェクトに投資する人が出す目的があって、その目的に関心や利害関係を持つ人が集まり、役割を決めて目的を達成するというのがイメージに近い。

役割の中では、やや特別な役割となるのが、プロジェクトスポンサーである。プロジェクトスポンサーはプロジェクトを構想し、プロジェクトの目的を決定し、その目的を達成するためにプロジェクトに投資（資源提供）をする。

これがもっとも一般的なプロジェクトのイメージである。

【戦略ノート251】プロジェクトリーダーの役割と責任

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

◆はじめに

春先は、新しいプロジェクトが増え、また、人事異動などの影響で新任のプロジェクトリーダーが増える時期でもある。今回の戦略ノートは、基本に立ち返り、プロジェクトリーダーの役割について考えてみたい。

まず、プロジェクトメンバーとプロジェクトリーダーはどう違うのかについて、いくつかの視点から考えてみよう。

【戦略ノート250】難局を乗り切るマネジメントとリーダーシップ（４）～危機から学び、守りから攻めへスイッチを切り替える

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

◆リカバリーをしたら、リードタイムが短くなった

過去に一度だけ、トラブルリカバリーをして、当初の計画より早く新製品（生産財）が完成し、かつ製品は当初計画より多くに売れた。この話を研修ですると、５人に一人くらいピンとくる人がいる。読者のみなさんのなかにも、気がついた方がいらっしゃると思う。製品機能を予定されていたものから削減をしたのだ。それも、既存機能だ。

スコープを削減する場合には、新規機能を対象とすることが多い。新規機能を対象に考えると、理由にもよるが多くの場合は、頑張ってなんとか実現しようということになる。新規機能に対してマーケティングしているのだから、ある意味、当たり前だ。

ところが、このケースはちょっと事情が違った。スケジュール遅延を引き起こした技術的な問題の解決のためには、既存機能を削るか、新しい機能をあきらめるかという選択をせざるを得なかった。

そこで、ラインナップを変更し、既存機能を削った新製品を開発することになった。

【戦略ノート249】難局を乗り切るマネジメントとリーダーシップ（３）～長期戦を想定し、戦略を描き、計画的に進める

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

◆失敗の法則

トラブルに陥り、不適切な対応で、大失敗に終わるプロジェクトには共通的にみられる対応行動がある。

（１）即効性のある対応にこだわる
（２）起こっていることを深刻さを見誤る

の２つである。この２つは深く関係しており、深刻さを感じないから、即効性だけを考えた対応、悪くいえば目先の対応をする。

【戦略ノート248】難局を乗り切るマネジメントとリーダーシップ（２）～現実を直視する

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

◆米国連邦危機管理庁・元長官のジェームズ・ウィット氏の言葉

米国連邦危機管理庁を公務員的な組織から、危機管理の役割をしっかりと担える組織に立て直したことで知られるのジェームズ・ウィット元長官が自書で

強いリーダーほど、厳しい試練に出会った時にまわりの人たちの力を借りている

という指摘をしている。

では、どのように力を借りればいいのか。これが結構、難しい。試練に出会うとはどういうことかということでもある。今回はこの点について、プロジェクトを念頭において考えてみよう。

【戦略ノート247】難局を乗り切るマネジメントとリーダーシップ（１）～レジリエンスを高める

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

◆回復力、あるいは弾力性

最初のテーマを何にしようかと思って、ふと、頭に浮かんだのがレジリエンス(resilience)である。レジリエンスは一言でいえば、

困難な状況にもかかわらず、うまく適応できる力

であり、カタカナで使われることが多い言葉だが、日本語では回復力とか、弾力性といった言葉があてられる。僕が、レジリエンスという言葉を知ったのは、ある仕事で金井壽宏先生にアドバイスを求めたときに、キーワードとしていただいたことがきっかけである。金井先生は、昨年出版されたポジティブ心理学のワークショップ記録書籍「人勢塾」の中で、以下のように　説明されている。

（レジリエンスとは）ネガティブな逆境、葛藤あるいはポジティブであるが進歩、責任の増大など圧倒されてしまいそうな状況に、立ち向かい、克服し、元の状態にまで跳びはねていく力、さらに、そのような状況に偶然遭遇するだけであく、自らの選択で、安定して快適なゾーンを後にして、なにか新しくて未知なことに乗り出し、途中であきらめずにそれを成し遂げる力を指す。

金井 壽宏編著『「人勢塾」 ポジティブ心理学が人と組織を鍛える』、小学館（2010）
http://people.weblogs.jp/books/2010/04/positive.html

【戦略ノート246】ＰＭＢＯＫはアジャイルに適している

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

※ＰＭＢＯＫはＰＭＩの登録商標です。登録商標マークは省略しています。

◆ついに、ＰＭＩがアジャイルに

米国ＰＭＩがアジャイルプロジェクトマネジメントの試験を始めると発表した。結構、話題になっている。ＰＭＢＯＫとアジャイルというと、水と油のように思っている人が多いようだ。

これが大きな誤解だ。ＰＭＢＯＫはプロセスに対して、インプットとアウトプットが完全につながっている。つまり、全体が巨大な一つのプロセスになっている。ＰＭＢＯＫの信奉者の大好きな世界だが、このことにさして意味があるわけではない。ＰＭＢＯＫのプロセスをすべて実行するようなマネジメントが必要なケースはほとんどないからだ。

ＰＭＢＯＫのすべてのプロセスには、ツールと技法という「プラクティス」が示されている。ＰＭＢＯＫのプロセスは、プロセスの形で示されたプラクティスだと考えた方がすっきりする。

ＰＭＢＯＫの原型ができたのは、１９８７年であるが、標準になったのはそこから１０年後の１９９６年である。当初はプロセスとして標準化しようとしたが、実際には難しく、知識体系に落ち着いたという経緯があり、収束に１０年の月日がたったという話を聞いたことがある。

実際にマネジメントプロセスを記述するというのは不可能に近い。実際に１９９６年に出版された初版のＰＭＢＯＫはすべてのプロセスはつながっていない。

【戦略ノート245】続・プロジェクトマネジメントとプロジェクトリーダーシップ

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

◆プロジェクトリーダーはビジョンを決める

戦略ノート２４２で述べたように、正しい意思決定をするプロジェクトリーダーと、正しくプロジェクトを実施するプロジェクトマネジャーの両方の役割が必要である。言い換えると、プロジェクトにはプロジェクトマネジメントとプロジェクトリーダーシップが必要である。ここで、いくつか考えるべき点がある。

一つ目は、プロジェクトリーダーは何を意思決定する役割かという問題である。もっともしっくりくるのは、プロジェクトリーダーはプロジェクトのビジョンを決める。つまり、そのプロジェクトが企業や社会にとってどのような役割を果たすプロジェクトにするのか、言い換えるとプロジェクトの目的を決める。そして、プロジェクトマネジャーはそのビジョンを実現する役割になる。

このようなフォーメーションでは、プロジェクトリーダーはプロジェクトスポンサーになることが多い。プロジェクトである目的を達成するためにプロジェクトを立ち上げ、予算をつける。そして、プロジェクトマネジャーを指名し、その目的の達成を委ねる。