パターン38:小さなスケジュール変更をするな

   

 

問題:

プロジェクトはどのくらいの期間になるのか?

コンテキスト:

製品を開発しており、進捗管理が絶対に必要である。

影響する事柄:

長すぎると、開発者は自己満足に陥り、市場でのチャンスを失ってしまう。

短すぎると、開発者は燃え尽きてしまい、やっぱり市場でのチャンスを失ってしまう。

スケジュールによる動機がないプロジェクトは永遠に続くか、見当違いあるいは顧客の要求に役に立たないような枝葉末節を磨くために時間を費やしすぎる。

解決策:

「我々は、“人月の神話”から、小さなスケジュール変更をするなによってうまくやっていく方法を見つけた。毎週、クリティカルパス(最低限)の実績が、計画にどれだけ近いかどうかを計測しなさい。もし3日間の遅れなら、3日間の“幻の索引”を追跡しなさい。もし幻の索引がばかばかしすぎるようになったら、スケジュールをずらしなさい。これは、スケジュールをかき回すのを避けるのに役立つ。」・・・ 1994年6月のPaul Chisholmとの個人的なディスカスから。

結果として生じるコンテキスト:

プロジェクトは、柔軟な目標日を持つようになる。目標日を見積もるのはいつもむずかしい。DeMarcoは、トラブルでの最も重大な問題の兆候は、最終日から逆算されたスケジュールである、といっている [DeMarco]。

論理的根拠:

MITでのプロジェクトマネージメントシミュレーションとQPWで実証されている。[Brooks]も参照してください。ほとんどの分別のあるプロジェクトで、このように運用されている。