プロジェクトあるある（８２）

本日のプロジェクトあるある：

「プロジェクトスケジュールを積み上げで作成すると、だいたいお客様の希望納期より長くなる」

プロマネがプロジェクトスケジュールを検討するとき、まずは理想のスケジュールを作成します。

ざっくりいうと以下の3つをプロマネはやります。
　
1.必要なタスクの洗い出し(WBSの作成ですね)
2.各タスクに必要な工数(何人で何日かかるか)
3.各タスクの前後関係の精査(どのタスクがどのタスクの前に終わっておく必要があるかの関係整理)

この作業が完了すると、プロジェクトスケジュールの雛形が完成です。

ここから実際プロジェクトに参加可能な人員の都合を加味してスケジュールを調整するのです。

これだけ聞いたらやる事が決まっていて、機械的に作成できそうな気もしますね。

しかし実際にはそう簡単ではありません。

3つの作業工程どれも頭を使います。

過去のプロジェクトを参考にすることはあってもそのまま使えるということはまずありません。

そうやって作成したスケジュールと言うのは、えてしてお客様の望む納期に納まりません。

そして言われます。　

「もうXヶ月前倒しして欲しいのですが」

お願いのされ方は丁寧だったり申し訳なさそうだったりしますが、どうであっても大体はもはや命令に近い依頼です。

そこでプロマネは提案します。

「スコープを絞りましょう。」

しかしお客様は首を縦にふりません。　

そしてこのお客様の要望に、味方であるはずの自分の会社の営業がお客様に加勢するのです。　

そりゃそうです。決裂して案件がなくなったら売上がなくなりますからね。

そうなるともうなんとかするしかありません。　

PMBOKでおなじみのクラッシングやファストトラッキングを駆使して工期短縮を始めます。

それでも埋まらない。　

予備期間を削ります。

まだ埋まらない。

ついにプロマネは禁断の手に出ます。

土日を稼働時間に盛り込むのです。

そうしてどうにかスケジュールは希望納期に収まりました。

もう計画の段階でプロマネは憂鬱です。

プロマネの皆さんは、最初から逆線表のスケジュールを作成した方が時間短縮になるじゃないかと思われるかもしれませんが、それは違います。

まず自分がプロマネとして確実に成功させるならこれだけのスケジュールが必要という物を見せておく必要があるのです。

その上で期間短縮の検討をし、その場合のリスクを伝えるのです。

そうしないと、最初から(自分が無理だと思っている)スケジュールを合意したとみなされてしまいかねません。

プロジェクト進行に対する責任はプロマネが負います。

だからこそ、自分が無理だと思うことはきちんと主張し、エビデンス(証拠)を残しておく必要があるのです。

ただただ安易に受けてはいけないのです。

それではまた！
日々感謝 m(_ _)m