なぜプロジェクトマネジメントが機能しないのか 26 プロジェクトバッファ

日本で最初の民間シンクタンクで、プロジェクトマネジメントのコンサルタントとして、ある時はＰМ、ある時はＰМОとして、お客様と問題解決に取り組んでいます。本記事では、まだＰМＢОＫには書かれていない暗黙知を言語化し、形式知としてお伝えすることにチャレンジしてみようと思います。
マガジン：https://note.com/think_think_ab/m/m0e070db46016

TOCとCCPM

本記事の第２５回まで、
プロジェクトマネジメントの目的を
不確実性の早期排除（＝リスクの早期顕在化）とし、

不確実性を、
ＱＣＤバランスを脅かすもの と具体的にしたうえで、
プロジェクトマネジメントの各プロセスを紐づけて説明してきました。

・ＷＢＳ：スコープの全量性の確保 → 抜け漏れ余地（不確実性）の排除
　　　　　タスクトレース → ウィークリンク（不確実性）の早期検知
・ファストトラッキング：リスク（不確実性）の早期検知
・進捗管理：進捗遅延（不確実性）の早期検知
・課題管理：課題（不確実性）の早期解決

これらのプロセスは、不確実性の早期排除 に貢献してこそ、
プロジェクトマネジメントは正しく機能します。

一方、
ＰＭＢＯＫに形式知化されたためか、あまりに自明すぎて、
各プロセスの目的や意味を問うことなく、意識することなく、
漫然とやっていては、プロジェクトマネジメントは正しく機能しません。

さて、
こうした 不確実性の早期排除 を補完する理論と方法論として
以下の２つはご存知でしょうか。

・ＴОＣ（Theory of Constraints、制約理論）
・クリティカル・チェーン・プロジェクト・マネジメント
　　　　（Critical Chain Project Management、CCPM）

ＴОＣは、
イスラエルの物理学者ゴールドラット氏（2011年没）による
全体最適のマネジメント理論で、

ＣＣＰМは、
その考え方をプロジェクトマネジメントに応用した管理手法です。

ここで紹介するのはＣＣＰМのプロジェクトバッファという考え方です。

一般的なスケジューリングでは、
各担当者が担当タスクに個別にバッファ（タスクバッファ）を見込んで
ＷＢＳを作成しますが、ＣＣＰМではタスクバッファを許容しません。

ＣＣＰМでは、
タスクバッファは、それぞれの担当者の範囲で消化されてしまうため、
各担当者からタスクバッファを奪い、プロジェクトの一番最後に集め、
プロジェクト全体のプロジェクトバッファとします。

余談ですが、
ＣＣＰМには担当者とマネージャーの高いレベルでの信頼関係が必要です。

なぜならば、
担当者は全タスクについて最短のリードタイムを提示することになるため、心理的な余裕がなくなります。遅延があっても対応は担当者に押し付けず、
プロジェクト全体で対応するという、担当者のマネジメントに対する信頼が
なければCCPMは成立しません。

プロジェクトバッファ

ただ、実際のプロジェクトでは、
プロジェクトの最後に、例えば１ヶ月程度をプロジェクト全体の予備日を
置くことが許容される場合もあるので、積極的にプロジェクトバッファを
確保しにいくことをお勧めします。

プロジェクトバッファを確保する
一番敷居が低いやり方は、まわりの意見を聞く前に、
プロジェクトマネージャーが一番最初に工程を引く際に、最初から
プロジェクトバッファとして、予備日を定義してしまうことです。

さらに、
最初に前述のように、
先にプロジェクトバッファを置いてしまうと、
各タスクから、自然とバッファがでてきますし、何よりも、
不確実性の早期排除 とのプロジェクトマネジメントの目的にも貢献します。

実は、
プロジェクト後半で、
リスクが顕在化した際にもっとも調達しにくいリソースがあります。

それは、「時間」です。

Ｑ（スコープ）やＣ（要員リソース）の調整判断に比べ、
Ｄ（納期）は調整関係者が多く、調整できない場合がほとんどです。

納期が厳しく、難しいプロジェクトであるほど、
プロジェクトバッファがプロジェクトを助けてくれる時が必ず訪れます。

次の記事（２７回）
↓