プロジェクト管理計画で特定されたパフォーマンス目標を達成するために、プロジェクトの進捗状況を追跡、レビュー、報告するプロセス

プロジェクトの作業全体を通して

プロジェクトの現在の状況、実行された手順、予算、スケジュール、範囲の予測を関係者に常に知らせます。

（1） 実際のプロジェクトのパフォーマンスをプロジェクト管理計画と比較する

（2） プロジェクトのパフォーマンスを評価し、是正措置または予防措置が必要かどうかを判断し、必要な措置を推奨します。

（3） 新しいリスクの特定、既存のリスクの分析、追跡および監視、リスクの包括的な特定の確保、リスク状態の報告、および適切なリスク対応計画の実施

（4） プロジェクト製品および関連ドキュメントを反映するために、プロジェクト全体を通じて正確かつ最新の情報ベースを維持します。

（5） 状況報告、進捗状況の測定、予測のための情報を提供する

（6） 予測を作成して現在のコストとスケジュール情報を更新します

（7） 承認された変更の実装を監視する

（8） プロジェクトがプログラムの一部である場合、プロジェクトの進捗状況とステータスもプログラム管理者に報告する必要があります。

入力 入力

ツールとテクニック ツール&テクノロジー

出力 出力

すべての変更要求のレビュー、変更の承認または拒否、成果物、組織プロセス資産、プロジェクト文書、およびプロジェクト管理計画への変更の管理、および変更処理の結果の伝達のプロセス。

プロジェクト全体を通じて、プロジェクトのすべての段階で適用され、プロジェクト マネージャーがこれに対する最終的な責任を負います。

プロジェクトの関係者は誰でも変更リクエストを送信できます。口頭で行うこともできますが、すべての変更リクエストは書面で文書化し、変更管理および構成管理システムに含める必要があります。

文書化された各変更リクエストは、責任者によって承認または拒否される必要があります。この責任者は通常、プロジェクト スポンサーまたはプロジェクト マネージャーであり、プロジェクト管理計画または組織プロセスで指定する必要があります。必要に応じて、変更管理委員会 (CCB) は、全体的な変更管理プロセスを実装するかどうかを決定する必要があります。

文書化されたプロジェクトの変更を統合的な観点から検討することで、プロジェクト全体の目標や計画に対する変更の影響を考慮しないことによるプロジェクトのリスクを軽減します。

プロジェクトの変更をレビュー、評価、承認、延期、または拒否し、変更処理の決定を文書化して伝達する責任を負う、正式に構成されたグループ

全体的な変更管理は、CCB および変更管理システムを通じて実現できます。しかし、全体的な変更管理は CCB だけの問題ではなく、プロジェクト マネージャーやプロジェクト チームの問題でもあります。

CCB は、主要なプロジェクト関係者 (顧客、ユーザー、スポンサー、経営陣、リーダー、マネージャー、プロジェクト マネージャーなど) の代表者で構成されるグループです。プロジェクト マネージャーはメンバーの 1 人になることもできますが、通常はチーム リーダーではありません。 CCB は変更リクエストをレビューし、承認または拒否する責任があります。

プロジェクトの目的に影響を与える可能性のある変更は、実装する前に変更管理委員会 (CCB) の承認を受ける必要があります。CCB の承認後、既に CCB のメンバーである場合を除き、顧客またはスポンサーの承認も必要になる場合があります。

変更管理システムとは、文書、追跡システム、変更承認レベルなどを含む、変更管理のための一連の正式な書面による手順を指します。

構成制御

変更管理

1. 構成の識別

2. 構成ステータスのログ記録

3. 構成の検証と監査

（1） 発生する可能性のある変更と実際に発生した変更を特定する

（2） 承認された変更のみが確実に実装されるようにするための、全体的な変更管理に影響を与える関連要素

（3） 変更リクエストを確認して承認する

（4） 標準化された変更要求プロセスを通じて承認された変更を管理する

（5） ベースラインの完全性を管理して、承認された変更のみがプロジェクトの製品またはサービスに統合されるようにし、変更に関する構成および計画文書を維持します。

（6） 書面によるすべての是正措置および予防措置のレビューと承認

（7） 承認された変更に基づいて、プロジェクトの範囲、コスト、予算、スケジュール、品質要件を管理および更新する 変更は、プロジェクト全体の観点から調整する必要があります。

（8） 変更リクエストによるすべての影響を文書化する

（9） 欠陥修正の正確性を検証する

（10） 品質レポートに基づいてプロジェクトの品質を管理し、標準への準拠を確保します

入力 入力

ツールとテクニック ツール&テクノロジー

出力 出力

すべてのプロジェクト管理プロセス グループのすべてのアクティビティを完了して終了し、プロジェクトまたはプロジェクト フェーズを正式に終了するプロセス

このプロセスには、プロジェクト プロセスのすべてのアクティビティを完了して、プロジェクトまたはフェーズ全体を正式に終了すること、プロジェクトの成果物を顧客または資金提供者と調整して文書化して正式に承認することが含まれます。

クロージングステージの主な管理内容はクロージング管理です。本質は、プロジェクトの管理上の終了を実行することです。プロジェクトを終了する過程では、プロジェクトのスポンサーや顧客からプロジェクトの製品、サービス、結果について最終的な承諾を得る必要もありますが、この承諾は主に必要な手続きであり、実質的な技術的な承諾ではなく、形式的な承諾です。受け入れ。真の技術的承認は、範囲検証プロセスの早い段階で達成されます。

経験と学んだ教訓を要約し、プロジェクト作業を正式に終了し、新しい作業のために組織リソースを解放します。

1. 事務処理の終了 【運営終了】

2. 契約締結

二人の関係

入力 入力

ツールとテクニック ツール&テクノロジー

出力 出力

プロジェクトを終了するとき、プロジェクト マネージャーは、すべてのプロジェクト作業が完了し、プロジェクトの目標が達成されたことを確認するために、前のフェーズの終了情報を確認する必要があります。

プロジェクト マネージャーは、プロジェクトの終了を宣言する前に、スコープ ベースラインを確認してプロジェクト作業が完了していることを確認する必要があります。

プロジェクトが完了前に途中で終了した場合、プロジェクトまたはフェーズのプロセスを終了するには、途中で終了した理由を調査して文書化する手順も必要になります。

プロジェクト マネージャーは、適切な関係者全員をこのプロセスに参加するよう招待する必要があります。