プロジェクト憲章って誰が作成していますか？

プロジェクトを立ち上げる際に一番最初に取り掛かる作業です。
作成するのはプロジェクトオーナーやスポンサーなので、実はプロジェクトマネジャーが作るものではありません。自社製品を作るような組織であればビジネスとしていけると判断したところでプロジェクト憲章を作成します。つまり、さぁプロジェクトを始めようといっていきなりプロジェクト憲章を作成するのではありませんね。
上流工程としてニーズの掘り起こしや提供する価値の見極めができているので、それをお金を出してくれる経営陣やステークホルダーに承認してもらうための成果物です。ビジネスアナリストの役割としてすでに作業が進んでいるはずです。
プロジェクトマネージャーはプロジェクト憲章のなかでアサインされます。とはいえ、大きくない組織や、そもそも組織体制が弱いような会社では代理で作成することになりますね。

プロジェクト憲章作成のプロセス

インプットから作業範囲記述書やビジネス・ケースといったものがある通り、ビジネスとしての判断材料がある程度進んでいるわけですね。もしこういったインプットが無い状態からプロジェクトを始めることになってしまった場合は作るしかありませんね

一般的には以下の内容を記載しましょうと言われています。

プロジェクト・エグゼクティブ・サマリー

本題で説明する内容をかみ砕き、要点だけを書きます。ビジネスでは結論から説明し、相手が興味を持ったら、さらに詳細を説明するのが鉄則。まずは決裁者に興味を持ってもらうことが先決です。概要・目標・スコープ・前提条件・リスク・コスト・アプローチといった内容のハイレベルの説明を記述します。そして、このあとに詳細が続いてきます。

プロジェクトの概要

プロジェクトの背景と状況、なぜこのプロジェクトを着手するのか、実行される作業のビジネス価値を明記します。

プロジェクトの目標

プロジェクトが何を達成し、どういった価値を提供するのかを記載します。目標の作り方にはSMARTの法則というのがあります。
S pecific　 ＝　具体的、わかりやすい
M easurable　 ＝　計測可能、数字になっている
A greed　upon　＝　同意して、達成可能な
R ealistic　 ＝　現実的で結果志向
T imely　 ＝　期限が明確

プロジェクト・スコープ

プロジェクトの境界を明確に定義します。
スコープの内・外に属する要素成果物のタイプ （ビジネス要件、現状評価）
スコープの内・外に属する主要なライフサイクル・プロセス （分析、設計、テスト）
スコープの内・外に属するデータのタイプ（財務、売上、従業員）
スコープの内・外に属するデータ源（またはデータベース）（請求書、総勘定元帳、給与）
スコープの内・外に属する組織（人事、製造、ベンダー）
スコープの内・外に属する主要な機能性 （意思決定支援、データ入力、管理報告）

プロジェクトの成果物

プロジェクトの活動でどのような成果物が生成されるかを明記する。マニュアルやインターフェース記述などなど。

影響を受ける組織

影響を受ける部門、プロジェクトに参加する部門やグループを特定ます。影響内容を明らかにし、適切なコミュニケーションを図るようにします。

プロジェクトの見積もり

スケジュールの概要
* プロジェクトを遂行する上での前提条件・制約条件
* プロジェクト承認要件
* 任命されたプロジェクト・マネジャーの氏名、責任、権限の範囲
* プロジェクト憲章を承認した人、あるいはスポンサー

プロジェクト憲章を作成する意義

結局のところ、経営陣やステークホルダーから認められるために作成するわけですので、そういった判断が出来る内容であるべきでしょう。
ニーズに対して提供する価値、それをする意義、財務指標がないと判断できませんよね。

あと、降って湧いてきたようなプロジェクトだと、要求と手段を間違えていることがあります。
たとえば「倉庫の入出庫管理システム」を作れという内容。
入出庫管理システムを作ることが命題となってしまっていて、手段を実現するための手段をマネジメントしていくとハマります。この部品とあの部品が組み合わさって仮置き場に行くだの、組み合わさるパターンに条件があるだの、現場に納入したら運用と合わないといった事態に遭遇するのはよくあるパターンです。
入出庫管理システムという頭で取り組んでしまうため、あとから湧いてくる細かい仕様にパンクしてしまいます。
倉庫にある棚や置き場に対する受け入れや払い出しといった部分に注目してシステムを作ってしまうと、いろいろな制約条件がシステムに入れ込みにくくなってしまいます。
本当にやりたかったのは部材のトレーサビリティーです。部材のライフサイクルを管理したいというのがニーズなわけで、入出庫監視システムを作ることがニーズではありませんよね。
プロジェクトの上流工程で間違いを起こしてしまうと、後工程では何ともなりません。そういった意味でもプロジェクトのスタートはとても大事です。