プロジェクト・タイム・マネジメント
納期が最優先となるプロジェクトも多く、重要なファクターである。
コストが超過しても、機能を一部先送りしても、
期日通りにシステムを稼働させることが多い。
※でも、こうならないようにするのがマネジメントの役目。。
納期を順守できるようなスケジュールを作成し、
これに沿って、計画通り進めていくことが必要。
<計画>
・アクティビティ定義
WBSの最下層の作業を、さらに小さい「アクティビティ」という単位に分解。
基本設計>○○画面、△△画面、…
・アクティビティ順序設定
アクティビティ間で守らなければならない順序を確認し、設定する。
テーブル構造やインタフェースを先に作成してから、業務ロジックの設計を行うなど。
効率よく作業し、手戻りを減らすため。
・アクティビティ資源見積もり
アクティビティ実行のために、どんな資源が必要かを見積もる。
どんなスキルを持った人をアサインするか。
また、各作業に対して、誰が責任を持つかもここで決めておく。(→責任分担マトリックス)
要員を積み上げ、ヒスとグラムや要員表を作成する。
検討するのは人だけではなく、それ以外も。
人はいるけど開発端末がない、座る場所がない、では開発が進まない。
・アクティビティ所要期間見積もり
各アクティビティに、どれだけの期間をかけるか決める。
資源見積もりでアサインした人が、成果物を作るのにどれくらいの期間がかかるかを見積もる。
・スケジュール作成
これが、よく見る「スケジュール」。
資源と所要期間より、各アクティビティの予定開始日と予定終了日を決める。
アクティビティを完了させるために、必要な要員を割り当てる。(これが「個人のスケジュール」となる)
ガントチャートにするとわかりやすい。
要員の稼働状況に注意。(作業過多だと、予定通りいかなくなる可能性が高い。)
また、クリティカルパス(作業を進める上で、日程的に余裕がなく、遅れることのできない経路)を、ここで把握する。
マイルストーン(プロジェクトの重要イベント)を決める。
例:プログラム製造の発注日など。ここまでに設計を終わらせる必要がある=ここを目がけて進む、という意識を生み出すことができる
<監視・コントロール>
・スケジュール・コントロール
変更要求に基づき、スケジュールを変更する。
※安易なスケジュール変更はできない。
変更する場合、変更管理の手続きをとってから、初めて変更を行う。
また、進捗の把握と是正を行う。
クリティカルパス、もしくはそれに近い日程を重点的に監視し、
遅れの傾向が見えたら、すぐ対策を検討する。