#2-15　「プロジェクト憲章」の作成と承認

前々回、前回に続いて、今回もプロジェクト憲章の作成についてです。

今回は、プロマネのセオリー的な「プロジェクト憲章」の内容についてです。

「プロジェクト憲章の作成」など、『PM BOK』の用語に関する話は、プロジェクトマネジメントのグランドセオリーとしての話、という認識でいただければと思います。
そういった内容の説明をする際には、「プロマネのセオリー的には」みたいな表現を添えていく予定です。

「プロジェクト憲章」とは

プロマネのセオリー的には、プロジェクトの存在や立上げを承認する文書のことです。プロジェクト全体の運営方針をガイドする役割もあります。

承認されると、プロジェクト活動のためのリソース（お金）が使えるようになります。

元々は、スポンサー（会社の経営層など）が作成して、プロジェクトマネージャー（PM）候補者に「業務指示書」として渡す、という形式が多かったそうですが、
最近は、スポンサーの意向を反映したPMが作成して、スポンサーが承認する、という形が多いようです。

プロジェクト憲章の内容

「プロジェクト憲章」の内容に関しては、会社ごとに決まりがありますが、プロマネのセオリー的にはいくつかの項目が挙げられています。

　・目的
　・測定可能なプロジェクト目標と成功基準
　・ハイレベル（※）な要求事項
※ハイレベル：「難しいレベル」という意味ではなく、「高いところから俯瞰する」という意味です。ざっくり定義、というニュアンスです。
　・全体的なリスク
　・要約マイルストーン・スケジュール
　・承認された財源（予算）
　・主要ステークホルダーのリスト
　・プロジェクト承認要求事項とプロジェクト終了基準
　・任命されたプロジェクトマネージャーの氏名、責任、権限レベル
　・プロジェクト憲章を認可するスポンサー

経験上、私は開発領域で分けた主要プロジェクトメンバーの構成図も作ることも多いです。

前提条件と制約条件

「プロジェクト憲章」作成時には「前提条件ログ」を作成して、プロジェクト活動の際には、前提条件と制約条件の両方を管理していく必要があります。プロジェクトの活動の過程で変化した場合は、「前提条件ログ」に記載していた内容を更新します。
（「プロジェクト憲章」の記載項目の中に前提条件と制約条件の項目を設ける場合もあります）

前提条件
「前提条件」とは、プロジェクト憲章作成時や計画時に、証拠や実証はなくても、確実にあるだろうとみなした要因のことを指します。
そもそも、プロジェクトは不確実性が伴うので、計画時にすべての要素を確定することは出来ません。

例えば、材料を契約実績のある会社から納入出来る、といった条件です。

この前提条件は、取引先の会社の倒産や、天変地異などで覆る可能性がありますし、必ず実現するという保障はないです。しかし、プロジェクトに必要で、発生する確率が高いものを前提条件として、プロジェクトの計画を立てます。

制約条件
「制約条件」とは、カネ・ヒト・モノ・時間などの制約のことです。
ビジネスとして成功するためには、無尽蔵にそういったリソースを使用することは出来ません。プロジェクトの活動に影響を与える制限要素ですが、認識しておく必要はあるので、「前提条件ログ」に明記しておきます。

プロジェクト憲章の承認

プロジェクト憲章がスポンサー（会社の経営層）に認可されたら、PMは正式に任命され、プロジェクト・マネジメントを本格的にスタートします。

勿論、全ての「プロジェクト憲章」が承認されるわけではなく、プロジェクトの承認が得られないこともあります。
承認されない理由は、コストの問題や実現の可能性が低そう、というケースが多いです。
そういう場合は、プロジェクトの全てではなく、一部のフェーズの切り出したスモールプロジェクトの承認のみ得る、という形もあります。

最初のフェーズの目的や成功基準など、「プロジェクト憲章」的な要素を明確にして、最初のフェーズの開発を進めます。そして、フェーズの終わりの成果物で、全プロジェクトの承認を得られないかの判断をしてもらいます。

大規模なプロジェクトになるほどリスクが大きいので、このようにスモールプロジェクト化してリスク分散をするという形が有効です。