プロジェクト・タイム・マネジメント

納期が最優先となるプロジェクトも多く、重要なファクターである。
コストが超過しても、機能を一部先送りしても、
期日通りにシステムを稼働させることが多い。
※でも、こうならないようにするのがマネジメントの役目。。
納期を順守できるようなスケジュールを作成し、
これに沿って、計画通り進めていくことが必要。

＜計画＞
・アクティビティ定義
　WBSの最下層の作業を、さらに小さい「アクティビティ」という単位に分解。
　　基本設計＞○○画面、△△画面、…

・アクティビティ順序設定
　アクティビティ間で守らなければならない順序を確認し、設定する。
　テーブル構造やインタフェースを先に作成してから、業務ロジックの設計を行うなど。
　効率よく作業し、手戻りを減らすため。

・アクティビティ資源見積もり
　アクティビティ実行のために、どんな資源が必要かを見積もる。
　どんなスキルを持った人をアサインするか。
　また、各作業に対して、誰が責任を持つかもここで決めておく。（→責任分担マトリックス）
　要員を積み上げ、ヒスとグラムや要員表を作成する。
　検討するのは人だけではなく、それ以外も。
　人はいるけど開発端末がない、座る場所がない、では開発が進まない。

・アクティビティ所要期間見積もり
　各アクティビティに、どれだけの期間をかけるか決める。
　資源見積もりでアサインした人が、成果物を作るのにどれくらいの期間がかかるかを見積もる。

・スケジュール作成
　これが、よく見る「スケジュール」。
　資源と所要期間より、各アクティビティの予定開始日と予定終了日を決める。
　アクティビティを完了させるために、必要な要員を割り当てる。（これが「個人のスケジュール」となる）
　ガントチャートにするとわかりやすい。
　要員の稼働状況に注意。（作業過多だと、予定通りいかなくなる可能性が高い。）
　また、クリティカルパス（作業を進める上で、日程的に余裕がなく、遅れることのできない経路）を、ここで把握する。
　マイルストーン（プロジェクトの重要イベント）を決める。
　例：プログラム製造の発注日など。ここまでに設計を終わらせる必要がある＝ここを目がけて進む、という意識を生み出すことができる

＜監視・コントロール＞
・スケジュール・コントロール
　変更要求に基づき、スケジュールを変更する。
　※安易なスケジュール変更はできない。
　　変更する場合、変更管理の手続きをとってから、初めて変更を行う。
　また、進捗の把握と是正を行う。
　クリティカルパス、もしくはそれに近い日程を重点的に監視し、
　遅れの傾向が見えたら、すぐ対策を検討する。