余裕のよっちゃん

   

また別の日、自分の席にあるプロジェクトのPMが来られ、相談を受けました。

 

PM:「助けてほしんだけど。」

 

A:「どうしたんですか?何でしょう?」

 

PM:「この間、システム部門長に呼び出され、私がPMをやっているプロジェクトの説明を求められたんだよ。内容的には特に指摘されなかったんだけど、スケジュールが長すぎる、縮めろって言われたんだよね。」

 

A:「なるほど、縮められるんですか?」

 

PM:「無茶だよ。当初は余裕あるスケジュールを引いていたんだけど、計画立案当初にもシステム部門長にチェックされて縮めろと言われたので、余裕を削っちゃってる状態なんだよ。」

 

A:「えっ?!遅延が許されないカツカツのスケジュールということですか?」

 

PM:「そう、遅延したら残業または休日出勤でしのぐしかないよ。連日の徹夜かな。。。」

 

A:「そのことはシステム部門長は把握されているのですか?」

 

PM:「言えるわけないじゃん!」

 

A:「...。で、私への相談とは何でしょうか?」

 

PM:「スケジュールを引くときのルールを作って欲しいんだよ。プロジェクトの規模やプロジェクト属性に応じてどの程度余裕を見るべきかとか。」

 

A:「あ~、なんとなく意図が伝わりましたよ。組織としてプロジェクトスケジュールのバッファを認めるルールを作るってことですかね。要するに言いにくいことを私にルールとして決めろってことですねw」

 

PM:「そうそう!そういうこと!さすが話が早いな!」

 

A:「え”ぇ~。。。もぉ”〜。。。」

 

 

特別チームを招集し、下記のようにまとめてシステム部門の上位会議体に付議して承認をもらいました。

 

バッファとは、システム開発を行っていると顕在化する問題への対応のために設ける予備期間のことを指す。

バッファは、各作業工程毎に組み込むのではなく、一か所に集めて一元管理する。

バッファはプロジェクトメンバー、作業者には見せないものとする。

過去の完了プロジェクトの実績を考慮し、下記基準でスタートしてみました。

 

難しいことは考えず、まずはやってみて、微修正というスタイルを取りました。

 

■スケジュール工期が3か月未満の場合

 工期の20%をバッファとする。

 

■スケジュール工期が3か月以上~6か月未満の場合

 工期の25%をバッファとする。

 

■スケジュール工期が6か月以上の場合

 工期の30%をバッファとする。

 

各プロジェクト毎にバッファ日数を算出し、かつバッファの使用状況を見える化して管理することにしました。

 

 

見える化してどうなるか?についてですが、以下の2つのケースの場合、どちらが危険なプロジェクトだと思われますか?

 

①スケジュールの前半でバッファを食いつぶしているプロジェクト
②スケジュールの後半でバッファを食いつぶしているプロジェクト

 

当然が危険プロジェクトですよね。

 

高度な知識も無いので、安直すぎる考え方かもしれませんが、

 

安直すぎる考え方であるが故に、現場への浸透、受け入れられ具合は良かったです。

 

ポイント

繰り返しますが、ルールは組織に認めてもらい、組織のルールとすることが重要です。
ローカルルールは無意味です。
スケジュール工期が3か月未満の場合、工期の20%をバッファとする。
スケジュール工期が3か月以上~6か月未満の場合、工期の25%をバッファとする。
スケジュール工期が6か月以上の場合、工期の30%をバッファとする。
バッファを設けたら、バッファの使用状況も見える化すること。

 - プロジェクトマネジメント, プロジェクト管理