2019年10月5日TwitterFacebookGoogle+LinkedInPocketLINELINEPMBOKでは2つの予備費の考え方があります。コンティンジェンシー予備とマネジメント予備です。今回はこの予備費というものについて考えていきましょう。実は予備費といっても「簡単に使えるのか」などと甘く考えていると、悲惨な出来事が待っています。管理人はいくつもの事例を見てきました。まとめ予備費とは何かPMBOKでの定義まずは2つの予備費の定義について見ていきましょう。PMBOKでは予備費の定義を次のように説明しています。PMBOKガイド第6版から引用します。既知のリスクに備えた有効な対応戦略のために、スケジュールまたはコストのベースラインに割り当てられた時間または資金マネジメント予備マネジメント面からのコントロールを目的として、パフォーマンス測定ベースライン(PMB)の範囲外に設定したプロジェクト予算またはプロジェクト・スケジュールであり、プロジェクト範囲での予期しなかった作業のために確保される。イメージ図PMBOKでのイメージ図を記載してみます。こないのは管理人だけでしょうか。PMBOKの予備費ざっくりいうと相変わらずPMBOKの説明はわかりにくいので、管理人がざっくりと説明します。みなさんの母体組織(要するに自社)では違う用語を使っているかもしれませんね。ここではPMBOKに準拠した用語を使用していきます。「プロジェクトマネージャの裁量で判断できるリスク」に対する予備費。「既知のリスク」すなわち、あらかじめ想定されているリスクの対応なので、プロジェクトマネージャの裁量で使用できます。いえ実態としては簡単に使えるわけではありません。「プロジェクトマネージャの裁量を超えてしまったリスク」に対する予備費。「未知のリスク」すなわち、プロジェクトマネージャでは判断できないレベルのリスクに対応するための予備費という扱いです。通常はプロジェクトマネージャの母体組織の上位層(要するにプロジェクトマネージャの上長たち)や、お客様上位層の判断が必要なレベルのリスクに対する予備費です。簡単に言っていますが、本来予備費を算出するには以下の手順で行う必要があります。プロジェクトでは、スコープ計画、スケジュール計画・リスク計画等を通してベースラインを決定していることでしょう。これらのベースラインは次のコスト計画に対するインプットです。予備費の算出に必要になるのは、リスク計画で洗い出している「各リスクに対する上乗せ(うわのせ)工数」です。リスクを考慮しないアクティビティの積み上げをベースラインとした場合、そこに上乗せ(うわのせ)する工数という意味です。大規模プロジェクトでは上述した通りに、リスクの洗い出しを厳密に行い、各リスク工数を算出します。規模が小さいプロジェクトなどでは、一律何%としてしまっているケースも多いのが実態です。この辺は母体組織の算出方法に準拠しましょう。次にスコープ・スケジュール・リスクの各計画を通して算出された「各リスクに対する上乗せ(うわのせ)工数」をコストに反映していきます。リスク計画にて個々のアクティビティの「不確定要素(要するにリスク)」がどれくらいあるかを算定しているはずです。その算定しているリスクがどれくらいになるかを積み上げます。その総数がプロジェクトでの「コンティンジェンシー予備」の総数となります。簡単に言うと、個々のリスクに対する予備費のことを「コンティンジェンシー予備」と理解しても良いでしょう。マネジメント予備は?マネージメント予備は個々のプロジェクトでは算出しません。そもそもそのような予備費が存在することすら知らない場合があります。ベンダー側の視点で考えると、マネジメント予備に該当するものは次のようになると考えています。母体組織全体の総プロジェクトに対して確保している予備費プロジェクトマネージャの母体組織(会社や部門レベル)で確保しているものなので、個々のプロジェクト単位ではなく、母体組織として扱っているプロジェクト総数に対しての予備費と考えてもらって良いと考えます。そのため個々のプロジェクト単位では使用するかどうか判断できません。母体組織の上位層で使用するかどうかの判断をします。組織の上位層(もしくはPMO)でないと、どのようにしてマネジメント予備費を算出しているのかが正直わかりません。管理人は「いちプロジェクトマネージャ」なのでこの辺が限界です。管理人が考える予備費のイメージ今まではPMBOKに沿って話を進めてきましたが、ここで趣向を変えて、管理人が考えている予備費のイメージを載せてみます。管理人が考える予備費みなさんの母体組織によって呼び名は異なると思いますが、話を簡単にするために「アクティビティ=WBS」という用語に置き換えて話を進めます。このWBS単位のリスクを積み上げて、さらにプロジェクトマネジメント上で想定されるリスクを上乗せ(うわのせ)します。これがプロジェクトのコンティジェンシー予備です。「WBS工数の積み上げ+コンティンジェンシー予備」が「プロジェクトとして死守しなければならない工数」と呼びます。ちなみに「マネジメント予備」に該当する項目は、管理人の母体組織では存在していません。存在していてもいなくてもプロジェクトマネージャの管轄外の予備費と考えて問題ないでしょう。幾分シンプルになったのではないでしょうか。予備費を使用する予備費を使用しなければならないような事態になってしまったとしましょう。事態を分析しなければなりません。上述した「どの予備費の定義になるか」を確定します。既知のリスクが発生した場合「コンティンジェンシー予備」を使用します。これは想定されていたリスクに該当します。想定しているコンティンジェンシー予備の範囲内ならば、使用するのに”さほど”問題はありません。”さほど”ですので注意してください。手順としては、当該メンバーから必要工数が算出され、プロジェクトマネージャがその妥当性を確認します。変更管理プロセス関係者(通常ステコミと呼ばれている)に報告、承認といった流れです。承認されてから使用が認められると考えて良いでしょう。「コンティンジェンシー予備はプロジェクトマネージャの裁量で使用可能」と言われていますが、「想定内の範囲」であっても、変更管理プロセス関係者やプロジェクトマネージャの母体組織上位層に対して「使用する旨の報告と承認」がなければ、実態としては使用できないケースが多いでしょう。想定以上の工数が必要になってしまった場合は面倒なことになります。個々のリスクで算出しているリスク工数を上回ったと仮定します。プロジェクト全体のコンティンジェンシー予備総数の範囲内であれば、他のリスクで算出しているコンティンジェンシー予備を「回してしまう」といった手も使えます。その分「他に回されたリスクが発生した時にどうするか」という策も検討しなければなりません。ここはプロジェクトマネージャの手腕が問われるところです。この時点ではまだプロジェクトマネージャに裁量の余地はあると考えてもらって良いでしょう。母体組織の上位層や変更管理プロセス関係者に対する報告・承認が必要なことは言うまでもありません。厳しい質疑応答を覚悟する必要があります。どのような対策を考えてもコンティンジェンシー予備総数を超えてしまう場合は、マネジメント予備を使用しなければならないケースと酷似します。次のマネジメント予備の項で説明します。未知のリスク発生、ならびにコンティンジェンシー予備総数を超えてまった場合マネジメント予備費使用可否の検討が発動されます。先にも書いた通りプロジェクトマネージャの裁量を超えた事態が発生したということです。「事態の収拾のために母体組織の上位層が動かなればならない事態になった」ことと同義です。母体組織の上位層や変更管理プロセス(ステコミ)関係者に事態の詳細を報告します。そこでどのように対処していくか討議・決定され、必要であればマネジメント予備を使用してプロジェクトの立て直しを図っていきます。予備費を使用しなかった場合おめでとうございます。あなたは優秀なプロジェクトマネージャです。ベースラインを超えることなくプロジェクトを完了させたということは称賛に値します。当初のベースラインから変更はあったかもしれません。それでも変更した計画通りにプロジェクトを遂行できたということは母体組織でも表彰されるような成功事例になることでしょう。プロジェクト完了時とは言わず、工程完了時にもコンテンジェンシー予備の見直しをする場合があります。最近は工程単位の検収(分割検収)が推奨されるようになってきていますので、その単位でコンテンジェンシー予備を設定しています。それを使わなかったということはコンティンジェンシー予備がそのまま「利益」となります。母体組織に対して利益面でも貢献しているということです。マネジメント予備費を使用するということ誰が負担するかで揉めるマネジメント予備を使うということは、プロジェクトマネージャの母体組織(自社)もしくはステコミ関係者(お客様)のどちらかが不足分を負担しなければなりません。不足した原因にもよりますが、非常にシビアな交渉が発生します。自社に責任がある場合は自社から不足分を負担しなければなりません。お客様側に責任がある場合は、追加費用を負担してもらうことになります。これは一筋縄でいくことはありません。長い長いシビアな交渉プロセスが待っています。自社が負担するにしても、お客様が負担するにしてもいずれにしてもプロジェクトは”赤字”という結果になります。俗に言われる「失敗プロジェクト」です。上位層の統制下に置かれるプロジェクトはプロジェクトマネージャの母体組織の上位層の統制下に置かれます。プロジェクトマネージャだけでは「事態の収拾ができない」と判断されるためです。続く上位層への説明プロジェクトマネージャは覚悟が必要です。ここでプロジェクトマネージャは事態を収拾できなかった責を問われます。ベンダ側の視点になってしまうことをご容赦ください。対しての詳細な説明を上位層にし続けなければなりません。プロジェクトマネージャの代わりに交渉をしてもらうのですから。これは交渉がまとまるまでひたすら続きます。プロジェクトマネージャとしての資質を問われる前項から続きますが、事態を収拾できなかった責によりプロジェクトマネージャとしての資質を問われます。最悪はプロジェクトマネージャをクビにされます。するとクビになった方が良いかもしれません。クビにならずに事態の立て直しに没頭していたプロジェクトマネージャのうち何人かは、精神に支障をきたしてしまった人もいました。クビになったらなったで、次はありません。このような事態を引き起こしたプロジェクトマネージャに、新しいプロジェクトを任せようという上位層は見たことがありません。なると正直自社内に居づらくなります。やって去って行ったプロジェクトマネージャも何人かいました。これはプロジェクトマネージャだけではありません。業務設計に起因したトラブルの場合は業務設計担当者にも責があるということになり、同じような追及が待っています。設計者としての資質を問われます。みんな不幸になるいくつか例に上げてきた通り、マネジメント予備を使うかどうかを検討している状態というのは、まさにデスマーチの状態になっています。これ以上は語る必要はないですね。ステークホルダー全員が不幸になっているということです。最終責任はプロジェクトマネージャこうなってしまった責任は「最終的にプロジェクトマネージャにある」と断定されます。厳しいようですがプロジェクトマネージャは「プロジェクトを成功に導く」ために存在しているわけですから。まとめ予備費を使うということは、プロジェクトに何らかの異常が発生しているということです。なる前に未然にリスク発生を察知できるようなアンテナがプロジェクトマネージャには必要です。予備費を使う前にリスクを摘み採れるようにマネジメントをしっかり実施していかなければなりません。予備費といっても簡単に使えるものではありませんし、簡単に考えていると足をすくわれる事態に発展してしまいます。最終的な責任はプロジェクトマネージャに問われます。「そこまでしてプロジェクトマネージャをやるの?」と言われそうですが、管理人はプロジェクトマネージャをやっていきます。プロジェクトが成功した時の感激、充実感はなににも変えられませんから。wpmasterよろしければシェアお願いしますTwitterFacebookGoogle+LinkedInPocketLINELINE関連記事プロマネ資格を取得して約1年、結果を報告します早いものでプロマネ資格を取得してはや一年。...プロジェクトマネージャに必要なのは知識より情熱?よく聴く言葉です。「プロジェクトマネージャは情熱が必要である」と。...リスクとコンティンジェンシー予備プロジェクトにリスクはつきものです。...プロジェクトマネジメント計画書の重要性プロジェクトを立ち上げた後、プロジェクトの計画を立てます。コメントをキャンセルメールアドレスが公開されることはありません。の”ダーゴ二郎”です。某大手ITベンダーに勤務している、アラフィフの平社員。この業界に勤めて約20年、プロマネを始めて約10年。連載している記事をまとめました。ショートカットできるので、ぜひご利用ください。