プロジェクトを正式に承認し、プロジェクト マネージャーがプロジェクト活動で組織リソースを使用することを承認する文書

プロジェクトマネージャーは、できるだけ早く、できればプロジェクト憲章の作成時に特定され、任命される必要がありますが、遅くとも計画を開始する前に決定される必要があります。

プロジェクト憲章は、スポンサーによって作成される場合もあれば、スポンサー機関と協力してプロジェクト マネージャーによって作成される場合もあります。プロジェクト マネージャーは、プロジェクトをより深く理解するためにプロジェクト憲章の作成に関与する必要があります。

プロジェクト憲章を作成して、プロジェクトが組織の戦略と日常業務のニーズを満たしていることを確認する

ビジネス文書（定期レビュー）

合意（契約）

ビジネス環境要因、組織プロセス資産

専門家の判断

ブレーンストーミング

フォーカスグループ

ガイド

会議の管理

プロジェクト計画書

仮説ログ

包括的なプロジェクト管理計画に統合し結合するプロセス

計画は継続的な更新を通じて徐々に詳細化する必要があり、これらの更新は管理および承認される必要があります

他の計画プロセスから出力されたサブプランとベースライン

プロジェクト計画書

チェックリスト

ガイド

ミーティング：キックオフミーティング 計画段階で最後に行うことです

プロジェクト管理計画

プロジェクト管理計画で特定された作業を実行する

承認された変更を実装するプロセス

プロジェクト管理計画

承認された変更リクエスト

PMISシステム

成果物

仕事のパフォーマンスデータ

問題ログ

変更要求

既存の知識を利用し、新しい知識を生成してプロジェクトの目標を達成し、学習プロセスの整理を支援します。

形式知

暗黙知

教訓登録

知財管理

情報管理

教訓登録

作業パフォーマンス情報を作業パフォーマンスレポートに統合して、関係者がプロジェクトの現在お​​よび将来のステータスを理解できるようにします。

仕事のパフォーマンス情報

コスト予測

進捗予測

代替案の分析

費用便益分析

根本原因分析

収益価値分析

偏差分析

トレンド分析

仕事のパフォーマンスレポート

変更要求

プロジェクト全体を通じて、プロジェクト マネージャーが最終的な責任を負います

誰でも行うことができ、口頭でも行うことができますが、すべての変更リクエストは書面で文書化する必要があります

プロジェクト管理計画または組織手順で変更を承認、延期、または拒否する責任者を指名します (デフォルトは CCB に送信されます)。

ベースラインが確立されるまで、実装統合変更管理プロセスによって変更を正式に管理する必要はありません。 プロジェクトのベースラインが確立されたら、このプロセスを通じて変更リクエストを処理する必要があります。

変更の理由を理解し、不必要な変更を防ぎます。 次のプロセスに従ってください: 1. 記録 2. 評価 3. 提出 (プロジェクト マネージャーが CCB に提出) 4. 更新 5. 通知

変更要求

プロジェクト管理計画

変更管理ツール

承認された変更リクエスト

プロジェクトファイルの更新

ノーマルエンディング

プロジェクトが早期に終了した

1. クローズが完全に完了している場合、リソースの解放はクローズの最後のステップです。 問題や欠陥が発生した場合、プロジェクト マネージャーは運用部門の介入をタイムリーに調整するだけで済みます。顧客が新しい機能を必要とする場合は、新しいプロジェクトを開くことを提案できます。 2. 最後の仕上げが完全に完了していない場合: 問題や欠陥が発生した場合、プロジェクト マネージャーは積極的に対処する必要があり、場合によっては変更プロセスを踏まなければなりません。新しい機能に遭遇した場合、通常は変更プロセスを経る必要があります。 3. 現在のプロジェクトの終了と新しいプロジェクトの開始が同時に発生する場合は、現在のプロジェクトを閉じることを優先します。

プロジェクト計画書

受領のための成果物

組織プロセス資産

契約書、ビジネス文書など

ミーティング

最終製品、サービス、または結果の引き渡し

最終報告書

組織プロセス資産

プロジェクトに適切なガバナンス構造を決定する 問題を報告するためのパスとしきい値を定義する

特定された調査の利点 関連する知識を文書化して、時間の経過とともにメリットを実感できるようにする 効果を追跡するための測定システムを確立するかどうかを確認する 価値を実証するために配信オプションを評価する ステークホルダーの価値獲得の進捗状況を評価する

重要な情報ニーズを特定する データを収集および分析して、情報に基づいたプロジェクトの意思決定を行う 集約されたデータを分析する プロジェクトまたはフェーズ計画を統合する マージ後の計画の依存関係を評価する

変化に対処するための戦略を決定する 変化の必要性を予測し、受け入れる（例：変更管理慣行に従う） 方法論に従って変更管理戦略を実行する 変化に対する対応を決定する

チーム内で責任について話し合う 職場環境に対する期待の概要を説明する 知識の伝達と交換の方法を特定する

プロジェクトの検証と終了の基準 引き継ぎ準備の確認 プロジェクトまたはフェーズを終了するための終了アクティビティを実行する