パターン4:スケジュールの期間を決める   

 

問題:

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

コンテキスト:

製品が理解され、プロジェクトの規模が見積もられようとしている。

影響する事柄:

スケジュールを寛大になりすぎて作成すると、開発者は自己満足に陥り、市場でのチャンスを失ってしまう。

もしスケジュールが意欲的すぎると、開発者は燃え尽きてしまい、やっぱり市場でのチャンスを失ってしまう。

もしスケジュールが意欲的すぎると、製品の品質が悪くなり、妥協的なアーキテクチャ上の原理が将来のメンテナンスのための基盤を貧弱なものにしてしまう。

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

解決策:

スケジュールが守れた時には金銭的なボーナス(あるいはリスク保証で;成功を補償するのパターンを参照)あるいは余分な休暇で開発者に報いなさい。2つのスケジュールを用意しなさい。1つは市場に対するもので、もう1つは開発者向けである。外部のスケジュールは顧客と交渉でき、内部のスケジュールは開発者と交渉できる。普通のプロジェクトであれば、内部スケジュールは外部スケジュールよりも2〜3週間短くなければならない(この数字はソフトウエアコンサルティング会社のシニアスタッフによるものである)。もし2つのスケジュールが調停できない時は、顧客の要求あるいは組織のリソース(あるいはスケジュールそのもの)が再交渉されなければならない。

論理的根拠:

MITのプロジェクト管理シミュレーションとQPWで実証されている。あるマネージャーは内部スケジュールと外部スケジュールの差は2週間よりも2ケ月に近いと示唆している。なぜなら、もし進捗が遅れたとしたら、2ケ月から3ケ月のコストが必要になる重大な見落としによる場合が多いからである。