スケジュール変更をスムーズに行うには

一旦たてたスケジュールを変えるのは難しいことです。特に発注者と合意しているスケジュールを変える場合はなおさらです。
スケジュールを変える一番の動機はそのスケジューではうまくいかない事が分かった時です。それは当然発注者側もそう考えていますので、こちらがスケジュールを変更しようとしたら発注者側の方では「なぜスケジュールを変更するのか」と聞いてくるのは当たり前のことです。そして発注者にしてみると「進捗が遅れてきているからスケジュールを変えようとしているんだな」と勘ぐってきます。　しかし、大抵その感はあたっています。

今のシステム開発では実際にスケジュール通りに作業を進めることの方が難しくなっているので、このような場面にはしょっちゅう出くわします。

このようなスケジュール変更を行わなければならない状況の時に有効なやり方があります。それは「今のやり方で行うとこのようになります」しかし「このようにするとＸＸＸＸがもっとよくなります」という形であくまでもスケジュール変更はプロジェクトにとっていいことなのだ　という形に持って行くことです。

発注者側が嫌うのはスケジュールそのものに問題は無いのに作業のやり方がまずくてスケジュール変更が発生することです。スケジュールそのものを見直すことで作業効率が上がったり、品質がよくなったりするのであればスケジュール変更も積極的に行うべきです。（ただしスケジュール変更にともなう混乱が起こらないような手を別途講じる必要がありますが）

当然いつもこのようにうまく行くわけではありません。多くの場合はこちらの進め方やスケジュールの詰めの甘さで進捗が遅延し再スケジュールになることが多いからです。ここで大事なことは再スケジュールに追い込まれる前に進捗の遅れが出てきた時に手を打つことです。もうひとつ大事なことははっきりしないのに詳細なスケジュールを立てないことです。２ヶ月も３ヶ月も先のことについて詳細になスケジュールを組んでも変わってしまうのが当たり前です。

そもそもプロジェクトが進んでいくことによってはじめて分かってくることが沢山あります。状況が分かってから詳細なスケジュールをたてる。つまり直近のことは詳細に、そしてその先は中粒度にスケジュールを立てて逐次直近のスケジュールを詳細に立てていくことが大事です。

このようにすると詳細なスケジュールを繰り返し立てることになります。これは長期のスケジュールを立てちょこちょこ変更するのと、同じようなものですが発注者側で受ける印象はまったく違います。つまり先にもあげたようにプロジェクトが進むと分かることがありますので、１ヶ月前に立てた来週のスケジュールよりも今立てる来週のスケジュールの方が正確になるし、いろいろな改善も盛り込めます。

このようにスケジュールをコントロールしているように見えるか、スケジュールに追い立てられているように見えるかは大きな違いです。

当然マイルストーンとして長期のスケジュールを別途立てることは必要ですし、その内訳として中粒度のスケジュールも必要です。

このような事もあり私は厳密なＷＢＳよりもマイルストーンと中粒度のスケジュールとタイムボックスを組み合わせたスケジュール管理を好んで使っています。