プロジェクトマネジメント計画書は、プロジェクトマネジメント計画書作成のアウトプットです。

ちなみに、
プロジェクトマネジメント計画書更新版は、沢山のプロセス（*）がアウトプットしてます。

（*）沢山のプロセス：
・実行プロセス群、
・監視コントロールプロセス群、
・あと、ちょぼちょぼ

ちなみに更新版というのは初版に修正や加筆されたものです。

プロジェクトマネジメント計画書をインプットにしているプロジェクトマネジメント・プロセスは、これも沢山(*)。

(*)これも沢山：
・各知識エリアの先頭プロセス
・プロジェクト作業の指揮・マネジメント
・監視・コントロール・プロセス群
・終結プロセス群

さて、そんなことより、
プロジェクトマネジメント計画書の構成を押さえておいてください。
簡単なので。

・変更マネジメント計画書
・コンフィギュレーション・マネジメント計画書
・９つの知識エリアの計画書（*）
・３つ（スコープ、スケジュール、コスト）のベースライン（＝PMB：　Performace Measurement BaseLine）
以上

（*）９つの知識エリアのマネジメント計画書：
スコープと、品質には２つあるので、全部で１１。

それぞれの知識エリアのマネジメント計画書の中身については、それぞれの知識エリアに譲るとして、

変更マネジメント計画書と、コンフィギュレーション・マネジメント計画書は、簡単に見ておきましょう。

変更マネジメント計画書は、
プロジェクトには付きものの、変更の取り扱いについての取り決めです。
変更が起きてから、変更の取り扱いを話し合うと１００％揉めます。
変更したい人と変更したくない人がいるからです。(*)

変更した人と変更したくない人(*)：
厳密に言うと、変更したい人というのは、タダで変更させたい人のことであり、変更したくない人も、「金くれるんならやるよ」と言う人です。

何が変更になるかを、予測することは困難ですが、プロジェクトで変更が起きるということは分かっています。

だったら、変更の扱い方は予め決めることができます。
実際に変更が発生していないので、比較的簡単に決めることができるわけです。

そうすれば、実際に変更が起きた時には、その決めた扱い方に基いて処理すればいいだけです。

事が起きてから考えるのではなく、事が起きる前にルールを決める。
こういうのがプロアクティブ、先手必勝です。

さて、
内容としては、変更窓口の一本化とか、変更起案フォーマットだとか、承認ルートとかになります。

コンフィギュレーション・マネジメント計画書は、構成管理のやり方です。
変更マネジメント計画書ともリンクするんですが、多数の部分の組合せからなる成果物や、文書なども含む付帯物について、すべてを矛盾がないようにマネジメントすることは、実は簡単ではありません。
ルール作りと、その定着が肝（きも）になります。
そのためのガイドラインです。

で、最後はプロジェクトマネジメント計画書そのもの。
全体の計画の方針であるとか、テーラリングの結果であるとか、用語の統一や、フォーマットなどの形式的なものまで。
各知識エリアの計画の指針となるようなものです。