キットＰＭはこの時期は花粉症がそろそろ攻撃を開始するので、毎年体調がすぐれない日が続き、結構つらい思いをします。5月まで続くのでちょっと大変です。
プロジェクトにおけるバッファについて考えています。前回は、プロジェクト・バッファがどの様な考えから成り立つのかを考えていきました。
プロジェクトに沢山あるタスクに散らばっている余裕を、各作業担当者から取り上げて、その余裕をプロジェクト工程の一番最後に配置することで、プロジェクトを期間オーバーのリスクから保護するわけです。
ことき、「取り上げる余裕 ＝ 余裕込の工期 － 集中してやれば完了可能な工期」 となります。「集中してやれば完了可能」が分かりにくいと思いますが、別の表現をすると「50%の確率で完了可能な工期」となります。つまり、完了の可能性が半分あることになります。
したがって、取り上げた余裕の全てをプロジェクト・バッファに回す必要がなく
バッファのサイズを小さくすることが可能になるという、素晴らし利点があることもお伝えしました。
従来型のプロジェクト手法である「ウォーターフォール型プロジェクトでは」実際にこの考え方で、プロジェクトの工期を大幅に短縮することができます。これには多くの事例があり、有効な手法と認知されています。
ただ、スクラムのようなアジャイル型のプロジェクトでのプロジェクト・バッファの適切なあり方については、まだ研究の余地があるようです。これについては、別の機会に研究してみようと考えています。
さて、プロジェクト・バッファを使ったプロジェクトマネジメントでは、進捗管理をどのような観点で行うのでしょうか。
通常、プロジェクトの進捗管理は予定工期との差をタスク毎に管理します。その時、特に注視するのがクリティカルパスという、最も影響の大きいタスクの繫がりとなります。それは、ここに含まれるタスクに進捗の遅れが発生すると、プロジェクト全体が遅れるためです。
バッファマネジメントを行う場合、進捗の状況はプロジェクト・バッファの消化具合で測ります。
バッファが充分にある場合シグナルはグリーンで、当たり前ですが特にプロジェクトに介入して何かをする必要がありません。
バッファが消化され始めたときシグナルはイエローですが、この時もまだ具体的な対策を講じるための行動はおこないません。これは、そもそもバッファは消費されるものであるという前提なのと、作業の進捗によってはバッファが回復する場合があるからです。でも、問題が発生しているという認識を持つことと、監視の度合いを強めるのは必要です。
さらにバッファが消化され、最終的な期限に影響が出る可能性があるときシグナルはレッドで、遅延している問題を解決する行動を起こします。
この考え方の利点は、マネージャの意識をどこに集中するかをシンプルにコントロールできるところにあります。ひっくり返して言うと、マネージャが本来必要のない所にパワーを使わず、必要なことに注力することが重要だという考えとなります。
一つ注意しないといけないのは、バッファの消化量は単純に割合で求められないことです。３０％だとグリーン、６０％だとイエロー、それ以上だとレッドとはなりません。プロジェクトのライフサイクルのどこで問題が発生しているかの、タイミングを考慮する必要があるからです。
つまり、プロジェクト初期のころのバッファの消化はその後の工程で、リカバリーされる可能性を含んでいます。しかし、プロジェクト終盤でのバッファ消化は、問題解決が手遅れになる危険性が大きくります。バッファの監視は、このタイミングという要素を考慮して行う必要があります。
次回はプロジェクトバッファ以外の、期間を守るためのバッファについて、考えて行きます。