« 【イノベーション戦略ノート:042】クロスインダストリー・イノベーション | メイン | 【イノベーション戦略ノート:043】好き嫌いから始めるイノベーション »

2014年7月29日 (火)

【プロジェクトマネジメントをコンセプチュアルにしよう!】第3回 プロジェクトで起こりそうな問題を予測する

バックナンバーはこちら http://mat.lekumo.biz/ppf/conceptual_pm/

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

◆はじめに

Yosoku

前回はPMBOK(R)について、実行力の源泉がコンセプチュアルスキルという話をした。

今回は、コンセプチュアルスキルが役立つ2つ目のポイントとして

(2)プロジェクトで起こりそうな問題を予測する

について考えてみる。



◆リスクマネジメントはうまく行っているのか

これをみて、なんだ、リスクの話かと思った人はもう少し読み進めてほしい。その通りなのだが、意外と認識されていないことだ。

組織からプロジェクトを見たときに失敗することが一番問題で、失敗させないためには徹底的にリスクを洗い出して、最初に手を打っておきたいというニーズがあるため、リスクマネジメントは組織的に、かなりコストを割いて行われているケースが多い。

しかし、実際に行われているリスクマネジメントには、コンセプチュアルスキル由来の問題がある。これについては、戦略ノートに記事を書いたことがあるので、読んでみてほしい。

【戦略ノート305】リスクマネジメントは具体的か


◆経験頼みのリスクマネジメント

この話は一旦おいて、なぜ、組織はプロジェクトマネジャーを信頼できないのだろうかということを考えてみたい。計画レビューのような場で組織全体でリスク分析をすると、確実に言えることは、複数の経験豊かな人が考える分、プロジェクトマネジャー一人で考えるより、いろいろなリスクが出てくる。

要するにリスクを識別できるかどうかは経験頼みなのだ。リスクをチェックリスト化し、分析ツールに使うのはこれを体系的にやろうとしているだけに過ぎない。

ところが、ここに矛盾がある。プロジェクトには新規性なるものがある。したがってリスクも過去の失敗やトラブルの経験からは分からない部分があるのだ。言い換えると二つとして同じプロジェクト計画などない。リスクチェックリストはこのような前提の中でリスクをチェックリスト化していることを理解しておく必要がある。


◆チェックリストとは何か?

つまり、リスクチェックリストはある程度抽象的にならざるを得ないのだ。

たとえば、プロジェクトAのプロジェクト計画とプロジェクトBのプロジェクト計画は違っていた。Aは要件定義のスケジュールが遅れた。Bは要件定義のとっかかりが遅れた。

この2つの事象をリスクチェックリスト化するときにそのまま掲載しても役に立たない。そもそも、AとBでは要件定義の仕方も違うかもしれないし、ほかのプロジェクトでも違うかもしれない。すると、要件定義のどの時期に起こった問題は意味を持たない。

そこで、ほかの共通点を探すことになる。たとえば、Aではユーザが開発サイトに任せっぱなしで要件ヒヤリングに応じなかったのでスケジュールが遅れた。Bでは、ユーザが忙しくて時間が取れなかったのがスケジュールが遅れた原因だったとする。

このレベルまで抽象化するとこれでもいいが、リスクチェックリストによってはもっと抽象化し、顧客の分担の作業できちんとした対応がしてもらえないというリスク事象にまとめたとしよう。

その上で戦略ノート305に書いたように、抽象的に蓄積されているリスクを、当該プロジェクトの計画を踏まえて具体的に識別できて初めてリスクとして意味のある事象になる。つまり、前回の議論と同じで、リスクチェックリストを有効に使うには、具体化する想像力が非常に大切なのだ。


◆リスクとして識別できなかった問題への対応

さて、ここまではいいと思うが、次の問題は進行中のプロジェクトにおいてリスクとして識別できていなかった事象が生じたときにどういう対処ができるのかという問題だ。

ここで、2つのケースが考えられる。一つは具体的なリスク事象は想定していなかったが、発生したリスク事象を抽象化すればリスクチェックリストに含まれているケース。これは、上に述べたように具体化が不十分だった(見落としがあった)ことになる。

もう一つのケースは、抽象化された事象そのものがリスクチェックリストにないケースだ。この場合は単に同じトラブルを起こさないだけでは不十分である。まず、抽象化するが、そのあとで、その具体的な事象として起こる可能性のあることを徹底的に洗い出す必要がある。

言い換えるとリスクチェックリストに新しい事象が登録されたと考えて、もう一度リスク分析をやり直すのだ。

こういうことがコンセプチュアルスキルが高くなるとできるようになる。

コメント

コメントを投稿

PMstyle 7月~9月公開講座(★:開催決定)

PMstyle facebook

Twitterアカウント(PMstyle)

カテゴリ

Googleメニュー

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

最近のトラックバック

Powered by Six Apart

プロフィール

フォトアルバム

好川哲人

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