私、キットＰＭはこの度の地震と津波に被災された方々に心からのお見舞いを申し上げます。また、亡くなられた多くの方々のご冥福をお祈りいたします。
少しでも被災された皆様のお役に立ちたい、それにはどうしたらよいかキットＰＭなりに考えましたが、やはり本職のノウハウのご提供が一番だと思い立ちました。被災された中小企業の皆様のために、緊急のプロジェクトの立上げやプロジェクトのリカバリを行う場合の計画立案のために、キットＰＭの方ハウを無償でご提供いたします。
ご提供可能なサービスの内容についてはこちらをご覧ください。
◆－－－－－－－－－－－－－－－－－－－－－◆
■先の週末はとても良い天気でした。みなさんは春を満喫されているでしょうか。
被災地の事を考えるととてもそんな気になれないという方もいらっしゃるでしょうが、今ここで春の息吹を感じながら亡くなられた方のことを思うのも一つの鎮魂となるように思います。
■前回お約束した「思考プロセス」のケーススタディですが、一昨日と昨日「現状問題構造ツリー」作成にトライしていましたが、まだ完成していません。申し訳ありませんがもう少しお待ちください。
■で、今回はもう一度「リカバリマネジメント」の難しさについて異なる側面で考えてみたいと思います。
リカバリが必要になったということは、予期せざることが起きたということですから（通常はです。ときどきなるべくしなったトラブルというのもありますがそれはまた別の問題。）当然、プロジェクトに関わる全てのリソースつまり人、金、時間が程度の差こそあれ余分に消費されることになります。これは法則であり例外はありません。あるのは、予定外に対応するバッファ内に収まるか否かです。
余分に消費するということは明確に数字で見えて評価し易いため、往々にしてＰＭが消費を最小限にするための努力を優先することがあります。
でもちょっと待ってください。このブログで再三強調しているのはプロジェクトマネジメントの肝心は「目的」の明確化にあるということです。ＰＭの選択や判断はこの「目的」を達成するための１点によるものでなければなりません。
また、目的を達成するための具体的な成果物を現す「目標」は複数あって、それには優先順位をつけていたはずです。ということは、ＰＭが何を優先して判断すべきかはプロジェクト開始時点で計画されているはずです。
つまり、リカバリが必要になった時点で何かを犠牲にする必要があり、その何かは予め決まっていてそれを問題の大きさ（リカバリに必要なリソース投入量）と天秤にかけて判断するということになります。要するに痛みを伴うということです。
誰かが痛みを感じなければ、プロジェクトリカバリはできないということを正しく理解することが、一番難しいことかもしれません。往々にしてその痛みがプロジェクトメンバの労働時間に集約される場合があるのは問題ですが。
■上の例は、プロジェクト計画が正しく行われていてかつトラブルが発生したという場合の話です。
でも現実的にはそのようなプロジェクトはまだ少ないのです。外部のＰＭが火消しに入ったときにまず行う「現状確認」では、プロジェクト憲章やプロジェクト計画書の確認から入ります。当然ですよね。
ところが、それらの資料に火消しが期待する情報があるとは必ずしも保証されているわけではありません。さすがに何も資料がないということはありませんが、不十分であったり不完全であったりします。
そんなとき火消しはそもそものプロジェクトの目的まで遡って確認するハメに陥ります。その作業を通して、プロジェクトオーナーや経営者が本来望んでいることと、掲げているプロジェクトの目的が異なるということに気がつく場合もあります。こうなるとリカバリ以前の問題となり、まず、プロジェクトをストップする必要があります。でも、これを、ステークホルダに理解してもらうのは至難の業です。
■ん～、こう考えるとプロジェクトスタートの時点でちゃんと考えて計画していると、そう簡単にリカバリマネジメントが必要になる状況とならないことがよく解ります。なぜなら、当初計画時にリカバリの方針も内包しているということですから。通常のマネジメントで対処できるはずです。
とはいっても、通常のマネジメントをどこまで”ちゃんと”やれるかは個々のＰＭに委ねられるわけですから、やはりリカバリマネージャもなくならないのでしょうね。
■まとめ
リカバリマネジメントが必要になる時点で、何らかの予期しないコストが発生するのは避けられない。問題はそれを容認できるかどうか、また何を犠牲にできるかの心構えがあるかということになります。
ＰＭにはそのための判断基準を予め準備し、それに基づいて判断していくことが求められるということです。
■さて次回はなんとか「思考プロセス」の一部でもご覧頂けるように頑張ります。