マネジメント予備の意味と使い方

2019年10月5日

PMBOKでは2つの予備費の考え方があります。コンティンジェンシー予備とマネジメント予備です。今回はこの予備費というものについて考えていきましょう。実は予備費といっても「簡単に使えるのか」などと甘く考えていると、悲惨な出来事が待っています。管理人はいくつもの事例を見てきました。

予備費とは何か

PMBOKでの定義

まずは2つの予備費の定義について見ていきましょう。PMBOKでは予備費の定義を次のように説明しています。PMBOKガイド第6版から引用します。

コンティンジェンシー予備

既知のリスクに備えた有効な対応戦略のために、スケジュールまたはコストのベースラインに割り当てられた時間または資金

マネジメント予備

マネジメント面からのコントロールを目的として、パフォーマンス測定ベースライン(PMB)の範囲外に設定したプロジェクト予算またはプロジェクト・スケジュールであり、プロジェクト範囲での予期しなかった作業のために確保される。

イメージ図

PMBOKでのイメージ図を記載してみます。いまいちピンとこないのは管理人だけでしょうか。

PMBOKの予備費
PMBOKの予備費

ざっくりいうと

相変わらずPMBOKの説明はわかりにくいので、管理人がざっくりと説明します。みなさんの母体組織(要するに自社)では違う用語を使っているかもしれませんね。ここではPMBOKに準拠した用語を使用していきます。

    • コンテンジェンシー予備

「プロジェクトマネージャの裁量で判断できるリスク」に対する予備費。

「既知のリスク」すなわち、あらかじめ想定されているリスクの対応なので、プロジェクトマネージャの裁量で使用できます。とはいえ実態としては簡単に使えるわけではありません。

    • マネジメント予備

「プロジェクトマネージャの裁量を超えてしまったリスク」に対する予備費。

「未知のリスク」すなわち、プロジェクトマネージャでは判断できないレベルのリスクに対応するための予備費という扱いです。通常はプロジェクトマネージャの母体組織の上位層(要するにプロジェクトマネージャの上長たち)や、お客様上位層の判断が必要なレベルのリスクに対する予備費です。

予備費の算出方法

予備費予備費と簡単に言っていますが、本来予備費を算出するには以下の手順で行う必要があります。

スコープ・スケジュール・リスク他各計画

大抵のプロジェクトでは、スコープ計画、スケジュール計画・リスク計画等を通してベースラインを決定していることでしょう。これらのベースラインは次のコスト計画に対するインプットです。

予備費の算出に必要になるのは、リスク計画で洗い出している「各リスクに対する上乗せ(うわのせ)工数」です。リスクを考慮しないアクティビティの積み上げをベースラインとした場合、そこに上乗せ(うわのせ)する工数という意味です。

大規模プロジェクトでは上述した通りに、リスクの洗い出しを厳密に行い、各リスク工数を算出します。しかし規模が小さいプロジェクトなどでは、一律何%としてしまっているケースも多いのが実態です。この辺は母体組織の算出方法に準拠しましょう。

コスト計画でコンティンジェンシー予備を算出

次にスコープ・スケジュール・リスクの各計画を通して算出された「各リスクに対する上乗せ(うわのせ)工数」をコストに反映していきます。

リスク計画にて個々のアクティビティの「不確定要素(要するにリスク)」がどれくらいあるかを算定しているはずです。その算定しているリスクがどれくらいになるかを積み上げます。その総数がプロジェクトでの「コンティンジェンシー予備」の総数となります。

簡単に言うと、個々のリスクに対する予備費のことを「コンティンジェンシー予備」と理解しても良いでしょう。

マネジメント予備は?

マネージメント予備は個々のプロジェクトでは算出しません。そもそもそのような予備費が存在することすら知らない場合があります。ベンダー側の視点で考えると、マネジメント予備に該当するものは次のようになると考えています。

  • 母体組織全体の総プロジェクトに対して確保している予備費

プロジェクトマネージャの母体組織(会社や部門レベル)で確保しているものなので、個々のプロジェクト単位ではなく、母体組織として扱っているプロジェクト総数に対しての予備費と考えてもらって良いと考えます。

そのため個々のプロジェクト単位では使用するかどうか判断できません。母体組織の上位層で使用するかどうかの判断をします。

組織の上位層(もしくはPMO)でないと、どのようにしてマネジメント予備費を算出しているのかが正直わかりません。管理人は「いちプロジェクトマネージャ」なのでこの辺が限界です。

管理人が考える予備費のイメージ

今まではPMBOKに沿って話を進めてきましたが、ここで趣向を変えて、管理人が考えている予備費のイメージを載せてみます。

管理人が考える予備費
管理人が考える予備費

 

 

 

 

 

 

 

 

 

みなさんの母体組織によって呼び名は異なると思いますが、話を簡単にするために「アクティビティ=WBS」という用語に置き換えて話を進めます。

まずこのWBS単位のリスクを積み上げて、さらにプロジェクトマネジメント上で想定されるリスクを上乗せ(うわのせ)します。これがプロジェクトのコンティジェンシー予備です。

そして、「WBS工数の積み上げ+コンティンジェンシー予備」が「プロジェクトとして死守しなければならない工数」と呼びます。

ちなみに「マネジメント予備」に該当する項目は、管理人の母体組織では存在していません。存在していてもいなくてもプロジェクトマネージャの管轄外の予備費と考えて問題ないでしょう。

どうですか、幾分シンプルになったのではないでしょうか。

予備費を使用する

予備費を使用しなければならないような事態になってしまったとしましょう。まずは事態を分析しなければなりません。そして上述した「どの予備費の定義になるか」を確定します。

既知のリスクの場合

既知のリスクが発生した場合「コンティンジェンシー予備」を使用します。これは想定されていたリスクに該当します。当然ですが「発生原因・理由・対処方法・必要工数」などの分析をしておきます。

想定したコンテンジェンシー予備の範囲内の場合

想定しているコンティンジェンシー予備の範囲内ならば、使用するのに”さほど”問題はありません。”さほど”ですので注意してください。

手順としては、当該メンバーから必要工数が算出され、プロジェクトマネージャがその妥当性を確認します。そして変更管理プロセス関係者(通常ステコミと呼ばれている)に報告、承認といった流れです。承認されてから使用が認められると考えて良いでしょう。

「コンティンジェンシー予備はプロジェクトマネージャの裁量で使用可能」と言われていますが、「想定内の範囲」であっても、変更管理プロセス関係者やプロジェクトマネージャの母体組織上位層に対して「使用する旨の報告と承認」がなければ、実態としては使用できないケースが多いでしょう。

想定したコンティンジェンシー予備を超えてしまった場合

想定以上の工数が必要になってしまった場合は面倒なことになります。

個々のリスクで算出しているリスク工数を上回ったと仮定します。プロジェクト全体のコンティンジェンシー予備総数の範囲内であれば、他のリスクで算出しているコンティンジェンシー予備を「回してしまう」といった手も使えます。その分「他に回されたリスクが発生した時にどうするか」という策も検討しなければなりません。ここはプロジェクトマネージャの手腕が問われるところです。

この時点ではまだプロジェクトマネージャに裁量の余地はあると考えてもらって良いでしょう。母体組織の上位層や変更管理プロセス関係者に対する報告・承認が必要なことは言うまでもありません。ただし、かなり厳しい質疑応答を覚悟する必要があります。

どのような対策を考えてもコンティンジェンシー予備総数を超えてしまう場合は、マネジメント予備を使用しなければならないケースと酷似します。次のマネジメント予備の項で説明します。

未知のリスク発生、ならびにコンティンジェンシー予備総数を超えてまった場合

マネジメント予備費使用可否の検討が発動されます。先にも書いた通りプロジェクトマネージャの裁量を超えた事態が発生したということです。すなわち「事態の収拾のために母体組織の上位層が動かなればならない事態になった」ことと同義です。

母体組織の上位層や変更管理プロセス(ステコミ)関係者に事態の詳細を報告します。そこでどのように対処していくか討議・決定され、必要であればマネジメント予備を使用してプロジェクトの立て直しを図っていきます。

予備費を使用しなかった場合

おめでとうございます。あなたは優秀なプロジェクトマネージャです。ベースラインを超えることなくプロジェクトを完了させたということは称賛に値します。当然当初のベースラインから変更はあったかもしれません。それでも変更した計画通りにプロジェクトを遂行できたということは母体組織でも表彰されるような成功事例になることでしょう。

プロジェクト完了時とは言わず、工程完了時にもコンテンジェンシー予備の見直しをする場合があります。最近は工程単位の検収(分割検収)が推奨されるようになってきていますので、その単位でコンテンジェンシー予備を設定しています。それを使わなかったということはコンティンジェンシー予備がそのまま「利益」となります。母体組織に対して利益面でも貢献しているということです。すばらしい活躍です。

マネジメント予備費を使用するということ

誰が負担するかで揉める

マネジメント予備を使うということは、プロジェクトマネージャの母体組織(自社)もしくはステコミ関係者(お客様)のどちらかが不足分を負担しなければなりません。不足した原因にもよりますが、非常にシビアな交渉が発生します。自社に責任がある場合は自社から不足分を負担しなければなりません。お客様側に責任がある場合は、追加費用を負担してもらうことになります。これは一筋縄でいくことはありません。長い長いシビアな交渉プロセスが待っています。

自社が負担するにしても、お客様が負担するにしてもいずれにしてもプロジェクトは”赤字”という結果になります。俗に言われる「失敗プロジェクト」です。

上位層の統制下に置かれる

プロジェクトはプロジェクトマネージャの母体組織の上位層の統制下に置かれます。プロジェクトマネージャだけでは「事態の収拾ができない」と判断されるためです。

ひたすら続く上位層への説明

プロジェクトマネージャは覚悟が必要です。当然です。ここでプロジェクトマネージャは事態を収拾できなかった責を問われます。ベンダ側の視点になってしまうことをご容赦ください。これから続く長く険しいお客様との交渉のために、膨大な時間を費やして「原因・理由・対処方法」などに対しての詳細な説明を上位層にし続けなければなりません。当然です。プロジェクトマネージャの代わりに交渉をしてもらうのですから。これは交渉がまとまるまでひたすら続きます。覚悟してください。

プロジェクトマネージャとしての資質を問われる

前項から続きますが、事態を収拾できなかった責によりプロジェクトマネージャとしての資質を問われます。最悪はプロジェクトマネージャをクビにされます。もしかするとクビになった方が良いかもしれません。クビにならずに事態の立て直しに没頭していたプロジェクトマネージャのうち何人かは、精神に支障をきたしてしまった人もいました。クビになったらなったで、次はありません。このような事態を引き起こしたプロジェクトマネージャに、新しいプロジェクトを任せようという上位層は見たことがありません。こうなると正直自社内に居づらくなります。そうやって去って行ったプロジェクトマネージャも何人かいました。

これはプロジェクトマネージャだけではありません。例えば業務設計に起因したトラブルの場合は業務設計担当者にも責があるということになり、同じような追及が待っています。設計者としての資質を問われます。

みんな不幸になる

いくつか例に上げてきた通り、マネジメント予備を使うかどうかを検討している状態というのは、まさにデスマーチの状態になっています。これ以上は語る必要はないですね。ステークホルダー全員が不幸になっているということです。

最終責任はプロジェクトマネージャ

こうなってしまった責任は「最終的にプロジェクトマネージャにある」と断定されます。厳しいようですがプロジェクトマネージャは「プロジェクトを成功に導く」ために存在しているわけですから。

まとめ

予備費を使うということは、プロジェクトに何らかの異常が発生しているということです。そうなる前に未然にリスク発生を察知できるようなアンテナがプロジェクトマネージャには必要です。予備費を使う前にリスクを摘み採れるようにマネジメントをしっかり実施していかなければなりません。

予備費といっても簡単に使えるものではありませんし、簡単に考えていると足をすくわれる事態に発展してしまいます。

そして最終的な責任はプロジェクトマネージャに問われます。「そこまでしてプロジェクトマネージャをやるの?」と言われそうですが、管理人はプロジェクトマネージャをやっていきます。

やはりプロジェクトが成功した時の感激、充実感はなににも変えられませんから。

PM

Posted by wpmaster