担当者ごとの予定はあっても、何を変えるときに誰へ相談すべきかが不明なことがあります。
プロジェクト計画(Project plan)は、目的と範囲、日程、費用、資源、品質、変更の扱いなど、実行と管理の方針をまとめた計画です。
詳細な書式は組織や案件によって異なります。

合意すべき前提を記す

たとえば、会員サービスへ新しい申込み方法を導入する場合、開発だけでなく、問い合わせ対応、既存会員への説明、移行も必要になります。
対象となる利用者、提供する範囲、受け入れ条件、判断する担当をそろえます。
開始日が固定されているなら、その理由と、調整できる範囲も明記します。
計画の読み手が同じ条件で判断できることが、文書を作る目的です。

日程表だけでは足りない情報

誰が何をいつ行うかに加え、承認の方法、問題の共有先、計画を変える条件を示します。
申込み方法の例なら、審査で追加確認が必要になった場合、機能の範囲を変えるか、公開日を動かすかを誰が決めるかを整理します。
外部サービスへ依存する部分には、確認済みの条件と仮定を分けて記録します。
図や表を用いる場合も、計画の版と基準日がわかるようにします。

計画を変更するとき

新しい情報で前提が変われば、残る仕事への影響を確認し、必要な承認を得て更新します。
元の計画を黙って上書きすると、何が変わったかを関係者が比較できなくなります。
変更理由、影響、決定者、次の確認時点を残します。
変化を認めない計画と、何でも無条件に受け入れる計画の間に、明確な変更の手順を置きます。

詳細がまだ決められない仕事は、調査と見直しの時点を計画します。
不確実さを隠して予定を埋めるより、どの情報が必要かを示したほうが、次の判断へつながります。
作業計画は日々の実行を具体化し、リソース計画は必要な人員や設備を扱います。
計画を作った後の観察と調整はプロジェクト管理も参照してください。

参考資料