スケジュール変更、リスケはダメと言われたら


プロジェクトの当初スケジュールを提示後に進めてみたら想定と違うことが起きるとスケジュール変更、リスケをしないとこのままでは終われないう状況はまま起きるものです。またそういうときに限って、顧客に打診をしたりその可能性を知りたくて囁いてみると「ダメ」と一刀両断されることもあります。


プロジェクトのスケジュール変更、リスケの打診に対してNGを出してくる顧客はなぜNGを出すのでしょうか。それは簡単なことで顧客の担当がその顧客の中でスケジュールをコミットしているからなんですね。そう、とっても当たり前な理由だったりします。顧客の担当者だって顧客の組織の中で担当するプロジェクトのマネジメントを任されているのですからそのプロジェクトが遅延したり開放時の品質が利用に値しなければ公開処刑されるのは目に浮かびますから。


とは言え、何らかプロジェクトでの事情があり、まったくもってスケジュール変更やリスケがダメなのかというとその可能性は0%ではないと思いますし、結論から言えば、

「当初スケジュールは変えられるものと変えられないものがある」


なのです。全部が全部変えられないわけでもないし、何でも変えられるわけでもないし。


スケジュールで変えられないもの
スケジュールで変えられるものと変えられないものとあると言いましたが、何が変えられて何を変えられないかのあたりを付ける、想像することは顧客のマスタースケジュールをよくよく見るとそれが何なのか想像できたります。

マイルストーンが別プロジェクトとのイベントか
エンドユーザへのイベントか


そう、他のプロジェクトや外部組織やエンドユーザ、特に組織内部のユーザへの開放のマイルストーンがあって、そのイベントを後ろにずらすことでプロジェクトの顧客の担当者の顔をつぶすことになる場合はまずスケジュールの変更は受けれてもらえません。


そのマイルストーンが他のプロジェクトとの接続試験だったりすると、それに間に合わせられなければ先方は待ちになってしまい最悪他のプロジェクトのSIerの待ちのコストを負担しなければならなくなったりします。


エンドユーザへの開放が遅れると、それまでの開放日に向けて準備してきたサポート部隊はもちろんのこと実際に利用するエンドユーザのシステムへの評価はマイナスからスタートすることになり、のちのち辛い思いをするものです。


スケジュールで変えられるもの
逆にスケジュールで変えられるものは、そうしたマイルストーンの間にある工程の局面の長さを変更することは割と出来るものです。良くやる手は、次のマイルストーンまでの範囲で工程の終了を伸ばすとか追加工程を工程とマイルストーンの間に差し込んでしまう手です。あとは、アウトプットを次工程に申し送りするというのもありますが、先がつらくなるだけなので程度の問題はついて回りますね。


とは言え、そうしたスケジュールを勝手に変更することは顧客から見たら不信感を買う以外ない行為ですから、

スケジュール変更をすることになった理由
それに応じた対策と結果
スケジュール変更をして遣りきれる根拠
スケジュール変更をした場合のリスクと対策


こうした顧客の担当が理解でき、同意できるロジックを準備しておき、顧客の担当からプロジェクトの進捗に不安を持たれる前に先手を打って申し入れすることが受け入れやすい環境を作る手でもあります。


そのためにも、スケジュールは意味のあるスケジュールに変えなければなりません。スケジュールを変更するには変更する根拠が必要です。そしてその変更するスケジュールでゴーとなったら期待する実績が確認できるまで子細な作業でも確認の取りこぼしがないようにウォッチしなければなりません。そうした意味のあるスケジュールを現実にやり遂げるためにはやれることはなんでもやらないといけないです。


どっちにしても、スケジュール変更やリスケはそうそう出来るモノでもないし、チャンスもないので相応の覚悟が必要なことには変わりありません。