Wondershare EdrawMind
マインドマップギャラリー システムインテグレーションプロジェクトマネジメントエンジニア 第3版ソフト試験中期 第13章 監視プロセスグループ
- 3
システムインテグレーションプロジェクトマネジメントエンジニア 第3版ソフト試験中期 第13章 監視プロセスグループ
システムインテグレーションプロジェクトマネジメントエンジニア 第3版/ソフトテスト中期/第13章 監視プロセスグループ。モニタリングプロセスグループは、プロジェクトの実行をモニタリングし、必要に応じて是正措置を講じ、必要な計画変更を特定し、対応する変更手順を開始するなど、12のプロセスで構成されます。
2024-03-13 04:27:54 に編集されました
- おすすめ
- アウトライン
監視プロセスグループ
まとめ
モニタリングプロセスグループは、プロジェクトの実行をモニタリングし、必要に応じて是正措置を講じ、必要な計画変更を特定し、対応する変更手順を開始するなど、12のプロセスで構成されます。
プロセス間には相互作用があり、作業は並行して実行されます。監督とは、プロジェクトのパフォーマンスデータの収集、パフォーマンス指標の計算、パフォーマンス情報の報告と配布です。管理とは、実際のパフォーマンスと計画されたパフォーマンスを比較し、逸脱を分析し、プロセスを改善する傾向を評価し、代替案を評価し、必要な是正措置を推奨することです。
このプロセス グループの目的は、プロジェクトのパフォーマンスを定期的に監視および測定して、実際の状況とプロジェクト管理計画との乖離を迅速に認識し、発生する可能性がある予想される問題の予防策を開発し、変更を制御することです。
監視・制御プロセスグループは、特定のプロセスグループの進行中の作業を監視・制御するだけでなく、プロジェクト全体の結果も監視・制御します。
継続的なモニタリングにより、プロジェクト チームやその他の関係者はプロジェクトの健全性を洞察し、追加の注意が必要な領域を特定できます。監視プロセス グループでは、各知識領域、各プロセス グループ、各ライフ サイクル フェーズ、およびプロジェクト全体で行われている作業を監視および制御する必要があります。
11種類の作業が必要
1. 実行と計画を比較し、プロジェクトのパフォーマンス (スコープ パフォーマンス、スケジュール パフォーマンス、コスト パフォーマンス、品質パフォーマンスを含む) を分析し、パフォーマンスの偏差を特定して定量化します。
2. 逸脱の範囲と原因を分析し、将来のパフォーマンスを予測します。
3. 分析と予測の結果 (管理しきい値を超えた場合) に基づいて、修正措置、欠陥修復の推奨事項、計画変更の推奨事項、および予防措置の推奨事項を含む変更要求を開始します。
4. 変更管理計画の規定に従い、変更要求を総合的に検討し、承認、却下、保留などの決定を行います。
5. プロジェクトの設定された目標を達成するためにプロジェクトの変更を管理することに加えて、プロジェクトがビジネスニーズを満たし続けることを保証する観点からもプロジェクトの変更を管理する必要があり、プロジェクトの目標を変更するための変更要求は変更管理委員会に提出される必要があります。承認を求めて。
6. プロジェクトの実行とともに記録された問題ログにあるさまざまな問題をタイムリーに確認して処理し、これらの問題によるプロジェクトへの悪影響を最小限に抑えます。
7. 完成した成果物の品質をタイムリーにチェックし、適格な品質の成果物をタイムリーに受け入れて、プロジェクトの成果物がプロジェクト要件を満たし、組織の変革を達成し、ビジネス価値を創造できることを確認します。
8. チームメンバーと関係者のプロジェクトへの参加を監視し、プロジェクトの成功に貢献していることを確認します。
9. プロジェクトの調達活動を監視し、調達努力がプロジェクト目標の達成に貢献していることを確認します。
10. 個々のプロジェクトのリスクとプロジェクト全体のリスクの両方を監視し、プロジェクト目標に対する脅威を軽減し、プロジェクト目標を達成する可能性を高めるためのリスク管理取り組みの有効性を監視します。
11. 継続的な改善のために経験と教訓を継続的に要約します。
12工程
一、 品質管理
I. 意味
パフォーマンスを評価し、プロジェクトの出力が完全で正しく、顧客の期待に応えていることを確認するために、品質管理活動の結果を監視および記録するプロセス。
II. 効果
i. プロジェクトの成果物と作業が主要な関係者の品質要件を満たしており、最終的な承認が可能であることを確認します。
ii. 適用されるすべての標準、要件、規制、仕様を満たして、プロジェクトの成果物が意図した目的を満たしているかどうかを判断します。
III. このプロセスはプロジェクト全体で実行する必要があります。
IV. このプロセスでは、すべてのステップ、属性、変数を測定することで、計画段階で説明された仕様との一貫性と準拠性を検証します。品質管理は、プロジェクトがスポンサーやクライアントの受け入れ基準を満たしていることを証明する信頼できるデータとともに、プロジェクト全体を通じて実行する必要があります。
V. 品質管理に必要な労力と実行のレベルは、業界やプロジェクト管理のスタイルによって異なります。アジャイル プロジェクトまたはアダプティブ プロジェクトでは、品質管理活動はプロジェクト ライフ サイクル全体を通じてすべてのチーム メンバーによって実行されます。ウォーターフォール プロジェクトまたは予測型プロジェクトでは、品質管理活動は特定の時点またはプロジェクトの終了に向けて特定のチーム メンバーによって実行されます。フェーズの実行。
VI. 伊藤
i. 入力
1. プロジェクト管理計画
品質管理計画
プロジェクトの品質管理をどのように実行するかを定義します。
2. プロジェクトドキュメント
（1） 教訓登録
プロジェクトの初期段階で学んだ教訓を後の段階に適用して、品質管理を向上させることができます。
（2） 品質対策
プロジェクトまたは製品の属性と、品質管理プロセスがコンプライアンスを検証する方法を説明するために指定されています。
（3） テストおよび評価ドキュメント
品質目標の達成度を評価するために使用されます。
3. 承認された変更リクエスト
全体的な変更管理の実装中に、変更ログが更新され、どの変更が承認され、どの変更が承認されなかったかが示されます。承認される変更要求には、欠陥の修正、作業方法の修正、スケジュールの修正など、さまざまな修正が含まれる場合があります。ローカル変更を完了する際に手順が不完全または間違っていると、不整合や遅延が発生する可能性があります。承認された変更リクエストの実装は検証の対象となり、完全性、正確性の確認、および再テストが必要です。
4. 成果物
成果物とは、プロセス、フェーズ、またはプロジェクトの完了時に作成する必要がある、固有で検証可能な製品、結果、またはサービス機能です。プロジェクトの指示および管理の作業プロセスから出力された成果物は検査され、プロジェクトのスコープ ステートメントで定義された受け入れ基準と比較されます。
5. 仕事のパフォーマンスデータ
作業パフォーマンスデータには、観察、品質測定、技術的パフォーマンス測定、スケジュールパフォーマンスとコストパフォーマンスに関するプロジェクト品質情報などの製品ステータスデータが含まれます。
6. 事業環境要因
7. 組織プロセス資産
ii. ツールとテクニック
1. データ収集
（1） チェックリスト
品質活動を構造化して管理および制御するのに役立ちます。
（2） チェックリスト
計数表とも呼ばれ、さまざまな項目を合理的な方法で配置して、潜在的な定性的問題に関する有用なデータを効果的に収集するために使用されます。欠陥を特定するための検査を実施する場合、チェックリストは、欠陥の数や影響に関するデータなどの属性データを収集するのに特に便利です。
（3） 統計的サンプリング
検査対象母集団からいくつかのサンプルを選択して検査することを指します（75 点の設計図面から 10 点をランダムに選択するなど）。サンプルは測定管理や品質確認に使用されます。サンプリングの頻度と規模は、計画の品質管理プロセス中に決定する必要があります。
（4） アンケート
製品またはサービスの導入後に顧客満足度に関するデータを収集するために使用できます。アンケートで特定された欠陥関連コストは、COQ モデルでは外部障害コストとみなすことができ、コストそのものを超えて組織に影響を及ぼします。
2. データ分析
（1） 人事考課
計画品質管理プロセスで定義された品質尺度を、測定、比較、分析することによって、実際の結果と照らし合わせてレビューします。
（2） 根本原因分析 (RAC)
根本原因分析は、欠陥の原因を特定するために使用されます。
3. チェック
検査は、文書化された規格への適合性を判断するための作業成果物の検査です。検査の結果には通常、関連する測定データが含まれており、個々の活動の結果からプロジェクトの最終製品に至るまで、あらゆるレベルで実施できます。検査は、レビュー、ピアレビュー、監査、検査などと呼ばれることもありますが、一部のアプリケーション分野では、これらの用語はより狭く、より具体的な意味を持ちます。検査は、欠陥の修復を確認するためにも使用される場合があります。
4. テスト/製品評価
テストは、プロジェクトのニーズに基づいてテストされる製品またはサービスの品質に関する客観的な情報を提供することを目的とした、組織化された構造化された調査です。テストの目的は、製品またはサービスのエラー、欠陥、脆弱性、またはその他の不適合を特定することです。各要件を評価するために使用されるテストの種類、量、範囲はプロジェクト品質計画の一部であり、プロジェクトの性質、時間、予算、またはその他の制約によって異なります。テストは、プロジェクトのさまざまなコンポーネントが利用可能になるとき、またはプロジェクトの終了時に最終成果物が納品されるときに、プロジェクト全体で実行できます。早期のテストは、非準拠の問題を特定するのに役立ち、非準拠コンポーネントにパッチを適用するコストの削減に役立ちます。アプリケーション分野が異なれば、異なるテストが必要になります。
5. データパフォーマンス
（1） 因果関係図
品質上の欠陥とエラーの考えられる結果を特定するために使用されます。
（2） 管理図
プロセスが安定しているか、またはパフォーマンスが予測可能であるかを判断するために使用されます。仕様の上限と下限は要件に基づいて設定され、最大許容値と最小許容値を反映します。上限および下限管理限界は仕様限界とは異なります。管理限界は、標準的な統計原理に従って標準的な統計計算によって決定され、安定したプロセスの自然な変動範囲を表します。計算された管理限界に基づいて、プロジェクト マネージャーと関係者は、管理限界内に収まらないパフォーマンスを防ぐための修正措置が必要なチェックポイントを特定できます。管理図を使用して、さまざまなタイプの出力変数を監視できます。管理図は、バッチ生産における反復的なアクティビティを追跡するために最も一般的に使用されますが、コストやスケジュールの逸脱、歩留まり、範囲変更の頻度、またはプロジェクト管理プロセスが制御されているかどうかを判断するその他の管理作業を監視するためにも使用できます。
（3） ヒストグラム
欠陥数はソースまたはコンポーネントごとに表示できます。
（4） 散布図
計画されたパフォーマンスを 1 つの軸に表示し、実際のパフォーマンスをもう 1 つの軸に表示できます。
6. 会議
（1） 承認された変更リクエストを確認する
承認された変更リクエストはすべてレビューされ、承認された方法で実装されていること、部分的な変更が完了していること、すべての部分が実行、テスト、完了、検証されていることを確認します。
（2） 振り返り/学んだ教訓
プロジェクトチームのミーティング
以下について議論することを目的としています。
1||| プロジェクト/フェーズの成功要因。
2||| 改善分野;
3||| 現在のプロジェクトと将来のプロジェクトに何を追加できるか。
4||| 組織のプロセス資産に何を追加できるかなど。
iii. 出力
1. 品質管理測定結果
管理品質の測定は、品質管理活動の結果を書面で記録するものであり、品質管理計画で定められた形式で記録される必要があります。
2. 検証された成果物
品質管理プロセスの目的の 1 つは、成果物の正確性を判断することです。品質管理プロセスの実行結果は検証された成果物であり、それが正式に承認されるための範囲の検証プロセスへの入力となります。成果物に関連して変更要求や改善があった場合、変更が実装され、検査され、再検証されることがあります。
3. 仕事のパフォーマンス情報
作業パフォーマンス情報には、プロジェクト要件の達成、拒否の理由、必要なやり直し、修正措置の推奨事項、検証された成果物のリスト、品質測定指標のステータス、およびプロセス調整の必要性に関する情報が含まれます。
4. 変更リクエスト
5. プロジェクト管理計画の更新
品質管理計画
6. プロジェクトファイルの更新
（1） 問題ログ
（2） 教訓登録
（3） リスクレジスター
（4） テストおよび評価ドキュメント
二、 範囲の確認
I. 意味
完了したプロジェクト成果物を正式に受け入れるプロセス。
II. 効果
各成果物を検証することで、受け入れプロセスに客観性をもたらし、最終製品、サービス、または結果が受け入れられる可能性が高まります。
III. このプロセスは、プロジェクト全体を通じて必要に応じて定期的に実行する必要があります。
IV. 品質管理プロセスから出力された検証済みの成果物は、主要な関係者、特に顧客またはスポンサーによってレビューされ、これらの成果物が満足に完了し、正式に受け入れられたことが確認されます。スコープの検証プロセスは、プロジェクト スコープ管理の知識領域の対応するプロセスから取得した出力 (要件文書やスコープ ベースラインなど)、および他の知識領域の実行プロセスから取得した作業パフォーマンス データに基づいて、成果物の検証と最終的な受け入れを行います。
V. 範囲を確認する手順
範囲の検証はプロジェクト全体で行う必要があります。プロジェクトの各段階でプロジェクト スコープを確認する場合は、プロジェクト スコープの変更が効率的かつタイムリーに行われるように、プロジェクト調整を通じてプロジェクト スコープの変更頻度を減らす方法も考慮する必要があります。
範囲を確認する一般的な手順は次のとおりです。
1. スコープ検証が必要な場合を決定します。
2. スコープの検証に必要な入力を特定します。
3. 正式に受け入れられる範囲の基準と要素を決定します。
4. また、範囲確認会議の組織的な手順も決定します。
5. 組織範囲確認会議。
通常、ソフトウェアプロジェクトのスコープを確認する前に、確認作業をスムーズに完了するために、プロジェクトチームはまず品質管理作業を行う必要があります。
範囲確認プロセスと品質管理プロセスの違いは、前者は成果物の受け入れに焦点を当てているのに対し、後者は成果物の正確性と品質要件を満たしているかどうかに焦点を当てていることです。通常、品質の制御プロセスはスコープの検証プロセスに先行しますが、同時に実行することもできます。
VI. 確認すべき問題
1. 成果物は具体的で確認可能ですか?
2. 各成果物には明確なマイルストーンがありますか?また、マイルストーンには明確で識別可能なイベントがありますか?たとえば、顧客からの書面による承認などです。
3. 明確な品質基準はありますか？成果物の納品には明確な標準マークが必要であるだけでなく、成果物が要件に従って完了しているかどうかも明確に定義されている必要があります。
4. レビューと約束は明確に伝えられていますか?プロジェクト スポンサーは、プロジェクトの境界、プロジェクトによって完成する製品またはサービス、およびプロジェクト関連の成果物について正式に合意する必要があります。プロジェクト チームは、成果物が何であるかを明確に理解する必要があります。これらすべては明確かつ全会一致で表明されなければなりません。
5. プロジェクトの範囲は、製品またはサービスのために完了する必要があるすべてのアクティビティをカバーしていますか? 漏れや間違いはありますか?
6. プロジェクトの範囲のリスクが高すぎますか?リスクが発生した場合、経営陣はプロジェクトへの影響を軽減できるでしょうか?
VII. 利害関係者の焦点の違い
1. 管理は主にプロジェクトの範囲に焦点を当てます
これは、範囲がプロジェクトの進捗、資金、リソースに与える影響、これらの要素が組織の範囲を超えているかどうか、およびインプットとアウトプットが合理的であるかどうかを指します。
2. 顧客は主に製品範囲に焦点を当てています
プロジェクトの成果物が製品またはサービスを完成させるのに十分であるかどうかが心配です。
3. プロジェクトマネージャーは主にプロジェクトの制約に焦点を当てます
プロジェクトの成果物が十分であるか、完了する必要があるか、時間、資金、リソースが十分であるかどうか、主な潜在的なリスクと準備された解決策について懸念します。
4. プロジェクト チームのメンバーは、主に、自分たちが関与し、責任を負うプロジェクト範囲の要素に焦点を当てます。
スコープ内の時間を定義して作業時間が十分かどうか、プロジェクトのスコープ内に複数のタスクがあるかどうか、およびこれらのタスク間に競合がないかどうかを確認します。
VIII. 伊藤
i. 入力
1. プロジェクト管理計画
（1） スコープ管理計画
完成した成果物がどのように正式に受け入れられるかを定義します。
（2） 需要管理計画
プロジェクトの要件を特定する方法について説明します。
（3） スコープベースライン
スコープのベースラインと実際の結果を比較して、変更、修正措置、予防措置が必要かどうかを判断します。
2. プロジェクトファイル
（1） 要件文書
要件と実際の結果を比較して、変更、修正措置、または予防措置が必要かどうかを判断します。
（2） 要件追跡マトリックス
要件の確認方法など、要件に関する情報が記載されています。
（3） 品質レポート
レポートには、チームによって管理または報告されたすべての品質保証事項の概要、改善の提案、および品質管理プロセス中に発見された問題を含めることができます。製品を受け入れる前に、これらすべてを確認する必要があります。
（4） 教訓登録
プロジェクトの初期段階で学んだ教訓を後の段階に適用して、成果物の受け入れの効率と有効性を向上させることができます。
3. 検証された成果物
検証済み成果物とは、完成し、管理品質プロセスによって正しいことが確認された成果物です。
4. 仕事のパフォーマンスデータ
これには、要件が満たされる程度、不一致の数、不一致の重大度、または特定の期間内に実行された検証の数が含まれる場合があります。
ii. ツールとテクニック
1. 診る
2. 意思決定
投票する
iii. 出力
1. 受領のための成果物
受け入れ基準を満たす成果物は、クライアントまたはスポンサーによって正式に承認される必要があります。プロジェクト成果物が利害関係者によって正式に受け入れられたことを示す正式な文書をクライアントまたはスポンサーから入手する必要があります。これらの文書は、プロジェクトまたはフェーズの終了プロセスに提出されます。
2. 変更要求
3. 仕事のパフォーマンス情報
作業パフォーマンス情報には、どの成果物が受け入れられ、何が失敗したか、およびその理由など、プロジェクトの進捗情報が含まれます。この情報は記録され、関係者に伝えられる必要があります。
4. プロジェクトファイルの更新
（1） 教訓登録
（2） 要件文書
（3） 要件追跡マトリックス
三、 制御範囲
I. 意味
プロジェクトと製品のスコープのステータスを監視し、スコープのベースライン変更のプロセスを管理します。
II. 効果
プロジェクト全体を通じてスコープのベースラインを維持します。
III. このプロセスはプロジェクト全体で実行する必要があります。
IV. プロジェクトの範囲を制御することで、すべての変更要求、推奨される是正措置、または予防措置が全体的な変更管理プロセスの実装を通じて確実に処理されます。制御プロセスの範囲は、実際に変更が発生したときに管理するためにも必要です。コントロールスコーププロセスは、他のコントロールプロセスと連携して実行する必要があります。
V. スコープクリープ
製品またはプロジェクトの範囲が制御されずに拡大する (時間、コスト、リソースの対応する調整が行われない)。
VI. 伊藤
i. 入力
1. プロジェクト管理計画
（1） スコープ管理計画
プロジェクトと製品の範囲を制御する方法を文書化しました。
（2） 需要管理計画
プロジェクト要件を管理する方法を文書化します。
（3） 変更管理計画
プロジェクトの変更を管理するプロセスが定義されています。
（4） 構成管理計画
どの構成項目が構成項目であるか、どの構成項目が正式な変更制御を必要とするか、およびこれらの構成項目の変更制御プロセスが定義されます。
（5） スコープベースライン
スコープのベースラインと実際の結果を比較して、変更、修正措置、予防措置が必要かどうかを判断します。
（6） パフォーマンス測定ベンチマーク
達成額分析を使用すると、パフォーマンス測定のベースラインが実際の結果と比較され、変更、是正措置、または予防措置が必要かどうかが判断されます。
2. プロジェクトファイル
（1） 教訓登録
プロジェクトの初期段階で学んだ教訓を後の段階に適用して、範囲の制御を改善できます。
（2） 要件文書
合意されたプロジェクトまたは製品範囲からの逸脱を特定するために使用されます。
（3） 要件追跡マトリックス
これは、プロジェクト目標に対する変更や範囲ベースラインからの逸脱の影響を調査するのにも役立ちます。また、管理された要件のステータスも提供されます。
3. 仕事のパフォーマンスデータ
作業パフォーマンス データには、受信した変更リクエストの数、受け入れられた変更リクエストの数、または検証、検証、および完了した成果物の数が含まれる場合があります。
4. 組織プロセス資産
ii. ツールとテクニック
1. データ分析
（1） 偏差分析
（2） トレンド分析
iii. 出力
1. 仕事のパフォーマンス情報
コントロールスコーププロセスによって生成される作業パフォーマンス情報は、プロジェクトと製品のスコープがスコープのベースラインに対してどのように実行されているかについての、相互に関連し、文脈に応じた情報です。これには、受け取った変更の分類、特定されたスコープの逸脱とその原因、スケジュールとコストへの逸脱の影響、予測が含まれます。将来のスコープのパフォーマンスを予測します。
2. 変更要求
3. プロジェクト管理計画の更新
（1） スコープ管理計画
（2） スコープベースライン
（3） 進行状況のベースライン
（4） 原価ベース
（5） パフォーマンス測定ベンチマーク
4. プロジェクトファイルの更新
（1） 要件文書
（2） 要件追跡マトリックス
（3） 教訓登録
四、 進行状況を制御する
I. 意味
プロジェクトのステータスを監視して、プロジェクトの進行状況とスケジュール ベースラインへの変更を管理するプロセスを更新します。
II. 効果
プロジェクト全体を通じてスケジュールのベースラインを維持します。
III. このプロセスはプロジェクト全体で実行する必要があります。
IV. 進捗モデルを更新するには、これまでの実際のパフォーマンスを知る必要があります。スケジュール ベースラインへの変更は、全体的な変更管理プロセスの実装を通じて承認される必要があります。
V. 進行状況の管理 全体的な変更管理プロセスの実装の一環として、以下に重点を置きます。
1. プロジェクトの進行状況の現在の状況を確認します。
2. スケジュール変更を引き起こす要因に影響を与える。
3. 必要なスケジュールの確保を再検討する。
4. プロジェクトのスケジュールが変更されたかどうかを判断します。
5. 実際に発生した変更を管理します。
VI. アジャイル手法を採用する場合は、次の点に注意してください。
1. 前回の期間に納品および受け入れられた作業の合計量と完了した作業の見積もりを比較することにより、プロジェクトの進捗状況を判断します。
2. プロセスを修正および改善するために、遡及的レビュー (学んだ教訓を記録するための定期的なレビュー) を実施します。
3. 残りの作業計画 (バックログ項目) の優先順位を再設定します。
4. 各反復内で成果物が生成、検証、受け入れられる速度を確認します (合意された作業サイクル期間、通常は 2 週間または 1 か月)。
5. プロジェクトのスケジュールが変更されたことを確認します。
6. 実際に発生した変更を管理します。
VII. 作業をアウトソーシングする場合、請負業者やサプライヤーから定期的にマイルストーンに関するステータスの最新情報を入手することは、作業が合意されたスケジュールに確実に進んでいることを確認し、進捗状況を確実に管理するのに役立ちます。同時に、請負業者の報告が正確かつ完全であることを確認するために、進捗状況のレビューと検査を実行する必要があります。
VIII. 伊藤
i. 入力
1. プロジェクト管理計画
（1） 進捗管理計画
プログレスの更新頻度、プログレス保留の使い方、プログレスの制御方法について説明します。
（2） 進行状況のベースライン
進行状況のベースラインと実際の結果を比較して、変更や是正措置、予防措置が必要かどうかを判断します。
（3） スコープベースライン
プロジェクトの WBS、成果物、制約、スコープ ベースラインの前提条件を明示的に考慮する必要があります。
（4） パフォーマンス測定ベンチマーク
達成額分析を使用すると、パフォーマンス測定のベースラインが実際の結果と比較され、変更、是正措置、または予防措置が必要かどうかが判断されます。
2. プロジェクトファイル
（1） 教訓登録
プロジェクトの初期段階で学んだ教訓を後の段階に適用して、スケジュール管理を改善できます。
（2） プロジェクトカレンダー
スケジュール モデルでは、一部のアクティビティには異なる作業期間が必要となるため、プロジェクトの進捗を予測するために複数のプロジェクト カレンダーが必要になる場合があります。
（3） プロジェクトスケジュール
プロジェクトスケジュールの最新版です。
（4） リソースカレンダー
チームおよび物理的リソースの可用性が表示されます。
（5） 進捗データ
進捗データは、進捗管理プロセス中に確認および更新する必要があります。
3. 仕事のパフォーマンスデータ
作業パフォーマンス データには、どのアクティビティが開始されたか、その進捗状況 (実際の終了時間、残り時間、実際の完了率など)、およびどのアクティビティが完了したかなど、プロジェクトのステータスに関するデータが含まれます。
4. 組織プロセス資産
ii. ツールとテクニック
1. データ分析
（1） 収益価値分析
スケジュールバリアンス（SV）やスケジュールパフォーマンスインデックス（SP1）などのスケジュールパフォーマンス測定指標は、当初のスケジュールベースラインからの逸脱度を評価するために使用されます。
（2） 反復バーンダウン チャート
このタイプの図は、反復のバックログでまだ実行されていない作業を追跡するために使用されます。理想的なバーンダウン チャートからの逸脱を分析します。バーンダウン チャートでは、まず斜線を使用して理想的なバーンアウト状況を表し、次に実際の残り作業量を毎日描画し、最後に残り作業量に基づいて傾向線を計算して完了を予測します。
（3） 人事考課
実際の開始日と終了日、完了率、現在の作業の残り時間など、スケジュールのベースラインに対してスケジュールのパフォーマンスを測定、比較、分析することを指します。
（4） トレンド分析
プロジェクトのパフォーマンスを長期的に調査して、パフォーマンスが向上しているか低下しているかを判断します。グラフィカルな分析手法は、これまでのパフォーマンスを理解し、完了日として表される将来のパフォーマンス目標と比較するのに役立ちます。
（5） 偏差分析
計画からの実際の開始日と終了日の偏差、計画からの実際の期間の偏差、およびフロートの偏差に焦点を当てます。これには、スケジュールのベースラインからの逸脱の原因と範囲の特定、これらの逸脱が将来の作業に及ぼす影響の評価、および是正措置または予防措置が必要かどうかの判断が含まれます。
（6） What-if シナリオ分析
プロジェクト リスク管理プロセスの出力に基づいて、さまざまなシナリオが評価され、スケジュール モデルがプロジェクト管理計画および承認されたベースラインと一致します。
2. クリティカルパス方式
クリティカルパスの進捗状況を確認することで、プロジェクトの進捗状況を把握することができます。クリティカル パスの逸脱は、プロジェクトの終了日に直接影響します。サブクリティカル パス上のアクティビティの進捗状況を評価すると、スケジュールのリスクを特定するのに役立ちます。
3. プロジェクト管理情報システム
4. リソースの最適化
リソース最適化手法は、リソースの可用性とプロジェクト時間の両方を考慮しながら、アクティビティとアクティビティに必要なリソースのスケジュールを計画することです。
5. リードとラグ
ネットワーク分析の進み具合と遅れ具合を調整して、遅れているプロジェクト活動を計画どおりに戻すように努めます。
6. 進行状況の圧縮
スケジュール圧縮技術を使用して、スケジュールが遅れているプロジェクト活動を予定どおりに進め、残りの作業に対して迅速なフォローアップまたは急ぎの方法を使用できます。
iii. 出力
1. 仕事のパフォーマンス情報
作業パフォーマンス情報には、スケジュールのベースラインと比較してプロジェクト作業がどのように実行されているかが含まれます。開始日と終了日の偏差と期間の偏差は、作業パッケージ レベルと制御アカウント レベルで計算できます。達成額分析を使用するプロジェクトの場合、スケジュール差異 (SV) とスケジュールパフォーマンス指数 (SP1) が作業パフォーマンスレポートに記録されます。
2. 進捗予測
スケジュール予測とは、既存の情報や知識に基づいて、将来のプロジェクトの状況やイベントを推定または予測することを指します。プロジェクトが実行されるにつれて、作業パフォーマンス情報、収益価値パフォーマンス指標を含む可能性のある是正措置または予防措置に基づいた将来のパフォーマンスの予測、および将来のプロジェクトに影響を与える可能性のあるスケジュールの予備に基づいて、スケジュール予測が更新および再発行される必要があります。 。
3. 変更要求
4. プロジェクト管理計画の更新
（1） 進捗管理計画
（2） 進行状況のベースライン
（3） 原価ベース
（4） パフォーマンス測定ベンチマーク
5. プロジェクトファイルの更新
（1） 仮説ログ
（2） 推定根拠
（3） 教訓登録
（4） プロジェクトスケジュール
（5） リソースカレンダー
（6） リスクレジスター
（7） 進捗データ
五、 コストの管理
I. 意味
プロジェクトのステータスを監視してプロジェクトのコストを更新し、コストの基準変更のプロセスを管理します。
II. 効果
プロジェクト全体を通じてコストのベースラインを維持します。
III. このプロセスはプロジェクト全体で実行する必要があります。
IV. 予算を更新するには、これまでの実際のコストを知る必要があります。予算の増加は、統合変更管理プロセスの実装からの承認があった場合にのみ行うことができます。資金の支出によって完了する作業の価値を考慮せずに、単に資金の支出を監視することは、せいぜい資金の流れを追跡しているとしか考えられません。したがって、コスト管理では、プロジェクトの資本支出とそれに対応して完了した作業との関係を分析することに重点を置く必要があります。効果的なコスト管理の鍵は、承認されたコスト基準を管理することです。
V. プロジェクトのコスト管理の目標には次のものが含まれます。
1. 原価基準の変更を引き起こす影響要因。
2. すべての変更リクエストが速やかに処理されるようにします。
3. 実際に変更が発生したときに変更を管理します。
4. コスト支出が、期間別、WBS コンポーネント別、活動別、またはプロジェクト全体の制限のいずれにも割り当てられていない、承認された資金制限を超えないことを確認します。
5. コストパフォーマンスを監視し、コストベースラインからの逸脱を特定して分析します。
6. 資金支出に対する作業パフォーマンスを監視します。
7. コストまたはリソース使用量レポートの未承認の変更を防止します。
8. 承認されたすべての変更とそれに関連するコストを関係者に報告します。
9. 予想されるコストの超過を許容範囲内に制御するなどしてください。
VI. 伊藤
i. 入力
1. プロジェクト管理計画
（1） コスト管理計画
プロジェクトのコストを管理および制御する方法について説明します。
（2） 原価ベース
コストのベースラインと実際の結果を比較して、変更や是正措置、予防措置が必要かどうかを判断します。
（3） パフォーマンス測定ベンチマーク
達成額分析を使用すると、パフォーマンス測定のベースラインが実際の結果と比較され、変更、是正措置、または予防措置が必要かどうかが判断されます。
2. プロジェクトファイル
コスト管理プロセスへの入力として機能するプロジェクト文書は教訓記録であり、プロジェクトの初期段階で学んだ教訓を後の段階に適用してコスト管理を改善できます。
3. プロジェクトの資金要件
プロジェクトの資金要件には、推定支出と推定負債が含まれます。
4. 仕事のパフォーマンスデータ
作業パフォーマンス データには、どのコストが承認、発生、支払い、請求されたかなど、プロジェクトのステータスに関するデータが含まれます。
5. 組織プロセス資産
ii. ツールとテクニック
1. 専門家の判断
2. データ分析
（1） 収益価値分析 (EVA)
範囲、スケジュール、リソースのパフォーマンスを考慮してプロジェクトのパフォーマンスと進捗を評価する方法。これは、一般的に使用されるプロジェクトのパフォーマンス測定方法です。スコープ ベースライン、コスト ベースライン、スケジュール ベースラインを統合してパフォーマンス測定ベースラインを形成し、プロジェクト管理チームがプロジェクトのパフォーマンスと進捗状況を評価および測定できるようにします。プロジェクト管理手法として、政治分析では、プロジェクト中のパフォーマンスを測定するための統合ベースラインの確立が必要です。 EVA 原則は、あらゆる業界のすべてのプロジェクトに適用されます。
ワーク パッケージと制御アカウントごとに、次のメトリックが計算および監視されます。
1||| 計画値（PV）
プロジェクトの特定の段階で必要な計画作業量を完了するために必要な予算時間 (またはコスト)。 PV は主にスケジュール内で完了すべき作業量を反映しており、管理予備費は含まれません。プロジェクトの計画総額は、完了時予算 (BAC) とも呼ばれます。
2||| 実際のコスト(AC)
プロジェクト実行プロセスの特定の段階で実際に完了したワークロードによって消費された工数（またはコスト）は、主にプロジェクト実行の実際の消費指標を反映します。
3||| 獲得価値 (EV)
プロジェクトの実行プロセスの特定の段階で完了した実際の作業量と、予算割り当てに基づいて計算された工数 (またはコスト) の積。
（2） 偏差分析
達成額管理を使用しないプロジェクトの場合は、計画コストと実際のコストを比較することにより、コストのベースラインと実際のプロジェクトのパフォーマンスの差異を特定します。さらに分析を実行して、スケジュールのベースラインからの逸脱の原因と範囲を特定し、修正措置または予防措置が必要かどうかを判断できます。元のコストベースラインからの逸脱は、コストパフォーマンス測定を通じて評価できます。プロジェクトの作業が徐々に完了するにつれて、偏差の許容範囲 (通常はパーセンテージで表されます) は徐々に縮小していきます。
1||| スケジュール差異 (SV) とスケジュールパフォーマンス指数 (SPI)
スケジュールの差異は、プロジェクトがスケジュールのベースラインより遅れているか、進んでいるかを示すスケジュール パフォーマンスの尺度です。プロジェクトが完了すると、計画されたすべての価値 (つまり、達成価値) が実現されるため、スケジュールの差異は最終的にゼロになります。
SV計算式：SV=EV-PV
SV>0 の場合、進捗が予定より進んでいることを意味します
SV<0 の場合、進捗が遅れていることを意味します
SV=0の場合、実績進捗が計画通りであることを意味します。
スケジュール パフォーマンス インデックスは、プロジェクト チームがどれだけ効率的に時間を使っているかを反映するスケジュール効率の尺度であり、最終的な完了見積もりを予測するためにコスト パフォーマンス インデックス (CPI) と組み合わせて使用されることもあります。 。 SPI はプロジェクトの総工数を測定するため、クリティカル パス上のパフォーマンスも個別に分析して、プロジェクトが完了予定日より早く完了するか遅く完了するかを確認する必要があります。
SPI計算式：SPI=EV/PV
SPI>1.0 の場合、進捗が予定より進んでいることを意味します
SPI <1.0 の場合、進捗が遅れていることを意味します
SPI=1.0の場合、実際の進捗が計画通りであることを意味します。
2||| コスト差異 (CV) とコストパフォーマンス指数 (CPI)
コスト偏差は、プロジェクトのコストパフォーマンスの指標であり、実際のパフォーマンスとコスト支出の関係を示し、特定の時点での予算の赤字または黒字を示します。プロジェクト終了時のコスト差異は、完了時の予算 (BAC) と実際のコストの差です。
CV計算式：CV=EV-AC
CV<0 の場合、コスト超過を意味します
CV>0 の場合、コスト削減を示します。
CV=0 の場合、コストが予算と等しいことを意味します。
コストパフォーマンス指数は、プロジェクトのコスト効率の尺度であり、完了した作業のコスト効率を測定するために使用され、プロジェクトのコストとスケジュールの最終構造を予測するための基礎を提供します。
CPI計算式：CPI=EV/AC
CPI <1.0 はコスト超過を意味します
CPI > 1.0 の場合、コスト削減を示します。
CPI=1.0の場合、コストが予算と等しいことを意味します。
（3） トレンド分析
傾向分析は、プロジェクトのパフォーマンスの時間の経過に伴う変化を調べて、パフォーマンスが向上しているか低下しているかを判断するように設計されています。グラフィカルな分析手法は、これまでのパフォーマンスを理解し、傾向を将来のパフォーマンス目標と比較するのに役立ちます。
傾向分析手法には次のようなものがあります。
1||| チャート
収益価値分析では、計画価値、収益価値、および実際コストの 2 つのパラメーターを段階的に (通常は週または月ベースで)、または累積ベースで監視およびレポートできます。
2||| 予測する
プロジェクトが進行するにつれて、プロジェクト チームはプロジェクトのパフォーマンスに基づいて完了見積もり (CEAC) を予測できます。予測結果は完了予算 (BAC) とは異なる場合があります。 BAC がもはや実現不可能であることが明らかな場合、プロジェクト マネージャーは EAC の事前フラッシュを検討する必要があります。 EAC の予測とは、現在入手可能なパフォーマンス情報やその他の知識に基づいて、将来のプロジェクトの状況やイベントを予測することです。予測は、プロジェクトの実行中に提供される作業パフォーマンス データに基づいて生成、更新、再発行されます。作業パフォーマンス情報には、プロジェクトの過去のパフォーマンスに加え、将来のプロジェクトに影響を与える可能性のある情報が含まれます。
EAC を計算するときは、通常、完了した作業の実際コスト AC に、残りの作業の完了までの見積もり (ETC) を加えたものが使用されます。つまり、EAC = AC ETC です。 ETC を計算する最も一般的な 2 つの方法は次のとおりです。
ETC は非定型偏差に基づいて計算されます。このアプローチは、現在の逸脱が典型的ではないと考えられ、プロジェクト チームが将来同様の逸脱が発生しないと予想している場合によく使用されます。
計算式は次のとおりです: ETC=BAC-EV
ETC は一般的な偏差に基づいて計算されます。このアプローチは、現在の偏差が将来の偏差を表す可能性のある典型的な偏差であると考えられる場合に使用できます。
計算式は次のとおりです: ETC=(BAC-EV)/CPI、または EAC=BAC/CPI
予測された EAC 値が許容範囲内にない場合は、プロジェクト管理チームに早期警告信号が送信されます。
（4） 埋蔵量分析
コスト管理のプロセスでは、予備金分析を使用してプロジェクト内の緊急予備金と管理予備金の使用状況を監視し、これらの予備金がまだ必要かどうか、または追加の予備金を追加する必要があるかどうかを判断できます。プロジェクトの作業が進行するにつれて、これらの予備金は計画どおりにリスクやその他の緊急事態のコストをカバーするために使用される場合があります。また、リスク事象が予想どおりに発生しない場合は、未使用の予備金がプロジェクト予算から差し引かれる場合があります。他のプロジェクトや運営。プロジェクト内のリスク分析をさらに進めると、プロジェクト予算の追加準備金を要求する必要があることが判明する可能性があります。
3. 完成までのパフォーマンス指標
To-Complete パフォーマンス インデックス (TCP1) は、特定の管理目標を達成するために、残りのリソースを使用して達成する必要があるコスト パフォーマンス指標です。これは、残りの予算に対する残りの作業を完了するために必要なコストの比率です。 TCPI は、特定の管理目標 (BAC や EAC など) を達成するために、残りの作業の実装が達成する必要があるコスト パフォーマンス指標を指します。 BAC がもはや実現不可能であることが明らかな場合、プロジェクト マネージャーは TCPI 計算に EAC を使用することを検討する必要があります。承認されると、BAC は EAC に置き換えられます。
BAC に基づく TCPI 式: TCPI=(BAC-EV)/(BAC-AC)
4. プロジェクト管理情報システム
これは、PV、EV、AC の 3 つの収益価値分析指標を監視し、傾向グラフを作成し、プロジェクトの最終結果の可能な範囲を予測するためによく使用されます。
iii. 出力
1. 仕事のパフォーマンス情報
作業パフォーマンス情報には、プロジェクト作業のパフォーマンス (コスト ベースラインに対する) に関する情報が含まれており、作業パッケージ レベルと制御アカウント レベルの両方で、実行された作業と作業コストの逸脱を評価できます。収益価値分析を使用するプロジェクトの場合、CV、CPI、EAC、VAC、および TCPI が作業実績レポートに記録されます。
2. コスト予測
計算された EAC 値であっても、ボトムアップの推定 EAC 値であっても、記録して関係者に伝達する必要があります。
3. 変更要求
4. プロジェクト管理計画の更新
（1） コスト管理計画
（2） 原価ベース
（3） パフォーマンス測定ベンチマーク
5. プロジェクトファイルの更新
（1） 仮説ログ
（2） 推定根拠
（3） 原価見積
（4） 教訓登録
（5） リスクレジスター
六、 制御リソース
I. 意味
物理リソースが計画どおりにプロジェクトに割り当てられ、実際のリソース使用量がリソース使用計画に対して監視され、必要な修正措置が講じられるようにするプロセス。
II. 効果
割り当てられたリソースが適切なタイミングで適切な場所でプロジェクトに利用可能であり、必要がなくなったら解放されるようにします。
III. このプロセスはプロジェクト全体で実行する必要があります。
IV. リソースを制御するプロセスは、プロジェクトのすべてのフェーズおよびプロジェクトのライフサイクル全体を通じて継続的に実行する必要があり、プロジェクトを継続できるように、リソースは適切なタイミングで、適切な場所に、適切な量で割り当ておよび解放される必要があります。制御リソースのプロセスは、機器、材料、施設、インフラストラクチャなどの物理リソースに焦点を当てます。
V. リソース割り当てを更新するときは、どのリソースが使用され、どのリソースをまだ取得する必要があるかを把握する必要があります。これを行うには、これまでのリソース使用状況を確認する必要があります。
VI. 制御リソースのプロセスは以下に焦点を当てます。
1. リソースの支出を監督します。
2. リソース不足/過剰状況をタイムリーに特定し、対処します。
3. プログラムとプロジェクトのニーズに従ってリソースが使用および解放されるようにします。
4. リソース関連の問題が発生した場合は、適切な関係者に通知します。
5. リソース使用量の変化につながる可能性のある影響要因。
6. 実際に発生した変更を管理するなど。
VII. スケジュール ベースラインまたはコスト ベースラインに対する変更は、統合された変更管理プロセスを通じて承認される必要があります。
VIII. 伊藤
i. 入力
1. プロジェクト管理計画
資源管理計画
物理リソースを使用、制御し、最終的に解放する方法についてのガイダンスを提供します。
2. プロジェクトドキュメント
（1） 問題ログ
資源不足、原材料の供給遅延、低品位原材料に関連する問題を特定するために使用されます。
（2） 教訓登録
プロジェクトの初期段階で学んだ教訓を後の段階に適用して、物理リソースの制御を改善できます。
（3） 物的資源配分シート
リソースの予想される使用法と、タイプ、数量、場所、リソースが組織内のものか購入したものであるかなどのリソースの詳細について説明します。
（4） プロジェクトスケジュール
プロジェクトにいつ、どこでどのリソースが必要になるかを示します。
（5） リソースの内訳構造
プロジェクト中にリソースを交換または再取得する必要がある場合の参照を提供します。
（6） リソース要件
プロジェクトに必要な材料、設備、消耗品、その他のリソースが特定されます。
（7） リスクレジスター
機器、材料、供給品に影響を与える可能性のある個別のリスクが特定されます。
3. 仕事のパフォーマンスデータ
作業パフォーマンス データには、使用されたリソースの量や種類など、プロジェクトのステータスに関するデータが含まれます。
4. 合意
プロジェクトで署名された契約は、組織から外部リソースを取得するための基礎となるものであり、新しい計画外のリソースが必要な場合、または現在のリソースに問題が発生した場合に、関連する手順を契約に定義する必要があります。
5. 組織プロセス資産
ii. ツールとテクニック
1. データ分析
（1） 代替案の分析
（2） 費用便益分析
（3） 人事考課
（4） トレンド分析
2. 問題解決
問題解決では、プロジェクト マネージャーがリソースを制御するプロセスで発生する問題を解決するのに役立つさまざまなツールを使用できます。
1||| 問題を特定する: 問題を明確にします。
2||| 問題を定義する: 問題を管理可能な部分に分割します。
3||| 調査: データを収集します。
4||| 分析: 問題の根本原因を見つけます。
5||| 解決策: 多くの解決策の中から最も適切なものを選択します。
6||| 解決策を確認する: 問題が解決されたことを確認します。
3. 対人スキルとチームスキル
（1） 交渉
（2） 影響
4. プロジェクト管理情報システム
iii. 出力
1. 仕事のパフォーマンス情報
2. 変更リクエスト
3. プロジェクト管理計画の更新
（1） リソース管理計画
（2） 進捗ベンチマーク
（3） コストベース
4. プロジェクトファイルの更新
（1） 仮説ログ
（2） 問題ログ
（3） 教訓登録
（4） 物的資源配分シート
（5） リソースの内訳構造
（6） リスクレジスター
七、 コミュニケーションを監督する
I. 意味
プロジェクトとその関係者の情報ニーズが確実に満たされるようにするプロセス。
II. 効果
コミュニケーション管理計画および利害関係者関与計画の要求に応じて、情報転送プロセスを最適化します。
III. このプロセスはプロジェクト全体で実行する必要があります。
IV. コミュニケーションプロセスを監視して、綿密に計画されたコミュニケーション方法とコミュニケーション活動がプロジェクトの成果物と期待される結果をどのようにサポートしているかを判断します。プロジェクトのコミュニケーションの影響と結果は、適切なコンテンツ (送信者と受信者の両方が理解できる) が適切なチャネルを通じて適切なタイミングで適切な視聴者に確実に配信されるように、正式に評価および監視される必要があります。
V. 監督上のコミュニケーションには、顧客満足度調査の実施、学んだ教訓の文書化、チーム観察の実施、問題ログのレビュー、変更の評価など、さまざまな方法が必要となる場合があります。
VI. コミュニケーションプロセスを監視すると、コミュニケーション計画を変更し、コミュニケーションの有効性を向上させるために追加のコミュニケーションアクティビティを実行するために、コミュニケーション管理の計画とコミュニケーションプロセスの管理の反復がトリガーされる場合があります。この反復は、プロジェクト コミュニケーション管理の各プロセスの継続性を反映しています。問題、主要業績評価指標、リスク、または競合が発生すると、これらのプロセスの反復が直ちに開始される可能性があります。
VII. 伊藤
i. 入力
1. プロジェクト管理計画
（1） 資源管理計画
プロジェクト組織図とともに役割と責任を記述することで、リソース管理計画を使用して、実際のプロジェクト組織とその変更を理解することができます。
（2） コミュニケーション管理計画
チームメンバー、利害関係者、およびコミュニケーションプロセスにおける関連タスクを特定する情報をタイムリーに収集、生成、配布するための最新計画。
（3） ステークホルダーエンゲージメント計画
利害関係者の関与を導くために計画されたコミュニケーション戦略が特定されます。
2. プロジェクトドキュメント
（1） 問題ログ
プロジェクトに関する履歴情報、問題への関係者の関与の記録、およびそれらがどのように解決されたかを提供します。
（2） 教訓登録
プロジェクトの初期段階で学んだ教訓は、プロジェクトの後の段階でコミュニケーションを改善するために使用できます。
（3） プロジェクトコミュニケーション記録
行われたコミュニケーションに関する情報を提供します。
3. 仕事のパフォーマンスデータ
行われた通信の種類と量に関するデータが含まれます。
4. 事業環境要因
5. 組織プロセス資産
ii. ツールとテクニック
1. 専門家の判断
2. プロジェクト管理情報システム
3. データパフォーマンス
ステークホルダーの関与評価マトリックス
4. 対人スキルとチームスキル
観察する/話す
5. 会議
iii. 出力
1. 仕事のパフォーマンス情報
2. 変更リクエスト
3. プロジェクト管理計画の更新
（1） コミュニケーション管理計画
（2） ステークホルダーエンゲージメント計画
4. プロジェクトファイルの更新
（1） 問題ログ
（2） 教訓登録
（3） 利害関係者登録簿
八、 見落としリスク
I. 意味
合意されたリスク対応計画の実施を監督し、特定されたリスクを追跡し、新たなリスクを特定および分析し、プロジェクト期間全体を通じてリスク管理の有効性を評価するプロセス
II. 効果
プロジェクトの意思決定は、プロジェクト全体のリスクと個々のプロジェクトのリスクに関する最新の情報に基づいて行われます。
III. このプロセスはプロジェクト全体で実行する必要があります。
IV. プロジェクト チームと主要な利害関係者が現在のリスク レベルを確実に理解できるようにするには、リスク監視プロセスを通じてプロジェクト作業を継続的に監視し、個別のプロジェクトの新たなリスク、変化するリスク、廃止されるリスクに継続的に注意を払う必要があります。
V. リスク監視プロセスでは、プロジェクトの実行中に生成されたパフォーマンス情報を使用して、次のことを判断します。
1. 実施したリスク対応が効果的かどうか。
2. プロジェクト全体のリスクレベルが変化したかどうか。
3. 特定された個々のプロジェクトのリスクのステータスが変化したかどうか。
4. 新たな個別プロジェクトのリスクが発生するかどうか。
5. リスク管理アプローチが依然として適切であるかどうか。
6. プロジェクトの前提条件が依然として有効かどうか。
7. リスク管理ポリシーと手順が遵守されているかどうか。
8. コストまたはスケジュールの緊急準備金を変更する必要があるかどうか。
9. プロジェクト戦略がまだ有効かどうかなど。
VI. 伊藤
i. 入力
1. プロジェクト管理計画
リスク管理計画
これには、リスクをいつどのようにレビューすべきか、どのようなポリシーと手順に従うべきか、このプロセスの監督に関連する役割と責任の取り決め、および報告形式が規定されています。
2. プロジェクトドキュメント
（1） 問題ログ
未解決の問題が更新されているかどうかを確認し、リスク登録に必要な更新を行い、リスク登録に必要な更新を行うために使用されます。
（2） 教訓登録
プロジェクトの初期段階で学んだリスク関連の教訓は、後のフェーズでも活用できます。
（3） リスクレジスター
主な内容には、特定された個々のプロジェクトのリスク、リスク所有者、合意されたリスク対応戦略、および具体的な対応策が含まれます。また、対応計画の有効性を評価するために使用されるコントロール、リスクの症状と早期警告兆候、残存リスクと二次リスク、優先度の低いリスクの監視リストなど、追加の詳細も提供される場合があります。
（4） リスクレポート
現在のプロジェクト全体のリスク ポータルと合意されたリスク対応戦略の評価が含まれており、重要な個別のプロジェクト リスクとその対応計画とリスク所有者についても説明されています。
3. 仕事のパフォーマンスデータ
実施されたリスク対応、発生したリスク、まだアクティブなリスク、終了したリスクなど、プロジェクトのステータスに関する情報が含まれます。
4. 仕事のパフォーマンスレポート
偏差分析結果、稼得額データ、予測データなどのパフォーマンス測定結果を分析することで、プロジェクトの作業パフォーマンスに関する情報を提供できます。この情報は、パフォーマンス関連のリスクを監視するときに必要です。
ii. ツールとテクニック
1. データ分析
（1） 技術的なパフォーマンス分析
技術パフォーマンス分析を実施して、プロジェクトの実行中に達成された技術的成果と、関連する技術的成果を達成するための計画を比較します。実際の結果を計画された要件と比較できる、技術的パフォーマンスの客観的かつ定量的な尺度の定義が必要です。技術的なパフォーマンスの測定には、処理時間、欠陥の数、ストレージ容量が含まれる場合があります。実際の結果が計画からどの程度乖離しているかは、脅威または機会の潜在的な影響を表す可能性があります。
（2） 埋蔵量分析
プロジェクトの実行全体を通じて、予算やスケジュールの緊急準備金にプラスまたはマイナスの影響を与える、特定の個別プロジェクトのリスクが発生する可能性があります。準備金分析とは、残りの緊急準備金とプロジェクトの任意の時点での残りのリスク量を比較し、残りの準備金が依然として妥当であるかどうかを判断することを指します。さまざまなグラフ (バーンダウン チャートなど) を使用して、緊急時準備金の枯渇を示すことができます。
2. 監査
リスク監査
リスク管理プロセスの有効性を評価するために使用できる監査の一種です。プロジェクト マネージャーは、プロジェクト リスク管理計画で指定された頻度でリスク監査が実施されるようにする責任があります。リスク監査は、毎日のプロジェクトレビュー会議とリスクレビュー会議で実行できます。また、チームは特別なリスク監査会議を開催することもできます。監査を実施する前に、リスク監査の手順と目的を明確に定義する必要があります。
3. 会議
リスク検討会議
リスクレビューを定期的にスケジュールして、プロジェクト全体のリスクおよび特定されたプロジェクトの個別リスクに対処する際のリスク対応の有効性を調査し、文書化する必要があります。リスクレビューでは、新しい個々のプロジェクトのリスク (合意された対応から生じる二次的リスクを含む) を特定し、現在のリスクを再評価し、時代遅れのリスクを解決し、リスクの発生によって引き起こされる問題について議論し、プロジェクトの後続の段階で得られる教訓を要約することもできます。現在のプロジェクトまたは将来の同様のプロジェクト。リスク管理計画の規定に応じて、定期的なプロジェクト状況会議でリスクレビューを議題にすることも、専用のリスクレビュー会議を開催することもできます。
iii. 出力
1. 仕事のパフォーマンス情報
単一のリスクの実際の発生と予想される発生を比較することによって得られる、プロジェクトのリスク管理のパフォーマンスに関する情報です。これは、リスク対応計画と対応実施プロセスの有効性を示すことができます。
2. 変更リクエスト
3. プロジェクト管理計画の更新
任意のコンポーネント
4. プロジェクトファイルの更新
（1） 仮説ログ
（2） 問題ログ
（3） 教訓登録
（4） リスクレジスター
（5） リスクレポート
5. 組織プロセス資産の更新
九、 購入をコントロールする
I. 意味
調達関係を管理し、契約の履行を監視し、必要な変更と修正を実施し、契約を締結するためのプロセスを実行します。
II. 効果
買い手と売り手が法的合意を履行し、プロジェクトのニーズを満たしていることを確認します。
III. このプロセスは、必要に応じてプロジェクト全体で実行する必要があります。
IV. 買い手と売り手の両者は、調達契約を管理する上で同様の目的を持っており、各当事者は、両当事者が契約上の義務を履行し、それぞれの法的権利が保護されていることを確認する必要があります。契約関係の法的性質により、プロジェクト管理チームは制御調達中に行われたあらゆる行為の法的影響を理解する必要があります。複数のサプライヤーが関与する大規模プロジェクトの場合、契約管理の重要な側面は、さまざまなサプライヤー間のコミュニケーションを管理することです。法的な重要性を考えると、多くの組織は契約管理をプロジェクトとは別の組織機能として捉えています。調達マネージャーはプロジェクト チームのメンバーになることもできますが、通常は別の部門の契約管理マネージャーに直属します。
V. 調達プロセスを管理する際には、適切なプロジェクト管理プロセスを契約関係に適用する必要があり、これらのプロセスの成果をプロジェクト全体の管理に統合する必要があります。複数の販売者が関与し、複数の製品、サービス、成果が関与する場合、多くの場合、この統合は複数のレベルで行う必要があります。
VI. 契約管理活動には次のものが含まれます。
1. データを収集し、物理的および財務的パフォーマンスの詳細な記録を維持し、測定可能な調達パフォーマンス指標を確立するなど、プロジェクト記録を管理します。
2. 調達計画と進捗計画を改善する。
3. 調達関連プロジェクトデータの収集、分析、報告のためのメカニズムを確立し、組織向けの定期報告書を作成します。
4. 調達環境を監視して実施を指導または調整する。
5. 売主に支払う
VII. 調達監査の独立性と信頼性を含む管理調達の品質は、調達システムの信頼性を決定する重要な要素です。組織の倫理規定、社内弁護士、および継続的な汚職防止プログラムを含む外部の法的アドバイスはすべて、適切な調達管理の達成に貢献します。
VIII. 調達プロセスを管理するには、販売者への支払いを監視するなどの財務管理が必要です。これは、契約の支払い条件が遵守され、支払いが契約に指定されている売り手の作業の進捗に関連付けられていることを確認するためです。注目すべき重要な点は、売り手への支払いと売り手が実際に完了した作業量との間に強い関係があることを確認することです。契約書で、支払いがプロジェクトのインプット（作業時間など）ではなく、プロジェクトのアウトプットと成果物に基づいて行われると規定されていれば、調達管理をより効果的に実行できます。
IX. 契約締結前に、両当事者が合意に達した場合には、契約書の変更管理条項に従って、いつでも契約を変更することができます。契約の変更は通常、書面で文書化されます。
X. 伊藤
i. 入力
1. プロジェクト管理計画
（1） 需要管理計画
請負業者の要件がどのように分析、文書化、管理されるかを説明します。
（2） リスク管理計画
売り手が開始するリスク管理活動がどのように構築され、実行されるかを説明します。
（3） 調達管理計画
制御調達プロセスで実行する必要があるアクティビティを指定します。
（4） 変更管理計画
販売者によって開始された変更を処理する方法に関する情報が含まれています。
（5） 進行状況のベースライン
売り手のスケジュールの遅れがプロジェクトの全体的なスケジュールのパフォーマンスに影響を与える場合、現在の期待を反映するためにスケジュールを更新して承認する必要がある場合があります。
2. プロジェクトファイル
（1） 仮説ログ
調達プロセス中に行われた仮定は文書化されます。
（2） 教訓登録
プロジェクトの初期段階で学んだ教訓は、プロジェクトの将来において、請負業者のパフォーマンスと調達プロセスを改善するために使用できます。
（3） マイルストーンリスト
主要なマイルストーンのリストは、販売者がいつ結果を提供する必要があるかを説明します。
（4） 品質レポート
不適合な販売者のプロセス、手順、または製品を特定するために使用されます。
（5） 要件文書
第一に、販売者が満たす必要がある技術的要件、第二に、健康、安全、セキュリティ、パフォーマンス、環境、保険、知的財産、雇用機会均等、ライセンス、許可などの契約上および法的重要性を伴う要件が含まれる場合があります。技術的以外の要件。
（6） 要件追跡マトリックス
製品要件をソースから要件を満たす成果物に結び付けます。
（7） リスクレジスター
選択された各売主には、売主の組織、契約期間、外部環境、プロジェクトの実施方法、選択された契約の種類、そして最終的に合意された価格に応じて、固有のリスクが生じます。
（8） 利害関係者登録簿
契約チームのメンバー、選択された販売者、契約に署名した専門家、調達に関与するその他の利害関係者など、特定された利害関係者に関する情報を含めます。
3. プロトコル
合意は二者間で締結され、各当事者の義務についての全会一致の理解が含まれます。関連する契約を確認して、その契約条件が遵守されていることを確認してください。
4. 調達書類
調達文書には、作業明細書、支払い情報、請負業者の作業実績情報、計画、図面、その他の通信など、調達プロセスを管理するために使用される完全なサポート記録が含まれています。
5. 承認された変更リクエスト
6. 仕事のパフォーマンスデータ
作業パフォーマンス データには、技術的なパフォーマンス、開始、進行中または完了した活動、発生または投資されたコストなど、プロジェクトのステータスに関連するベンダー データが含まれます。作業実績データには、販売者に支払いが行われたインスタンスも含まれる場合があります。
7. 事業環境要因
8. 組織プロセス資産
ii. ツールとテクニック
1. 専門家の判断
調達を管理する場合は、財務、エンジニアリング、設計、開発、サプライチェーン管理などの関連分野の専門知識または訓練を受けた個人またはグループの意見を求める必要があります。
2. クレーム管理
買い手と売り手が変更に対する補償について合意できない場合、または変更を行うべきかどうかについて意見が一致しない場合、要求された変更は異議のある変更または建設的な変更となる可能性があります。このような係争中の変更はクレームと呼ばれます。適切に解決されないと、紛争が発生し、最終的には苦情につながる可能性があります。契約のライフサイクル全体を通じて、請求は通常、契約の条件に従って記録、処理、監視、管理されます。契約当事者が自ら請求を解決できない場合、契約に指定された手順に従って裁判外紛争解決 (ADR) を利用しなければならない場合があります。すべての申し立てと紛争を解決するには、交渉が推奨される方法です。
3. データ分析
（1） 人事考課
品質、リソース、スケジュール、コストパフォーマンスを契約と比較して測定、比較、分析し、契約作業のパフォーマンスをレビューします。これには、作業パッケージが予定より進んでいるか遅れているか、予算を上回っているか下回っているか、リソースや品質に問題があるかどうかを判断することが含まれます。
（2） 収益価値分析 (EVA)
スケジュールとコストの差異、および目標からの乖離度を判断するためのスケジュールとコストパフォーマンスの指標を計算するために使用されます。
（3） トレンド分析
コスト パフォーマンスに関する完了見積り (CEAC) を作成して、パフォーマンスが向上しているか低下しているかを判断するために使用できます。
4. 診る
検査は、請負業者によって実行されている作業の構造化されたレビューであり、成果物の単純なレビューや作業自体の現場レビューが含まれる場合があります。建設、エンジニアリング、インフラストラクチャのプロジェクトでは、購入者と請負業者が共同で現場を訪問し、行われている作業について双方が共通の理解を持っていることを確認する検査が行われます。
5. 監査
監査は、調達プロセスの構造化されたレビューです。監査に関連する権利と義務は、調達契約で明確に定義される必要があります。買い手側と売り手側の両方のプロジェクト マネージャーは、プロジェクトに必要な調整を行えるように監査結果に注意を払う必要があります。
iii. 出力
1. 調達は完了しました
買い手は、通常、認可された購入管理者を通じて、契約が完了したことを書面で正式に売り手に通知します。調達を正式に完了するための要件は、通常、調達管理計画を含む契約条件に定められています。
一般に、これらの要件には次のものが含まれます。
1||| すべての成果物は、技術的要件に従って、品質を保ちながら予定通りに納品されています。
2||| 未払いの請求や請求書はなく、最終的な支払いはすべて完了しています。
プロジェクト管理チームは、調達を完了する前にすべての成果物を承認する必要があります。
2. 調達書類の更新
3. 仕事のパフォーマンス情報
作業パフォーマンス情報は、契約要件と比較した成果物の完成および技術的パフォーマンスの達成、SOW 予算と比較したコストの生成と完了した作業の認識など、売り手によって実行されている作業のパフォーマンスです。
4. 変更要求
5. プロジェクト管理計画の更新
（1） リスク管理計画
（2） 調達管理計画
（3） 進行状況のベースライン
（4） 原価ベース
6. プロジェクトファイルの更新
（1） 教訓登録
（2） リソース要件
（3） 要件追跡マトリックス
（4） リスクレジスター
（5） 利害関係者登録簿
7. 組織プロセス資産の更新
十、 利害関係者の関与を監督する
I. 意味
プロジェクトの利害関係者間の関係を監督し、参加戦略と計画を修正することで利害関係者がプロジェクト プロセスに合理的に参加できるように導きます。
II. 効果
プロジェクトの進行や環境の変化に応じて、ステークホルダー参加活動の効率や有効性を維持または向上させます。
III. このプロセスはプロジェクト全体で実行する必要があります。
IV. 伊藤
i. 入力
1. プロジェクト管理計画
（1） 資源管理計画
チームメンバーを管理する方法を決定しました。
（2） コミュニケーション管理計画
プロジェクト関係者向けのコミュニケーション計画と戦略について説明します。
（3） ステークホルダーエンゲージメント計画
利害関係者のニーズと期待を管理するための計画が定義されます。
2. プロジェクトファイル
（1） 問題ログ
プロジェクトと関係者に関連するすべての既知の問題を文書化します。
（2） 教訓登録
プロジェクトの初期段階で学んだ教訓は、プロジェクトの後の段階で利害関係者の関与の効率と有効性を向上させるために使用できます。
（3） プロジェクトコミュニケーション記録
コミュニケーション管理計画およびステークホルダーエンゲージメントプランに基づく、プロジェクトのステークホルダーとのコミュニケーションの記録。
（4） リスクレジスター
利害関係者の関与と相互作用に関連するリスクが、その分類と潜在的な対応を含めて文書化されます。
（5） 利害関係者登録簿
ステークホルダー一覧、評価結果、分類状況などを中心に、さまざまなステークホルダー情報を記録します。
3. 仕事のパフォーマンスデータ
どの利害関係者がプロジェクトをサポートしているか、その利害関係者の関与のレベルと種類など、プロジェクトのステータス データが含まれます。
4. 事業環境要因
5. 組織プロセス資産
ii. ツールとテクニック
1. データ分析
（1） 代替案の分析
利害関係者の参加の効果が期待される要件を満たさない場合、逸脱に対処するためのさまざまな代替案を評価するために代替案分析を実行する必要があります。
（2） 根本原因分析
根本原因分析を実施して、利害関係者の関与が望ましい結果を達成できなかった根本原因を特定します。
（3） ステークホルダー分析
プロジェクト上の任意の時点での利害関係者のグループと個人のステータスを確認します。
2. 意思決定
（1） 多基準の意思決定分析
関係者のプロジェクトへの参加を成功させるための基準を検討し、優先順位と重み付けに基づいて最も適切なオプションを特定します。
（2） 投票する
利害関係者の参加レベルの逸脱に対処するための最良の解決策に投票します。
3. データパフォーマンス
ステークホルダーの関与評価マトリックス
ステークホルダー エンゲージメント評価マトリックスを使用してステークホルダー エンゲージメントを監視し、各ステークホルダーのエンゲージメント レベルの変化を追跡します。
4. コミュニケーションスキル
（1） フィードバック
利害関係者に送信された情報が確実に受信され、理解されるようにするために使用されます。
（2） デモ
ステークホルダーに明確な情報を提供します。
5. 対人スキルとチームスキル
（1） アクティブリスニング
積極的に傾聴することで誤解やコミュニケーションエラーを減らします。
（2） 文化的意識
文化的認識と感受性は、プロジェクト マネージャーが利害関係者やチーム メンバーの文化的違いや文化的ニーズを分析し、コミュニケーションを計画するのに役立ちます。
（3） リーダーシップ
利害関係者の関与を成功させるには、ビジョンを伝え、利害関係者にプロジェクトの作業と結果をサポートするよう促すための強力なリーダーシップ スキルが必要です。
（4） 対人コミュニケーション
対人交流を通じてステークホルダーの関与レベルについて学びます。
（5） 政策の認識
ポリシーを認識することは、組織戦略を理解し、誰が権力と影響力を行使できるかを理解し、これらの利害関係者とコミュニケーションする能力を開発するのに役立ちます。
6. ミーティング
ステークホルダーの関与を監視するために使用できる会議の種類には、ステータスミーティング、スタンドアップ、振り返り、およびステークホルダーの関与のレベルを監視および評価するためにステークホルダーの関与計画で指定されたその他の会議が含まれます。会議はもはや対面または音声による対話に限定されません。対面でのやり取りは理想的ですが、コストがかかる場合があります。電話会議と通信テクノロジーはコストを削減し、豊富な連絡方法と通信オプションを提供します。
iii. 出力
1. 仕事のパフォーマンス情報
作業パフォーマンス情報には、ステークホルダーの関与のステータスに関する情報が含まれます。たとえば、プロジェクトに対するステークホルダーのサポートの現在のレベルと、ステークホルダーの関与評価マトリックス、ステークホルダー キューブ、またはその他のツールによって決定される望ましい関与のレベルと比較した情報が含まれます。
2. 変更要求
3. プロジェクト管理計画の更新
（1） 資源管理計画
（2） コミュニケーション管理計画
（3） ステークホルダーエンゲージメント計画
4. プロジェクトファイルの更新
（1） 問題ログ
（2） 教訓登録
（3） リスクレジスター
（4） 利害関係者登録簿
十一、 プロジェクトの作業を監視する
I. 意味
プロジェクト管理計画で特定されたパフォーマンス目標の達成に向けて、プロジェクト全体の進捗状況を追跡、レビュー、報告するプロセス。
II. 効果
関係者にプロジェクトの現在の状況を知らせ、パフォーマンスの問題に対処するために取られる行動に同意してもらうだけでなく、コストとスケジュールの予測を通じて将来のプロジェクトの状況を関係者に知らせます。
III. このプロセスはプロジェクト全体で実行する必要があります。
IV. 監督はプロジェクト全体で行われるプロジェクト管理活動の 1 つであり、プロセス改善を推進するための測定値の収集、測定、分析と傾向の予測が含まれます。継続的なモニタリングにより、プロジェクト管理チームはプロジェクトの進行状況を把握し、特別な注意が必要な領域を特定できます。管理には、問題を効果的に解決するための是正措置や予防措置の策定、または措置計画の再計画と実施の追跡が含まれます。
V. プロジェクトの作業プロセスの監視は主に次のことに焦点を当てています。
1. 実際のプロジェクトのパフォーマンスをプロジェクト管理計画と比較します。
2. プロジェクトのパフォーマンスを定期的に評価し、是正措置または予防措置が必要かどうかを判断し、必要な措置を推奨します。
3. 個々のプロジェクトのリスクの状況を確認します。
4. 製品とドキュメントのステータスを反映するために、プロジェクト全体を通じて正確かつ最新の情報ベースを維持します。
5. ステータスレポート、進捗状況の測定および予測のための情報を提供します。
6. 予測を作成して現在のコストとスケジュール情報を更新します。
7. 承認された変更の実装を監視します。
8. プロジェクトがプログラムの一部である場合、プロジェクトの進捗状況とステータスもプログラム管理者に報告する必要があります。
9. プロジェクトがビジネス ニーズなどと一致していることを確認します。
VI. 伊藤
i. 入力
1. プロジェクト管理計画
任意のコンポーネント
2. プロジェクトファイル
（1） 仮説ログ
プロジェクトに影響を与える前提条件と制約に関する情報が含まれます。
（2） 推定根拠
バイアスに対処する方法を決定するために、さまざまな推定値がどのように導出され、使用されるかを説明します。
（3） コスト予測
プロジェクトの過去のパフォーマンスに基づいて、プロジェクトが予算の許容範囲内にあるかどうかを判断し、必要な変更を特定します。
（4） 問題ログ
目標期日内に特定の問題を解決する責任がある人を文書化および監視するために使用されます。
（5） 教訓登録
逸脱に対応する効果的な方法と、是正措置および予防措置が含まれる場合があります。
（6） マイルストーンリスト
計画されたマイルストーンが達成されたかどうかを確認するには、特定のマイルストーン達成日をリストします。
（7） 品質レポート
品質管理の問題、プロセス、プロジェクト、製品の改善に関する提案、是正措置 (やり直し、欠陥 (抜け穴) の修復、全数検査などを含む) の提案、および品質管理プロセス中に発見された状況の概要が含まれます。
（8） リスクレジスター
プロジェクトの実行中に発生したさまざまな脅威と機会に関する情報を文書化して提供します。
（9） リスクレポート
プロジェクト全体のリスクと個別のリスクに関する情報が記録され、提供されます。
（10） 進捗予測
プロジェクトの過去のパフォーマンスに基づいて、プロジェクトがスケジュールの許容範囲内にあるかどうかを判断し、必要な変更を特定します。
3. 仕事のパフォーマンス情報
作業パフォーマンスデータは作業実行中に収集され、さらなる分析のために制御プロセスに渡されます。作業パフォーマンス情報は、作業パフォーマンス データをプロジェクト管理計画コンポーネント、プロジェクト文書、その他のプロジェクト変数と比較することによって生成されます。この比較により、プロジェクトのパフォーマンスがどの程度優れているかがわかります。
範囲、スケジュール、予算、品質に関する具体的な作業パフォーマンスの尺度は、プロジェクトの開始時にプロジェクト管理計画に指定されます。パフォーマンス データは、プロジェクト中に制御プロセスを通じて収集され、計画や他の変数と比較されて、ジョブ パフォーマンスのコンテキストが提供されます。
4. プロトコル
購入契約には契約条件が含まれており、実行される作業や売り手によって納品される製品に関する買い手による規定などの他の項目も含まれる場合があります。プロジェクトが作業の一部を外部委託する場合、プロジェクト マネージャーは請負業者の作業を監督して、すべての契約がプロジェクト固有の要件および組織の調達ポリシーに準拠していることを確認する必要があります。
5. 事業環境要因
6. 組織プロセス資産
ii. ツールとテクニック
1. 専門家の判断
2. データ分析
（1） 代替案の分析
逸脱が発生した場合に実行する是正措置、または是正措置と予防措置の組み合わせを選択するために使用されます。
（2） 費用便益分析
逸脱が発生した場合に、最もコスト効率の高い修正措置を特定するのに役立ちます。
（3） 収益価値分析
範囲、スケジュール、コストパフォーマンスの包括的な分析を実施しました。
（4） 根本原因分析
問題の主な原因の特定に重点を置き、逸脱が発生した理由と、プロジェクト マネージャーがプロジェクト目標を達成するために注力すべき領域を特定するために使用できます。
（5） トレンド分析
過去の実績に基づいて将来のパフォーマンスを予測することで、プロジェクトのスケジュールの遅延を予測できます。傾向分析は、プロジェクト期間の十分早い段階で実行する必要があります。傾向分析の結果に基づいて、必要な予防策を推奨できます。
（6） 偏差分析
コストの見積もり、リソースの使用量、リソースのレート、技術的パフォーマンス、その他の測定値。プロジェクト作業を監視するプロセスでは、プロジェクト全体の偏差を理解するために、偏差分析を通じてコスト、時間、技術、リソースの偏差を包括的に分析します。
3. 意思決定
投票する
意思決定を行うために次の方法を使用することを含みます: 全会一致の同意、過半数の同意、または相対多数の原則。
4. ミーティング
iii. 出力
1. 仕事のパフォーマンスレポート
仕事のパフォーマンス情報は、物理的または電子的な形式で統合、記録、配布される場合があります。作業パフォーマンス情報に基づいて、決定を下したり、行動を起こしたり、注意を引いたりするために、作業パフォーマンスレポートが物理的または電子的な形式で作成されます。プロジェクトコミュニケーション管理計画に従ったコミュニケーションプロセスを通じて、作業実績レポートをプロジェクト関係者に送信します。
データ、情報、レポートの違い
業務実績報告書の内容としては、現状報告と進捗報告が一般的です。作業実績レポートには、稼得額のグラフと情報、傾向線と予測、引当金バーンダウン グラフ、欠陥ヒストグラム、契約履行情報、リスク プロファイルの概要を含めることができます。
また、注意を引き、決定を下し、行動を起こすためのダッシュボード、大きな表示チャート、タスク ボード、バーン チャートなどとして表すこともできます。
1||| ダッシュボード
情報は電子的に収集され、ステータスを説明するグラフが生成されるため、データの詳細な分析が可能になります。また、確立されたしきい値を超えたメトリックについてのテキストによる説明とともに、高レベルの概要情報を提供するために使用されます。
ダッシュボードには、信号チャート (RAG チャートとも呼ばれます。RAG は赤、黄、緑の略語です)、棒グラフ、円グラフ、および管理図が含まれます。
2||| 大きく見えるチャート
情報エミッターとも呼ばれる Large Visible Chart (BVC) は、組織内のメンバーにメトリクス情報と結果を提供し、タイムリーな知識の共有をサポートする目に見える物理的な表示ツールです。 BVC は、進行中の情報の公開ツールやレポート ツールに限定されるものではありません。BVC は、より頻繁に更新しやすく、人々が簡単に見ることができる場所にある必要があります。一般的に、BVC は電子的に生成されるのではなく、手動で維持されるため、「ローテク ハイタッチ」であることがよくあります。以下の図は、完了した作業、残りの作業、およびリスクに関連する BVC を示しています。
3||| タスクボード
タスク ボードは、開始の準備ができている作業 (To-Do)、進行中の作業、および完了した作業を視覚的に表現するもので、プロジェクト メンバーがいつでも各タスクのステータスを把握するのに役立ちます。さまざまな種類の作業を表すために、さまざまな色の付箋を使用します。
4||| 燃焼チャート
バーン チャート (バーンアップ チャートやバーンダウン チャートを含む) は、プロジェクトの生産性の尺度であるプロジェクト チームの「速度」を示すために使用されます。以下の図に示すように、バーンアップ チャートは計画に対して完了した作業量を追跡でき、バーンダウン チャートは残りの作業量 (適応型アプローチを使用したプロジェクトのストーリー ポイントなど) を表示できます。軽減されたリスクの量。
下図は予算閾値の設定例で、計画支出率を10％超える曲線が1、-20％を超える曲線が2と3であり、実際の支出を表しています。このグラフは、1 月に支出が診断計画のトリガーとなる 10% の許容限度を超えたことを示しています。
プロジェクト チームは、重要なしきい値が突破されるのを待ってから行動を起こすのではなく、傾向や新しい情報を通じて逸脱が予測できる場合には、事前に逸脱に積極的に対処できます。診断計画は、しきい値または予測を超えたときに実行される一連のアクションです。診断計画の重要性は、問題について話し合い、何を行う必要があるかについての計画を策定し、その後、計画が確実に実施され、計画が効果的かどうかを判断するためにフォローアップすることです。
2. 変更要求
3. プロジェクト管理計画の更新
任意のコンポーネント
4. プロジェクトファイルの更新
（1） コスト予測
（2） 進捗予測
（3） 問題ログ
（4） 教訓登録
（5） リスクレジスター
十二、 総合的な変更管理を実装する
I. 意味
すべての変更要求のレビュー、変更の承認、成果物、組織プロセス資産、プロジェクト文書、およびプロジェクト管理計画への変更の管理、および変更処理の結果の伝達のプロセス。
II. このプロセスでは、プロジェクト文書、成果物、またはプロジェクト管理計画に対するすべての変更要求をレビューし、変更要求の処理を決定します。
III. 効果
プロジェクト内の文書化された変更を包括的にレビューします。
IV. プロジェクト全体の目標や計画への影響を考慮せずに変更を実装すると、プロジェクト全体のリスクが増大することがよくあります。
V. このプロセスはプロジェクト全体で実行する必要があります。
VI. 全体的な変更管理プロセスはプロジェクト全体に実装され、プロジェクト マネージャーが最終的な責任を負います。変更リクエストは、プロジェクトの範囲、製品の範囲、プロジェクト管理計画のコンポーネントまたはプロジェクト文書に影響を与える可能性があります。プロジェクトのライフサイクルを通じて、いつでもプロジェクトに関係するすべての関係者が変更リクエストを送信できます。
VII. 変更を正式に管理する必要はなく、ベースラインが確立される前に全体的な変更管理プロセスを実装する必要があります。プロジェクトのベースラインが確立されたら、全体的な変更管理プロセスを実装して変更リクエストを処理する必要があります。変更は口頭で行うこともできますが、すべての変更要求は書面で文書化し、変更管理および/または構成管理システムに組み込む必要があります。変更を承認する前に、変更によるスケジュールへの影響とコストへの影響を理解する必要がある場合があります。変更リクエストがプロジェクトのベースラインに影響を与える可能性がある場合は常に、正式な全体的な変更管理プロセスが必要です。文書化された各変更リクエストは、責任者 (通常はプロジェクト スポンサーまたはプロジェクト マネージャー) によって承認、延期、または拒否される必要があります。この責任者はプロジェクト管理計画または組織手順で指定されるべきであり、CCB は必要に応じて全体的な変更管理プロセスを実行する必要があります。変更リクエストが承認された後、新しい (または修正された) コスト見積もり、アクティビティの順序、スケジュール日、リソース要件、および/またはリスク対応分析が必要になる場合があります。これらの変更には、プロジェクト管理計画やその他のプロジェクト文書の調整が必要になる場合があります。
VIII. 構成管理と変更管理には異なる懸念があります。
1. 構成管理は、各プロセスの成果物と技術仕様に焦点を当てます。
2. 変更管理は、プロジェクト文書、成果物、またはベースラインに対する変更の特定、文書化、承認、または拒否に焦点を当てます。
IX. 変更管理ツールがサポートする必要がある構成管理アクティビティには、次のものがあります。
1. 構成アイテムを特定する
製品構成の定義と検証、製品とドキュメントのラベル付け、変更の管理、責任の明確化の基礎となる構成アイテムを特定および選択します。
2. 構成アイテムのステータスを記録およびレポートする
各構成アイテムに関する情報を記録およびレポートします。
3. 構成アイテムの検証と監査
構成の検証と監査を通じて、プロジェクトの構成項目の構成が正確であること、および対応する変更が登録、評価、承認、追跡され、正しく実装されていることを確認し、構成ファイルで指定された機能要件が達成されていることを確認します。
X. 変更管理ツールがサポートする必要がある変更管理アクティビティには、次のものがあります。
1. 変更を特定する
プロセスまたはプロジェクトのドキュメントへの変更を特定して選択します。
2. 変更を記録する
変更を適切な変更要求として文書化します。
3. 変化する決断をする
変更をレビューし、プロジェクト文書、成果物、またはベースラインの変更について承認、拒否、延期、またはその他の決定を行います。
4. 変更を追跡する
変更が登録、評価、承認、追跡され、最終結果が関係者に通知されたことを確認します。
XI. ツールを使用して、変更要求とその後の決定を管理することもできます。その一方で、変更管理委員会のメンバーが責任を果たし、決定事項を関係者に伝達できるようにコミュニケーションに特別な注意を払います。
XII. 伊藤
i. 入力
1. プロジェクト管理計画
（1） 変更管理計画
変更管理プロセスを管理するためのガイダンスを提供し、CCB の役割と責任を文書化します。
（2） 構成管理計画
プロジェクトの構成項目を説明し、記録および更新する必要がある構成項目を特定し、プロジェクトの製品の一貫性と有効性を維持します。
（3） スコープベースライン
プロジェクトと製品の定義を提供します。
（4） 進行状況のベースライン
プロジェクトのスケジュールに対する変更の影響を評価するために使用されます。
（5） 原価ベース
プロジェクトのコストに対する変更の影響を評価するために使用されます。
2. プロジェクトファイル
（1） 推定根拠
期間、コスト、リソースの見積もりをどのように導き出すかを示し、時間、予算、リソースに対する変更の影響を計算します。
（2） 要件追跡マトリックス
プロジェクトの範囲に対する変更の影響を評価するのに役立ちます。
（3） リスクレポート
変更リクエストに関連するプロジェクトのリスクの原因に関する情報を提供します。
3. 仕事のパフォーマンスレポート
統合変更管理プロセスの実装に特に役立つ作業パフォーマンス レポートには、リソースの可用性、スケジュールとコストのデータ、収益額レポート、バーン チャートまたはバーンダウン チャートが含まれます。
4. 変更要求
プロジェクト実行中の多くのプロセスは変更リクエストを出力します。変更リクエストには、修正措置、予防措置、欠陥修復、および正式に管理されているプロジェクト文書または成果物の更新が含まれる場合があります。変更はプロジェクトのベースラインに影響を与える場合もあれば、影響しない場合もあり、変更の決定は通常、プロジェクト マネージャーによって行われます。
プロジェクトのベースラインに影響を与える変更の場合は、通常、変更を実行するコスト、必要なスケジュール日の変更、リソース要件、および関連するリスクを変更要求に記載する必要があります。このような変更は、CCB (存在する場合) およびクライアントまたはスポンサーによって承認されるものとします。ただし、クライアントまたはスポンサー自身が CCB のメンバーである場合は除きます。承認された変更のみを改訂されたベースラインに組み込むことができます。
5. 事業環境要因
6. 組織プロセス資産
ii. ツールとテクニック
1. 専門家の判断
2. 変更管理ツール
3. データ分析
（1） 代替案の分析
（2） 費用便益分析
4. 意思決定
（1） 投票する
（2） 独裁的な意思決定
（3） 多基準の意思決定分析
5. ミーティング
iii. 出力
1. 承認された変更リクエスト
プロジェクト マネージャー、CCB、または指定されたチーム メンバーは、変更管理計画に従って変更リクエストを処理し、承認、延期、または拒否の決定を下します。承認された変更リクエストは、プロジェクトの指示および管理の作業プロセスを通じて実装されます。変更リクエストが延期または拒否された場合は、変更リクエストを行った個人またはグループに通知する必要があります。
2. プロジェクト管理計画の更新
任意のコンポーネント
3. プロジェクトファイルの更新
変更ログ