意味

特徴

目標

開始背景

他の

意味

プロセス

相互に関連するプロジェクトのグループであり、個別に管理することでは得られない利点を得るために、調整された方法で管理されます。

プロジェクト間の依存関係に焦点を当て、これらの依存関係を管理する最適な方法を見つけるのに役立ちます

ポートフォリオ管理は、戦略的目標を達成するためにまとめられる「適切な」プログラムとプロジェクトの開発に焦点を当てます。

ポートフォリオ価値の最大化とコンポーネントの優先順位付けに重点を置く

製品の継続的な生産および/またはサービスの継続的な運用に注意を払う

戦略的目標を達成するために、ポートフォリオ、プログラム、プロジェクト管理を組織の推進力と統合するためのフレームワーク

開発ライフサイクル

構想、実現、成長、成熟、衰退に至る製品の進化における一連の段階

さまざまな要因に基づいて確立でき、通常は 1 つ以上の成果物の完了で終了します。

ステージゲートはプロジェクトフェーズの最後に行われ、プロジェクトのパフォーマンスと進捗状況がプロジェクト文書やビジネス文書と比較され、比較結果に基づいて決定が行われます（例：継続/終了の決定）。

新しいプロジェクトまたは既存プロジェクトの新しいフェーズを定義し、一連のプロセスがプロジェクトまたはフェーズを開始することを承認します。

プロジェクトのスコープを明確にし、目標を最適化し、目標を達成するためのアクションプランを策定するための一連のプロセス

プロジェクト要件を満たすためにプロジェクト管理計画で特定された作業を完了するための一連のプロセス

プロジェクトの進行状況とパフォーマンスを追跡、レビュー、調整し、必要な計画変更を特定し、対応する変更を開始するための一連のプロセス

プロジェクト、フェーズ、または契約を正式に完了または終了するプロセス

プロジェクト作業の実行中に、実行される各アクティビティから収集された生の観察と測定値

各制御プロセスから収集されたパフォーマンス データは、関連するコンテキストおよびクロスドメイン関係に基づいて統合および分析されます。

意思決定、質問、行動の実行、または懸念の表明を目的として、作業パフォーマンス情報を編集した物理的または電子的なプロジェクト文書

プロジェクトのビジネスケース

意味

プロジェクトがいつどのようにして利益を達成するか、開発する必要がある利益測定メカニズムについて説明します。

プロジェクトの設立を正式に承認し、プロジェクト マネージャーがプロジェクト活動を実行するために組織リソースを使用することを許可する、プロジェクト スポンサーによって発行される文書。

プロジェクトがどのように実行、監視、制御されるかを説明する文書

組織内では誰もが自分に合わないポジションに就く可能性があります

ある面で優れている人は、他の面でも優れていると考えることがよくあります。

確実に起こる何かが起こるのが怖い

どれだけ時間が与えられても、物事は常に最後の瞬間まで延期されなければなりません。

遅れている IT プロジェクトにスタッフを追加すると、さらに遅れが生じる可能性があります

異なる時間を刻む 2 つの時計を持っていると、時間がわかりません。

シンプルかつ短くしてください

あなたが他の人にどう接するかは、他の人があなたにどう接するかによって決まります

従業員は部門別マネージャーから採用されており、権限は低い。

スタッフは機能マネージャーから採用されます。スタッフの中にはプロジェクトマネージャーがいます。プロジェクトマネージャーと機能マネージャーの権限はバランスがとれています。

スタッフは機能マネージャーから採用されます。スタッフの中には機能マネージャーよりも大きな権限を持つプロジェクトマネージャーがいます。

「共有リソース」を管理し、「ベストプラクティス」と「標準」を特定して開発する

「プロジェクト監査」による「標準」の遵守状況の監視

ポリシー、手順、テンプレートを開発および管理し、ガイダンスとトレーニングを提供する

「プロジェクト間」コミュニケーションを調整する

ビジネスケース

給付管理計画

外部クライアントのプロジェクトに取り組む場合、通常は契約の形で行われます。

関連する専門知識やトレーニングを受けた個人またはグループはすべて専門家です

質よりも量を重視して、短時間で多くのアイデアを得る

対象分野の専門家 SME、デフォルトで同じ役割を担っており、面接よりも双方向のコミュニケーションに役立つ

1対1/多対多で直接チャットし、信頼できる環境で機密情報を取得します

会議前に明確な議題を用意し、会議中は議題を逸脱しないようにし、会議後に議事録を作成することが最も効果的です。

コンテンツが含まれています

要約する

プロジェクト憲章に組み込む必要がある高レベルの戦略的および運用上の前提条件と制約を特定する

プロジェクト チームは、プロジェクト憲章を初期プロジェクト計画の出発点として使用します。

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

プロジェクト マネージャーが計画を作成できるようにガイドしたり、プロジェクト管理計画に必要な情報がすべて含まれていることを確認したりするのに役立ちます。

ファシリテーターは、参加者が効果的に参加し、お互いを理解し、合意に達することを保証します。

キックオフ ミーティングは、プロジェクトの目標を伝達し、プロジェクトに対するチームのコミットメントを獲得し、各関係者の役割と責任を明確にすることを目的としています。プロジェクト管理計画は主要な関係者によって承認される必要があります

コンテンツ

効果

基準

気をつけて

まず計画を立てて、変更がある場合は実行します。

変更ログ、教訓記録、マイルストーン リスト、プロジェクト コミュニケーション記録、プロジェクト スケジュール計画、要件追跡マトリックス、リスク記録、リスク レポート

「承認された変更リクエスト」の実装がこのプロセスに該当することに注意してください。

スケジュール計画ソフトウェアツール、作業承認システム、構成管理システム、情報収集および公開システム

検証可能であり、プロジェクト管理計画のコンポーネントが含まれていること。成果物の最初のバージョンが完成したら、変更管理を実行する必要があります

生の観察と測定

問題ログは、プロジェクトのライフサイクル全体を通じてアクティビティを監視するとともに更新する必要があります。

リスクの予防策

逸脱を修正するための修正措置

欠陥修正と品質向上

一般的な変更計画 (またはベースライン) を更新する

活動リスト、前提ログ、教訓記録、要件文書、リスク記録、利害関係者記録

言葉、絵、数字を使って簡単に体系化できる知識

信念、洞察、ノウハウなど、個人の知識や言語化しにくい知識

学んだ教訓の記録、プロジェクト チームの派遣命令、リソースの内訳構造、サプライヤーの選択基準、および利害関係者の登録

プロジェクト管理計画のコンポーネントが含まれる場合があります

ナレッジ管理ツールとテクノロジーは従業員を結び付け、従業員が協力して新しい知識を生成し、暗黙知を共有し、さまざまなチーム メンバーが保持する知識を統合できるようにします。ジョブ シャドウイング、対人コミュニケーション、フォーラム、ストーリーテリング、対話型トレーニングが含まれます。

形式的な知識、学んだ教訓の記録を作成します。インタラクティブ要素の追加により強化し、暗黙知への拡張を促進

プロジェクトの初期段階で作成され、プロジェクト全体を通じて更新され、プロジェクトまたはフェーズの終了時に教訓から得た知識ベースに統合されます。

仮定ログ、見積り根拠、コスト予測、問題ログ、教訓記録、マイルストーンリスト、品質レポート、リスク記録、リスクレポート、スケジュール予測

作業パフォーマンス データは、さらなる分析のために制御プロセスに渡されて、作業パフォーマンス情報が形成されます。作業パフォーマンス情報は、このプロセスへの重要な入力です。

実行する最適な対策の組み合わせ、または最適なシナリオを選択します（プランB）

最もコストを削減する手段を決定する

総合的な性能の検査

問題の根本原因を特定し、根本から対処し、再発を防止します。

過去の実績に基づいて将来のパフォーマンスを予測し、必要な予防策を提案します

目標パフォーマンスと実際のパフォーマンスの差異を確認する

プロジェクト コミュニケーション管理計画に従って、コミュニケーション プロセスを通じて作業パフォーマンス レポートがプロジェクトの関係者に送信され、意思決定、行動の実行、または懸念の提起が行われます。

コスト予測、問題ログ、教訓記録、リスク記録、進捗予測

変更管理計画は、変更管理プロセスを管理するためのガイダンスを提供し、CCB の役割と責任を文書化します。

製品、サービス、成果の一貫性や有効性を維持するために、プロジェクトでどのような情報をどのように記録および更新する必要があるかを説明する

影響を評価するための基礎として使用される

変更を実行するコスト、必要なスケジュール日の変更、リソース要件、および関連するリスクは通常、変更リクエストに記載する必要があります。

変更管理システムとは、文書化、追跡システム、変更承認レベルなどを含む、変更管理のための一連の正式な文書化された手順を指します。また、CCB の構成、役割、権限、責任などについても説明されています。

プロジェクト文書、成果物、またはベースラインに対する変更を特定、文書化、承認または拒否します。ツールは、構成アイテムの特定 (計画)、構成アイテムのステータスの記録とレポート (実行)、構成アイテムの検証と監査 (モニタリング) をサポートする必要があります。

「承認された変更リクエスト」は「プロジェクト作業の指示と管理」サブプロセスで実装され、このプロセスには実装作業は含まれないことに注意してください。

ベンチマークへの変更は、最新バージョンのベンチマークに基づいて将来の状況に対処することのみが可能であり、過去のパフォーマンスを変更することはできません。

変更が承認されるかどうかに関係なく、変更ログを更新する必要があります。

1. 承認を得る 2. 最終結果を渡す 3. 経験と学んだ教訓を要約する 4. 組織プロセス資産を更新する 5. アーカイブする 6. リソースをリリースする

1. 理由を調査して記録する 2. 完了した最終結果と未完成の最終結果を引き渡す 3. 学んだ教訓を要約する 4. 組織プロセス資産を更新する 5. アーカイブする 6. リソースをリリースする

プロジェクト管理計画は、プロジェクトがどのように実行、監視、終了されるかを説明する文書であり、終了のガイドとして使用できます。

仮定ログ、推定根拠、変更ログ、問題ログ、教訓記録、マイルストーンリスト、プロジェクトコミュニケーション記録、品質管理測定結果、品質報告書、要件文書、リスク記録、リスクレポート

スコープの検証プロセスから

ビジネスケースは、プロジェクトが経済的実現可能性調査で期待される結果を達成するかどうかを判断するために使用されます。利益管理計画は、プロジェクトが計画された利益を達成したかどうかを測定するために使用されます。

プロジェクトまたはフェーズの終了プロセスに影響を与える可能性がある組織プロセス資産には次のものが含まれます (ただし、これらに限定されません): プロジェクトまたはフェーズの終了ガイドラインまたは要件 (終了方法がわからない場合は、終了ガイドを参照してください)

成果物が受諾に合格したことの確認、終了基準が満たされていることの判断、契約の正式な終了、利害関係者の満足度の評価、学んだ教訓の収集、プロジェクトの知識と情報の伝達、成功の祝いに使用されます。

教訓登録

プロジェクトによって提供される最終製品、サービス、または結果 (またはフェーズ終了の場合は、中間製品、サービス、またはフェーズの結果) をあるチームから別のチームに移転すること

最終レポートでプロジェクトのパフォーマンスを要約する

プロジェクトまたはフェーズの終了文書には、プロジェクトまたはフェーズの完了を示す正式な文書が含まれます。プロジェクトが完了前に早期に終了した場合、正式な終了文書にはプロジェクト終了の理由を記載し、プロジェクトの完了済みおよび未完成の成果物を他の人に引き渡すための正式な手順を記載する必要があります。

品質管理計画、プロジェクトのライフサイクルの説明、開発方法論

スコープクリープのリスクを軽減するためにプロジェクトスコープを定義、開発、監視、制御、検証する方法を説明する

プロジェクトと製品の要件を分析、文書化、管理する方法を説明する

プロジェクト憲章には、プロジェクトの概要と、詳細な要件を作成するために使用される高レベルの要件が文書化されています。

スコープ管理計画、要件管理計画、ステークホルダーエンゲージメント計画

仮定ログ、教訓記録、利害関係者記録

ビジネス ニーズを満たすために満たす必要がある、必要な標準、期待される標準、およびオプションの標準について説明します。

契約にはプロジェクトと製品の要件が含まれます

ブレーンストーミング

インタビュー

フォーカスグループ

アンケート

ベンチマーク

ファイル分析

投票する

独裁的な意思決定

多基準の意思決定分析

親和性図

マインドマッピング

名目上のグループ

観察して話す

ガイド

トポロジーマップ、視覚化

漸進的な精緻化の概念をサポートします。例: ストーリーボード作成。手戻りのリスクを軽減できます。ステップ (繰り返しサイクル): 1. モデルの作成、2. ユーザー エクスペリエンス、3. フィードバックの収集、4. プロトタイプの修正 (変更プロセスが必要な場合があります)

要件文書は、さまざまな単一要件がプロジェクトに関連するビジネス ニーズをどのように満たすかを説明します。

要件トレーサビリティ マトリックスは、製品要件をそのソースからその要件を満たす成果物まで結び付ける表です。各要件をビジネス目標またはプロジェクト目標に結び付けると、各要件にビジネス価値があることが保証されます。要件文書内のすべての承認された要件がプロジェクトの終了時に確実に提供されるようにするのに役立ちます。最後に、要件追跡マトリックスは、製品範囲の変更を管理するためのフレームワークも提供します。

プロジェクト憲章には、プロジェクト、製品の機能、承認要件の概要が記載されています。

要件文書は、範囲に含めるべき要件を特定します。

高レベルの製品またはサービスの説明を意味のある成果物に変換するために使用されます。含まれるもの：製品需要分析、システム価値分析、

一般化する

製品範囲の説明

成果物

プロジェクトの除外

実行する必要がある作業とプロジェクトに含まれない作業について説明します。

要件文書では、さまざまな単一要件がプロジェクトのビジネス ニーズをどのように満たすかを詳しく説明します。

プロジェクトの範囲とプロジェクトの成果物を、より小さく管理しやすいコンポーネントに段階的に分割する手法

いくつかの重要な原則: 80 時間の原則、100% の責任。

承認された範囲ステートメント、WBS、および対応する WBS 辞書

WBS のコントロール アカウントは、管理コントロール ポイントです。このコントロール ポイントでは、範囲、予算、スケジュールが統合され、獲得価値と比較されてパフォーマンスを測定します。

WBS辞書

検証済み成果物とは、完成し、品質管理プロセスによって正しいことが確認された成果物です。

測定、レビュー、検証などの活動を実施して、作業と成果物が要件と製品の受け入れ基準を満たしているかどうかを判断します。

受け入れ基準を満たす成果物は、クライアントまたはスポンサーによって正式に承認される必要があります。

合格しなかった場合は、1. 理由を記録します。 2. 変更を加えて欠陥を修正する

範囲の確認は成果物の受け入れに重点を置き、品質管理は成果物が品質要件を満たしているかどうかに焦点を当てます。通常はまず範囲が確認され、次に品質管理が実行されますが、この 2 つを同時に実行することもできます。品質管理は内部検査であり、プロジェクトの成果物についての確認範囲が外部関係者 (顧客またはスポンサー) によってチェックされ、受け入れられます。

確認スコープは成果物の検証と受け入れに重点を置き、プロジェクト終了はプロジェクトまたはフェーズを終了するために実行するプロセス作業に重点を置き、確認スコープとプロジェクト終了の両方に受け入れ作業があり、確認スコープはプロジェクト成果物の受け入れに重点を置き、プロジェクト終了は受け入れに重点を置きます。製品の。

製品またはプロジェクトのスコープを（対応する時間、コスト、リソースの調整を行わずに）制御せずに拡大することをスコープ クリープといいます。

スコープベースライン

要件文書

要件追跡マトリックス

偏差分析

トレンド分析

プロジェクト憲章で指定された全体的なマイルストーン スケジュールは、プロジェクトのスケジュール管理に影響します。

スコープ管理計画、開発方法論

意味

プロジェクトスケジュールモデルの開発

進捗管理計画

スコープベースライン

プロジェクトの範囲とプロジェクトの成果物を、より小さく管理しやすいコンポーネントに段階的に分割する手法。チームメンバーを分解プロセスに参加させると、より優れた、より正確な結果が得られます。

戦略計画の初期段階では、情報が十分に明確ではないため、作業パッケージは既知の詳細レベルまでしか分解できませんが、後でさらに多くの情報が得られると、近い将来に実装される作業パッケージを分解できるようになります。具体的な活動に取り入れます。

プロジェクトに必要なすべてのスケジュールアクティビティの包括的なリストです

アクティビティの説明を拡張するための各アクティビティのさまざまな属性

各マイルストーンが必須（契約で義務付けられているなど）であるか、オプション（履歴情報に基づいて決定されているなど）であるか。マイルストーンはアクティビティではなく、重要な時点またはイベントを表すため、期間はゼロです。

プロジェクトのベースラインを定義した後、成果物をアクティビティに徐々に詳細化していく過程で、もともとプロジェクトのベースラインに属さない作業が発見され、変更リクエストが提起されることがあります。

スコープベースライン

仮説ログ

FS、FF、SS、SF。 (先行アクティビティが XX の場合、後続アクティビティは XX にすることができます) FS は最も一般的に使用されるタイプの論理関係です。SF 関係はほとんど使用されません。

意味

必須の依存関係

選択的な依存関係

外部依存関係

内部依存関係

リード タイムは、後続アクティビティが先行アクティビティと比較して進めることができる時間です。ラグは、後続アクティビティが先行アクティビティと比較して遅延する必要がある時間です。

プロジェクト スケジュール ネットワーク図は、プロジェクト スケジュール アクティビティ間の論理関係 (依存関係とも呼ばれます) を表すグラフです。収束と分岐を伴うアクティビティは、複数のアクティビティの影響を受ける、または影響を与える可能性があるため、より大きなリスクが生じます。

時間がある限り、人は意図的か非意図的かに関わらず、すべての時間が使い果たされるまで、必要以上の仕事をすることになります（スコープクリープ）。

仕事の範囲は変わらないことが多く、人々は早い時間には何もしないか、ほとんど何もせず、締め切りが近づくまで待ってから急いで仕事を始めます。

うまくいかない可能性のあることは、うまくいかないでしょう

仕事は常に無能な人々によって占領されます。

リソースカレンダー

スケジュール管理計画、スコープベースライン

専門家の判断、全体的な見積もり、トップダウンの見積もりに似ています。高速、低コスト、そして正確。過去の活動が表面的ではなく本質的に似ていて、見積もりを行うプロジェクト チームのメンバーが必要な専門知識を持っている場合、類似見積もりが最も信頼できます。

履歴データと他の変数の間の統計的関係。パラメトリックモデルの成熟度と基本データの定量化

期間の見積もりの​​精度を向上させるために、見積もりの​​不確実性とリスクを考慮する

ベータ分布: 予想される期間 = (最も可能性の高い時間 4 * 最も楽観的な時間 最も悲観的な時間) / 6

三角分布: 予想期間 = (最も可能性の高い時間、最も楽観的な時間、最も悲観的な時間)/3

下から上にレイヤーごとにまとめます

代替案分析

埋蔵量分析

遅延は含まれませんが、一定範囲の変化を示す可能性があります

スケジュール管理計画、スコープベースライン

プロジェクト進捗ネットワーク図、プロジェクトチーム派遣命令、リソースカレンダー

スケジュール ネットワーク分析は、クリティカル パス手法、リソース最適化手法、モデリング手法など、他のいくつかの手法を使用するプロジェクト スケジュール モデルを作成するための包括的な手法です。

クリティカル パスは、プロジェクト内の最も長い一連のアクティビティであり、プロジェクトの最短期間を決定します。プロジェクトの完了日を遅らせたり、スケジュールの制約に違反したりすることなく、スケジュール アクティビティを最も早い開始日から遅らせることができる時間の長さが、トータル フロートまたはスケジュールの柔軟性となります。使用される制約に応じて、クリティカル パスの合計フロートは、正、ゼロ、または負になることがあります。フリー フロートとは、後続アクティビティの最も早い開始日を遅らせたり、スケジュールの制約に違反したりすることなく、スケジュール アクティビティを遅延できる時間です。

リソースバランシング

リソースのスムージング

既存のスケジュールに基づいて、さまざまなシナリオを検討し、さまざまな条件下でプロジェクトのスケジュールの実現可能性を評価します。

最も一般的なシミュレーション手法はモンテカルロ法です

意味

急ぎの仕事

素早いフォローアップ

リリースの進捗状況の高レベルのタイムライン (通常は 3 ～ 6 か月) を提供します。同時に、アジャイル リリース計画により、リリースのイテレーションまたはスプリントの数も決定されます。

スケジュール ベースラインは承認されたスケジュール モデルです

スケジュール モデルの出力には、比較的読みやすく、経営陣とのコミュニケーションに使用される棒グラフ、主要な成果物の計画開始日または完了日のみを示すマイルストーン チャート、および主要なプロジェクト スケジュール ネットワーク図が含まれます。純粋に論理図と論理棒グラフです

スケジュールされたアクティビティを実行できる勤務日と勤務シフトを指定します。

スケジュールのベースラインと比較したプロジェクト作業のパフォーマンスを含む

プロジェクト憲章では、事前承認された財務に関する規定が定められています。

進捗管理計画、リスク管理計画

プロジェクトのコストがどのように計画、スケジュール、管理されるかを説明する

コスト管理計画、品質管理計画、スコープベースライン

教訓登録、リスク登録

プロジェクトスケジュール

リソース要件

過去の同様のプロジェクトパラメータ値またはスケール指標に基づいて、現在のプロジェクトの同じパラメータまたは指標が推定されます。類似見積もりは最も信頼性が高く、以前のアクティビティが表面的ではなく本質的に類似しており、見積もりを行うプロジェクト チームのメンバーが必要な専門知識を持っている場合には、プロジェクトの初期段階でよく使用されます。

履歴データと他の変数の間の統計的関係。パラメトリックモデルの成熟度と基本データの定量化

下から上にレイヤーごとにまとめます

期間推定の精度を向上させるために、推定の不確実性とリスクを考慮してください。

代替案分析

埋蔵量分析

品質コスト

プロジェクト作業を完了するために必要となる可能性のあるコストを含めます。間接費もプロジェクトの見積もりに含まれている場合、活動レベル以上で請求​​できます。

コスト管理計画、品質管理計画、スコープベースライン

プロジェクトスケジュール

推定根拠

原価見積

ビジネスケース、福利厚生管理計画

コスト要約では、まず WBS の作業パッケージにコスト見積もりを要約し、次にその作業パッケージを WBS の上位レベル (制御アカウントなど) に要約し、最後にプロジェクト全体の総コストを取得します。

埋蔵量分析

パラメータまたはアナログ推定に役立つ履歴情報を確認します。

資金支出は、プロジェクト資金に対する制限とのバランスをとる必要があります。資金の制約と計画された支出の間に不一致が発見された場合、資金支出のレベルのバランスをとるために作業のスケジュールを調整する必要がある場合があります。これは、プロジェクトのスケジュールに必須の日付を追加することで実現できます。

承認され、段階的に設定されたプロジェクト予算は、管理予備費を除き、正式な変更管理プロセスを通じてのみ変更される可能性があり、実際の結果との比較の基礎として使用されます。コストのベースラインは、さまざまなスケジュール活動の承認済み予算の合計です。

プロジェクト資金は段階的に投資されるため、不均等になる可能性があります。管理準備金がある場合、必要資金総額は原価基準に管理準備金を加えた額となります。

原価見積

プロジェクトスケジュール

リスクレジスター

コスト管理計画、コストベースライン、パフォーマンス測定ベースライン

教訓登録

収益価値分析: BAC、PV、EV、AC

偏差分析：SV、CV、SPI、CPI

傾向分析: EAC、ETC

TCPI、VAC

埋蔵量分析

(TCPI) は、特定の管理目標を達成するために、残りのリソースの使用が達成しなければならないコストパフォーマンス指標であり、残りの予算に対する残りの作業を完了するために必要なコストの比率です。

作業パフォーマンス情報には、プロジェクト作業が（コストベースラインに対して）どのように実行されているかに関する情報が含まれており、作業パッケージレベルと制御アカウントレベルの両方で、実行された作業と作業コストの差異を評価できます。

計算された EAC 値であっても、ボトムアップの推定 EAC 値であっても、記録して関係者に伝達する必要があります。

将来のキャッシュフローを適切な割引率で割り引いた価値（現在の将来のお金の価値）

7% の割引率に基づく場合、3 年後に受け取った 8,000 ドルの現在価値は次のようになります。

投資計画によって生み出されるネットキャッシュフローと、資本コストを割引率として割り引いた後の元の投資の現在価値との差（期間内の収益の現在価値の合計から元の投資を差し引いたもの）

需要管理計画

スコープベースライン

ステークホルダーエンゲージメント計画

利害関係者登録

品質方針は上級管理者によって推奨され、特別な状況下では個別に策定することができます。

ベンチマーク

ブレーンストーミング

インタビュー

費用便益分析

品質コスト

多基準の意思決定分析

フローチャート

論理データモデル

マトリックス図

マインドマッピング

関連を満たすために製品、成果物、またはサービスがどのようにテストまたは検査されるか 利害関係者のニーズと期待

品質目標を達成するために、適用可能なポリシー、手順、ガイドラインがどのように実装されるかを説明します。 品質基準、品質目標、役割と責任などが含まれます。

プロジェクトまたは製品の属性と、品質管理プロセスの検証方法を説明するために使用されます。 適合性の認証

管理品質プロセスでは、これらの品質測定指標に基づいてプロジェクトのテスト シナリオを設定します。 改善の取り組みの基礎となる成果物

プロジェクトのプロセスと成果物の品質が、実行組織の標準または特定の要件を満たしているかどうかを分析および評価するために使用されます。また、これらの測定結果の生成プロセスを分析して、実際の測定結果がどの程度正しいかを判断するのにも役立ちます。

チェックリスト

代替案分析

ファイル分析

プロセス分析

根本原因分析 (RCA)

多基準の意思決定分析

親和性図

因果関係図

フローチャート

ヒストグラム

パレート

マトリックス図

散布図

プロジェクト活動が組織およびプロジェクトのポリシー、プロセス、手順に準拠しているかどうかを判断するために使用される、構造化された独立したプロセス。これには、1 識別、2 共有、3 支援、4 蓄積、5 確認が含まれます。内部または外部の監査人によってランダムに実施される場合があります。

製品設計中に最適化のために使用できる一連の技術ガイドライン。 デザインの具体的な側面

PDCA 計画、実行、確認、実行、シックスシグマ

1 定義、2 特定、3 計画、4 選択、5 実行、6 検証。問題解決は、問題を解決し、長期にわたる解決策を開発するのに役立ちます

他のプロセスや部門が是正措置を講じてプロジェクトの期待品質を達成するのに役立つグラフィック、データ、または定性的な文書を使用できます。

テストおよび評価文書は、業界要件と組織モジュールに基づいて作成できます。これらは品質管理プロセスへの入力値であり、品質目標の達成度を評価するために使用されます。

品質対策

テストおよび評価ドキュメント

承認された変更リクエストの実装には、完全性の検証と確認が必要です。 正しさ、および再テストするかどうか

成果物は検証可能であり、検査されます

チェックリスト

サンプリングの頻度と規模は、計画の品質管理プロセス中に決定する必要があります。

作業成果物を検査して、文書化された標準への準拠を判断します

早期テストはコンプライアンス違反の問題を特定するのに役立ちます

プロセスが安定しているか、またはパフォーマンスが予測可能であるかを判断するために使用されます。仕様の上下限と管理の上限、および管理外の判断方法に注意

プロジェクトチームが開催した承認された変更リクエストのレビュー、振り返り/教訓。

管理品質測定は、品質管理活動の結果を書面で記録したものです。 記録は品質管理計画で定められたフォーマットで記録する必要があります。

スコーププロセスへの入力を正式に承認するための確認

品質管理計画、範囲ベースライン

プロジェクトスケジュール、要件文書、リスク登録簿、利害関係者登録簿

階層的な

責任割り当てマトリックス

テキストタイプ

個人、チーム、組織単位がどのように行動するかを説明する

意味

コンテンツ

チームの価値観、コンセンサス、チームの作業ガイドラインに関する文書を作成します。認識し、 明確なルールに従うことで誤解が減り、チーム憲章を定期的に見直して更新できるようになります。 チームが常にチームの基本ルールを理解し、新しいメンバーがチームに溶け込めるように導くためのプロセス

リソース管理計画、範囲ベースライン

アクティビティ属性、アクティビティ リスト、コスト見積もり、リソース カレンダー

代替案分析

各ワークパッケージまたはワークパッケージ内のアクティビティに必要なリソースのタイプと量が特定されます。

リソースはカテゴリとタイプごとに階層的に表示されます

資源管理計画、調達管理計画、コストベースライン

プロジェクトのスケジュール、リソース カレンダー、リソース要件

多基準の意思決定分析

交渉

プロジェクトの物理的リソースまたはチーム リソースを事前に決定します。 1. 入札プロセス中にコミットする、2. プロジェクトを取得する 特定の人々の特定のスキルに依存します。 3. プロジェクト憲章またはその他のプロセスの指定

利点を理解するが、コミュニケーションの問題にも注意する

プロジェクトで使用される材料、設備、消耗品、場所、およびその他の物理的リソース

プロジェクトにおけるチームメンバーとその役割と責任を文書化する

リソースが利用できる時期とその期間

資源管理計画

プロジェクト スケジュール、プロジェクト チームの作業指示、リソース カレンダー、チーム憲章

集中オフィス

仮想チーム

チームビルディング

初期の報酬計画は、計画リソース管理プロセス中に作成され、受信者の重要なニーズを満たす報酬のみが効果的です。報酬は、文化の違いを考慮して、公式または非公式に行うことができます。価値を示す報酬を受け取ることでモチベーションを高めましょう。お金は目に見える報酬ですが、それと同じくらい効果的、あるいはそれ以上に効果的なさまざまな無形の報酬があります。プロジェクトのライフサイクル全体を通じて、可能な限り評価を与える必要があります。

差異を減らします。追加されたスキルが将来のプロジェクトに利益をもたらす場合、トレーニング費用は通常、プロジェクトの予算に含まれるか、実行組織が負担する必要があります。トレーニングは社内または社外のトレーナーによって実施可能

360°パフォーマンスレビューなど、メンバーの長所と短所についての洞察を得る

個人スキルの向上、チーム能力の向上、チームメンバーの離職率の低減、チームの結束力の強化

従業員のスキル

資源管理計画

チーム憲章

決定する

影響

リーダーシップ

競合管理

感情的知性

資源管理計画

物的リソース割り当てシート、プロジェクト スケジュール、リソースの内訳構造、リソース要件

代替分析、費用対効果分析、パフォーマンスレビュー、傾向分析

特定、定義、調査、分析（根本原因の発見）、問題の解決、解決策の検討

交渉: プロジェクト マネージャーは、物理リソースの追加、物理リソースの変更、またはリソース関連のコストについて交渉する場合があります。

影響: プロジェクト マネージャーがタイムリーに問題を解決し、必要なリソースを入手できるように支援します。

ステークホルダーエンゲージメント計画

利害関係者登録

コミュニケーションのニーズを分析し、必要な情報の種類と形式、関係者にとっての情報の価値など、プロジェクト関係者の情報ニーズを判断します。通信チャネルは n*(n-1)/2 として計算され、プロジェクト マネージャーを含める必要があります。

カンファレンスやWebサイトなどのさまざまなテクノロジー。情報の緊急性、可用性、使いやすさ、機密性、機密性を考慮する必要がある

エンコード、情報の伝達、デコード、受信確認（受信確認）、フィードバック/応答。

受領確認は、情報を受領したことを示すだけであり、必ずしも情報の内容への同意や理解を意味するものではありません。 送信者は、情報の送信、情報の明確性と完全性を確保し、情報が正確であることを確認する責任があります。 正しい理解; 受信側には、情報が完全に受信され、正しく理解されていることを確認する責任があり、受信したことを通知する必要があります。 に、または適切に応答します。双方とも騒音やその他の障害物に注意する必要があります。

インタラクティブコミュニケーション

プッシュコミュニケーション

プルコミュニケーション

すべてを会議で解決する必要がある場合、それは組織の作業手順やシステムに問題があることを意味します。

情報伝達に問題がある場合は、コミュニケーション管理計画を参照してください。

関係者のコミュニケーションニーズ。

言語、形式、内容、詳細レベルなど、伝達される情報。

報告期限、報告経路、報告手順。

要求された情報のリリース、受信確認、または応答 (該当する場合) の時間枠と頻度。

情報の受信先となる個人またはグループ (ニーズ、要望、期待など)。

メモ、電子メール、プレスリリース、ソーシャルメディアなど、情報を配信するために使用される方法または技術。

時間と予算を含む、コミュニケーション活動に割り当てられるリソース。

一般用語の用語集。

ステータスレポートや進捗レポートなどの作業パフォーマンスレポートは、このプロセスを通じてプロジェクト関係者に配信されます。ジョブ パフォーマンス レポート ダッシュボード、ホット スポット レポート、信号、または注意、意思決定、および行動を促進するその他の形式。

リソース管理計画、コミュニケーション管理計画、利害関係者関与計画

変更ログ、問題ログ、教訓記録、品質レポート、リスクレポート、ステークホルダー記録

プロジェクト情報を収集および配布する行為。作業パフォーマンス レポートはプロジェクト作業のモニタリング プロセスの出力ですが、このプロセスでは臨時レポート、プロジェクト プレゼンテーション、ブログ、その他の種類の情報が生成されます。

パフォーマンスレポート、成果物のステータス、スケジュールの進捗状況、発生したコスト、 デモンストレーションおよび利害関係者が必要とするその他の情報

プロジェクト憲章には、プロジェクトの高レベルのリスクが文書化されています

ステークホルダー分析

リスク計画会議

意味

リスクカテゴリー

関連当事者のリスク選好

リスクの確率と影響の定義

確率と影響のマトリックス

ファシリテーターの指導の下、自由なフォームまたは構造化されたフォームを使用して、さまざまな創造的なアイデアを生み出します。

過去に発生し、現在のプロジェクトに関連する可能性のある特定のプロジェクトのリスクをリストします。ただし、チェックリストは必要なリスクの特定作業に代わるものではありません。追加、削除、またはアーカイブされた新しい情報 古い情報

信頼と守秘義務が守られた環境で面接を実施し、正直で公平な意見を得る

仮定と制約の分析を実施して、仮定と制約の妥当性を調査する

プロジェクトの強み、弱み、機会、脅威（SWOT）のケースバイケースの調査

プロジェクト チームのアイデア開発を支援するフレームワークとして使用できます。リスク分類構造の下部にあるリスク カテゴリをプロンプト リストとして使用して、プロジェクト全体のリスクを特定します (PESTLE、TECOP、VUCA)。

特定された個々のプロジェクトのリスクの詳細を記録します。含まれるもの: 特定されたリスク リスト、潜在的なリスクの責任者、潜在的なリスク対応策のリスト

プロジェクト全体のリスクと特定された個別のプロジェクトのリスクに関する情報を提供する リスクの概要情報

リスクデータの品質評価

リスクの確率と影響の評価

他のリスクパラメータの評価

最もリスクにさらされている領域に注意と取り組みを集中させたり、一連の関連リスクに対する共通のリスク対応を開発したりするのに役立ちます。

確率と影響のマトリックス

階層図

リスク責任は、個々のプロジェクトのリスクに 1 つずつ割り当てられる必要があります。今後はリスクオーナーが責任を負います。 リスク対応の計画とリスク管理の取り組みの進捗状況の報告を担当します。

インタビュー

確率分布

感度分析でさまざまな変数の相対的な重要性を比較するために使用される特別な形式の棒グラフ。

EMV = (定時到着確率 * 定時到着収入) (遅延確率 * 遅延損失 (負の数))

個々のプロジェクトのリスクやその他の不確実性源を反映する定量的リスク分析モデル。リスクの発生が計画されたアクティビティに関連していない場合、リスクは確率的分岐として扱うのが最適です。

シミュレーション

感度分析 (トルネード プロット)

影響図

デシジョンツリー分析

報告

避ける

移行

緩和する

受け入れる

報告

開ける

共有

改善する

受け入れる

特定のイベントが発生した場合にのみ使用される応答。緊急事態対応および復旧計画を含む

簡単な比較を行って、どの応答が最適であるかを判断します

費用便益分析を通じて代替リスク対応戦略​​の費用対効果を判断する

多基準の意思決定分析

変更を提案し、関連するアクティビティをプロジェクト管理計画に追加します。

戦略、具体的な行動、早期警告、緊急時対応計画、リバウンド計画、二次リスク、残留リスク

リスクレジスター、リスクレポート

リスク管理計画

影響: 指定されたリスク所有者に必要な措置を講じるよう奨励する

技術的なパフォーマンス分析

埋蔵量分析

リスク管理プロセスの有効性を評価します。プロジェクト マネージャーは、プロジェクトのリスクが次の規則に従って確実に管理されるようにする責任があります。 経営計画に定められた頻度でリスク監査を実施

リスク検討会議。新しいリスクを特定し、現在のリスクを再評価し、古いリスクを解決します。

リスク監視プロセス中に生成される個々のプロジェクトのリスクに関する情報を記録する

一括契約

仕事と資材の契約 (T&M)

費用償還契約

市場調査

作るか買うかの分析

最低コスト（標準化された調達または日常的な調達に適用）、資格のみに基づく（比較的少額の調達額に適用）、品質または技術ソリューションのスコアに基づく、品質とコスト、独占的なソース、固定予算に基づく

調達に影響を与える可能性のあるプロジェクトのスケジュールの策定や管理など、プロジェクトの他の側面と調達を調整する方法。独立した見積もりを作成する必要があるかどうか、および要件を含む評価基準として使用する必要があるかどうか。特定のプロジェクトのリスクを軽減するための履行保証金または保険契約の場合

潜在的な販売者がそのような製品、サービス、または結果を提供する能力を判断できるように、購入を提案された製品、サービス、または結果を十分に詳細に説明します。調達作業明細書は、明確、完全かつ簡潔であるよう努める必要があります。パフォーマンスに関するレポートや、購入した商品の継続的な運用サポートなど、必要な追加サービスについて説明する必要があります。調達プロセス中、作業明細書は、署名された契約の一部となるまで、必要に応じて修正される必要があります。

技術的な専門知識と方法論、会社の財務的安定性など。

配送方法

契約支払いタイプ

調達段階

入札文書は、情報への招待状、見積への招待状、提案への招待状、または他の適切な調達文書であり得る。応答形式の要件、関連する調達作業明細書、および必要な契約条件を含めます。

製造か購入か分析を使用すると、特定のジョブを実行するのにプロジェクトが最適であることがわかります。 チームが自分たちで行うか、それとも外部ソースから購入する必要があるかの決定

大量の購入の場合、購入組織は独自の独立した見積もりを作成できます。 外部の専門の見積もり業者を雇ってコスト見積もりを作成し、それを売り手のオファーを評価するためのベースラインとして使用します。のように 2 つの間に大きな違いがある場合は、調達作業明細書に欠陥があるか不明確であることを示している可能性があります。 潜在的な売主が調達作業明細書を誤解したか、完全に応答しなかった

入札書類、調達作業明細書、独立したコスト見積もり、サプライヤーの選択基準を含む

基本情報を含む調達パッケージに対して売主が作成する提案書 この情報は、評価チームが 1 人以上の入札者 (売り手) を選択するために使用されます。

広告により、潜在的な販売者の既存のリストが拡張されることがよくあります

提案が提出される前の買い手と潜在的な売り手との間の会議。その目的は、すべての潜在的な入札者が調達要件を明確かつ一貫して理解しており、入札者が特別な扱いを受けないことを保証することです。

提案評価：入札評価、重み付け、スクリーニング

調達交渉

プロポーザル評価または入札評価において最も競争力が高いと判断された入札者

契約は、両当事者を拘束する合意です。これにより、売り手は指定された製品、サービス、または結果を提供することが強制され、買い手は対応する報酬を売り手に支払うことが義務付けられます。契約は、買い手と売り手の間に法的に保護された関係を確立します。調達作業明細書またはスケジュールに指定されたマイルストーン、または一般的な契約条件および変更要求の処理が含まれる場合がありますが、これに限定されません。解決方法。

合意とは、各当事者の義務についての合意された理解を含む、二者間の合意です。みんなで戦う 合意が優先されるものとします

調達に関連する変更は、管理された調達プロセスを通じて実施される前に、書面で正式に文書化され、正式に承認される必要があります。

1. 交渉 2. ADR (裁判外紛争解決) 3. 訴追。すべての申し立てと紛争を解決するには、交渉が推奨される方法です

人事考課

売り手の納品物の買い手による検査

監査は、調達プロセスの構造化されたレビューです。買い手のプロジェクトマネージャーと売り手のプロジェクトマネージャー マネージャーは、プロジェクトに必要な調整を行えるように、監査結果に注意を払う必要があります。

買い手は通常、認可された購買管理者を通じて、契約が完了したことを売り手に通知します。 正式な書面による通知

プロジェクト憲章には主要な利害関係者がリストされ、利害関係者の責任に関する情報が含まれる場合があります。 情報

契約の当事者はすべてプロジェクトの利害関係者であり、他の関係者が関与する場合もあります。

アンケート・調査

マインドライティング

ステークホルダー分析

ハイライトモデル

プロジェクトに多数のステークホルダーがいて、ステークホルダー コミュニティのメンバーが頻繁に変わる場合、ステークホルダー コミュニティは プロジェクト チームまたは利害関係者コミュニティ内との複雑な関係では、利害関係者を優先する必要がある場合があります。 レベルソート

利害関係者登録

ステークホルダー分析の結果を世界クラスとみなされる他の分析結果と比較する 比較する組織またはプロジェクトの情報

根本原因分析

優先順位付けまたはランク付け

マインド マッピングは、利害関係者の情報、相互関係、および組織との関係をマッピングするために使用されます。 視覚的に整理する

ステークホルダー エンゲージメント評価マトリックスは、ステークホルダー エンゲージメントの現在のレベルと望ましいエンゲージメント レベルを比較するために使用されます。認識していない: プロジェクトとその潜在的な影響を認識していません。抵抗力がある: プロジェクトとその潜在的な影響を認識していますが、プロジェクトの作業や結果から生じる可能性のある変更には抵抗します。そのような当事者は、プロジェクトの作業やプロジェクトの成果をサポートしません。中立: プロジェクトについては理解していますが、支持も反対もしません。協力的: プロジェクトとその潜在的な影響を理解し、プロジェクトの作業とその結果をサポートします。リーダーシップ: プロジェクトとその潜在的な影響を理解し、その成功を確実にするために積極的に関与します。 C は各利害関係者の現在の関与レベルを表し、D はプロジェクトの成功を確実にするために必要に応じてプロジェクト チームによって評価された関与レベル (望ましい) を表します。各関係者の現在の参加レベルと予想される参加レベルとのギャップに基づいて必要なコミュニケーションを実施し、関係者がプロジェクトに参加するように効果的に誘導する必要があります。

利害関係者関与計画には、個人または利害関係者を関与させるための特定の戦略または方法が含まれる場合があります (ただし、これらに限定されません)。