ダメなWBSではリスクコントロールなん１ミリもできやしない
RBS（リスクブレークダウンストラクチャー）ってなんだっけ、とおもってPMBOKで検索してみたらあった…。たしかに、PMBOKは計画駆動型のプロジェクトマネジメントだから、リスクも計画的に、網羅的に、なんだろうけれど…必要なのかしらん。
識別できなければリスクマネジメントの対象外である
リスクマネジメントの基本的な考え方は、識別したリスクをコントロールすることが狙いなのです。なので、識別できないなら、コントロールしようがないという身も蓋もないアプローチなんですよ。
だから、RBSで網羅的になんでしょうし、経験の少ないプロジェクトマネージャにとってはこういった手法が用意されていて、RBSでリスクを識別しなければならない対象範囲が用意されていることは経験がないことから気付けないことを予防する観点では良いと思うのだけれど…。
RBSの欠陥
でも、PMBOKに載っているRBSは「例」なんですよ。れい。RBS大事だぞ、と言いながら、例しか示さんよ、だと、結局自分で作らないといけない。で、それ、経験したり、見聞きしたことからでしか気付けないんですよ。
これ、考え方が良くても、結局、プラクティスを共有しないなら欠陥があるというとじゃないですか。
簡単なリスクの識別方法
でも、諦めてはいけないのです。簡単なリスクの識別方法があります。それは、
「WBSの進捗を、将来、阻害することをリスクとする」
という考え方です。
例えば、移行実施当日のリスクを洗い出すことにします。移行が中止になることには何があるか。
- 手順書が足らない
- 手順で想定していないエラーが出て対応できない
- 移行時間を超えてしまう
- 移行の正当性確認ができない
あたりは、作業ベースのリスクなので割とスラスラと出てくると思います。でも、ヒト・モノ・カネ・タイムに社会環境や自然を入れたらどうなるでしょうか。
- 移行要員が集合できない
人手が必要な場合、移行要員が集合できなければ移行作業自体始められません。つぎはその原因を想定します。
- 電車が止まる
- 天災が起きる
- 要員に不幸が起きる
馬鹿らしいと思うかもしれませんが、移行を延期できないなら、こうした外部要員のリスクを洗い出すことと、進捗を阻害しインパクトを受けるなら対策が必要になります。
