プロジェクトの特定の要件を満たすように組織の標準プロセスと手順を調整するためのガイドラインと基準

方針などの具体的な組織基準（人事方針、安全衛生方針、セキュリティおよび機密保持方針、品質方針、調達方針、環境方針など）

製品とプロジェクトのライフサイクル、および方法と手順（プロジェクト管理方法、評価指標、プロセス監査、改善目標、チェックリスト、組織内で使用される標準化されたプロセス定義など）

テンプレート (プロジェクト管理計画、プロジェクト文書、プロジェクト登録簿、報告書フォーマット、契約テンプレート、リスク分類、リスク説明テンプレート、確率と影響の定義、確率と影響のマトリックス、利害関係者登録テンプレートなど)

事前承認されたサプライヤーリストとさまざまな契約タイプ（一時金、費用償還、作業および材料契約など）

ベストプラクティス

トレーニング

学んだ教訓

方法論

テンプレートツール

ガバナンス

特定

報告

ビジネスケース

給付管理計画

契約は、プロジェクトを開始する当初の目的を定義するために使用されます。契約には、契約書、覚書 (MOU)、サービス レベル契約 (SLA)、合意書、意向書、口頭合意、電子メール、その他の書面による合意など、さまざまな形式があります。外部クライアント向けのプロジェクトに取り組む場合、通常は He Yu の形で行われます。

プロジェクト憲章プロセスに影響を与える可能性のある組織プロセス資産には以下が含まれます (ただし、これらに限定されません)。

専門家の判断とは、応用分野、知識分野、専門分野、業界などにおける専門知識に基づいた、現在の活動に関する合理的な判断を指します。この専門知識は、専門資格、知識、スキル、経験、またはトレーニング経験を持つ任意のグループから得られるものです。個人。

アクセス チャネルには以下が含まれます (ただし、これらに限定されません)。

ブレーンストーミング

フォーカスグループ

インタビュー

競合管理

ガイド

会議の管理

プロジェクト憲章の作成プロセス中に、主要な関係者とのミーティングの目的は、プロジェクトの目標、成功基準、主要な成果物、高レベルの要件、全体的なマイルストーン、およびその他の概要情報を特定することです。

補足: 6 つの思考の帽子

プロジェクト憲章は、プロジェクトの設立を正式に承認し、プロジェクト マネージャーがプロジェクト活動を実行するために組織リソースを使用することを許可する、開始者またはスポンサーによって発行される文書です。プロジェクトと、プロジェクトが提供すると予想される製品、サービス、結果に関する概要情報が記録されます。

プロジェクト憲章は、主要な成果物、マイルストーン、各プロジェクト参加者の役割と責任について関係者が一般に同意することを保証します。

通常、プロジェクトの開始前にビジネス ケースを作成するときに、高レベルの戦略的および運用上の前提条件と制約が特定されます。これらの前提条件と制約は、プロジェクト憲章に含める必要があります。下位レベルのアクティビティおよびタスクの前提条件は、仕様、見積もり、スケジュール、リスクの定義などのアクティビティがプロジェクト中に実行されるときに生成されます。仮定ログは、プロジェクトのライフサイクル全体を通じてすべての仮定と制約を記録するために使用されます。

プロジェクト チームは、プロジェクト憲章を初期プロジェクト計画の出発点として使用します。プロジェクト憲章に含まれる情報の量と種類は、プロジェクトの複雑さとすでにわかっている内容によって異なります。プロジェクト管理計画のさまざまなコンポーネントをさらに改良するために、少なくとも、プロジェクトに関する高レベルの情報をプロジェクト憲章で定義する必要があります。

プロジェクト管理計画を作成するには、多くのプロセスからのデータを統合する必要があります。他の計画プロセスから出力されるサブプランとベースラインは、このプロセスへの入力となります。さらに、これらのサブプランとベースラインを変更すると、それに対応してプロジェクト管理計画が更新される場合があります。

ブレーンストーミング

チェックリスト

フォーカスグループ

インタビュー

競合管理

ガイド

会議の管理

このプロセス中、会議はプロジェクトのアプローチについて話し合い、プロジェクトの目標を達成するために作業をどのように実行するかを決定し、プロジェクトを監視する方法を開発するために使用できます。

キックオフミーティングプロジェクトがスタート

計画中のプロジェクト

プロジェクト管理計画のあらゆるコンポーネントをこのプロセスへの入力として使用できます。

変更ログ

教訓登録

マイルストーンリスト

プロジェクトコミュニケーション記録

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

要件追跡マトリックス

リスクレジスター

リスクレポート

承認された変更リクエストは、プロジェクト マネージャーによって、また必要に応じて変更管理委員会 (CCB) によってレビューおよび承認された変更リクエストを含む、全体的な変更管理プロセスの実装の出力です。承認された変更リクエストは、修正措置、予防措置、または欠陥修復である可能性があり、プロジェクト チームによってプロジェクト スケジュールに組み込まれる可能性があり、プロジェクトまたはプロジェクト管理計画のあらゆる領域に影響を与える可能性があります。正式に管理されているプロジェクトの改訂。計画コンポーネントまたはプロジェクト文書を管理します。

このシステムは、ビジネス環境要因の一部として主要業績評価指標 (KPI) を自動的に収集して報告するためにも使用できます。

成果物とは、プロセス、フェーズ、またはプロジェクトの完了時に作成する必要がある、固有で検証可能な製品、結果、またはサービス機能です。通常、これはプロジェクトの成果であり、プロジェクト管理計画のコンポーネントが含まれる場合もあります。

次のように分割できます: 成果物 結果

作業パフォーマンス データは、プロジェクト作業の実行中に実行される各アクティビティから収集された生の観察と測定値です。データは通常、他のプロセスが情報を抽出できる最低レベルの詳細です。データは作業の実行中に収集され、さらなる分析のために制御プロセスに渡されます。

プロジェクトのライフサイクル全体を通じて、プロジェクト マネージャーは問題、ギャップ、不一致、または予期せぬ衝突に遭遇することがよくあります。プロジェクト マネージャーは、プロジェクトのパフォーマンスに影響を与えないように、これに対処するために特定の措置を講じる必要があります。問題ログは、すべての問題が記録および追跡されるプロジェクト文書です。

問題ログは、プロジェクト マネージャーが問題を効果的にフォローアップして管理し、確実に調査して解決するのに役立ちます。このプロセスの出力として、初めて問題ログが作成されますが、問題はプロジェクト中いつでも発生する可能性があります。問題ログは、プロジェクトのライフサイクル全体を通じてアクティビティを監視するとともに更新する必要があります。

補足: 問題とリスク

変更リクエストは、ドキュメント、成果物、またはベースラインを変更するための正式な提案です。プロジェクト作業の実行中に問題が発見された場合は、変更リクエストを送信して、プロジェクトのポリシーや手順、プロジェクトや製品の範囲、プロジェクトのコストや予算、プロジェクトのスケジュール、またはプロジェクトや製品の結果の品質を変更できます。その他の変更リクエストには、将来の悪影響を防ぐために必要な予防措置または是正措置が含まれます。変更リクエストはプロジェクトの関係者であれば誰でも送信でき、全体的な変更管理プロセスの実装を通じてレビューされ、処理される必要があります。変更リクエストはプロジェクト内またはプロジェクト外から発生し、オプションであるか、法律 (契約) によって義務付けられています。

任意のコンポーネント

アクティビティリスト

仮説ログ

教訓登録

要件文書

リスクレジスター

利害関係者登録

すべてのコンポーネント

教訓登録

プロジェクト チームが作業指示書を発送します

リソースの内訳構造

サプライヤーの選択基準

利害関係者登録

ナレッジ管理ツールとテクノロジーは従業員を結び付け、従業員が協力して新しい知識を生成し、暗黙知を共有し、さまざまなメンバーが保有する知識を統合できるようにします。プロジェクトに適したツールとテクニックは、プロジェクトの性質、特にイノベーションの程度、プロジェクトの複雑さ、チームの多様性の程度（専門分野の多様性を含む）によって異なります。

これらのツールとテクニックはすべて、直接または仮想的に適用できます。多くの場合、対面での対話は、ナレッジ管理に必要な信頼関係の確立に最も役立ちます。一度信頼が確立されると、仮想対話を使用してこの信頼関係を維持できます。

情報管理ツールと技術は、人々と知識の間のつながりを生み出すために使用され、シンプルかつ明確な方法で形式的知識の共有を効果的に促進します。

「連絡してください」機能などのインタラクティブな要素を追加することで、ユーザーはレッスンのポスターとつながり、特定のプロジェクトや状況に関連するアドバイスを求めることができます。これにより、情報管理ツールと技術の使用が強化されます。

アクティブリスニング

ガイド

リーダーシップ

対人コミュニケーション

政治的意識

教訓記録には、状況のカテゴリと説明を含めることができ、また、教訓記録には、状況に関連する影響、推奨事項、および一連の行動を含めることもできます。教訓記録には、課題、遭遇した問題、認識されたリスクと機会、またはその他のコンテンツを必要に応じて記録できます。

教訓記録は、このプロセスの出力としてプロジェクトの初期段階で作成されます。したがって、プロジェクト全体の多くのプロセスへの入力として使用できるだけでなく、出力として継続的に更新することもできます。この作業に関わる個人やチームは、学んだ教訓の文書化にも携わっています。知識はビデオ、写真、音声、その他の適切な方法で記録できるため、学んだ教訓を効果的に学習できます。

プロジェクトまたはフェーズの終了時に、関連情報は教訓知識ベースに組み込まれ、組織プロセス資産の一部になります。

任意のコンポーネント

すべてのプロジェクトは新しい知識を生み出します。プロジェクトの知識プロセスの管理中に、一部の知識を体系化して成果物に埋め込む必要があります。またはプロセスや手順を改善するために使用されます。このプロセスでは、たとえば、新しいプログラムの既存のアイデアが試行され、このプロジェクトで成功した場合など、既存の知識が初めて体系化または使用されることもあります。

このプロセス中に、組織プロセス資産を更新できます。

任意のコンポーネント

仮説ログ

推定根拠

コスト予測

問題ログ

教訓登録

マイルストーンリスト

品質レポート

リスクレジスター

リスクレポート

進捗予測

作業パフォーマンスデータは作業実行中に収集され、さらなる分析のために制御プロセスに渡されます。作業パフォーマンス情報は、作業パフォーマンス データをプロジェクト管理計画コンポーネント、プロジェクト文書、その他のプロジェクト変数と比較することによって生成されます。この比較により、プロジェクトのパフォーマンスがどの程度優れているかがわかります。

購入契約には契約条件が含まれており、実行される作業や売り手によって納品される製品に関する買い手による規定などの他の項目も含まれる場合があります。プロジェクトが作業の一部を外部委託する場合、プロジェクト マネージャーは請負業者の作業を監督して、すべての契約がプロジェクト固有の要件および組織の調達ポリシーに準拠していることを確認する必要があります。

代替案の分析

費用便益分析

収益価値分析

根本原因分析

トレンド分析

偏差分析

仕事のパフォーマンス情報は、物理的または電子的な形式で統合、記録、配布される場合があります。意思決定、行動の実行、または懸念の表明を目的として、職務遂行情報に基づいて職務遂行報告書を物理的または電子的な形式で作成します。プロジェクトコミュニケーション管理計画に従ったコミュニケーションプロセスを通じて、作業実績レポートをプロジェクト関係者に送信します。

ジョブ パフォーマンス レポートの例には、ステータス レポートや進捗レポートなどがあります。作業実績レポートには、稼得額のグラフと情報、傾向線と予測、引当金バーンダウン グラフ、欠陥ヒストグラム、契約履行情報、リスク プロファイルの概要を含めることができます。これは、ダッシュボード、ホットスポット レポート、信号機、または注意を引き、決定を下し、行動を起こすのに役立つその他の形式をとることができます。

任意のコンポーネント

コスト予測

問題ログ

教訓登録

リスクレジスター

進捗予測

要件を完全に収集する

ステークホルダーのサポートと参加

付加価値のない変更

付加価値のある変化

新しいプロジェクトを確立することをお勧めします

または変更プロセスに従ってください

欠陥は修理しなければならない

提案する

対処する

埋め込む

変更管理計画

構成管理計画

スコープベースライン

進行状況のベースライン

原価ベース

推定根拠

要件追跡マトリックス

リスクレポート

多くのプロセスが変更要求を出力します。変更リクエストには、修正措置、予防措置、欠陥修復、および変更または追加されたコメントやコンテンツを反映するための、正式に管理されているプロジェクト文書や成果物の更新が含まれる場合があります。変更はプロジェクトのベースラインに影響を与える場合もあれば、影響しない場合もありますが、ベースラインと比較したプロジェクトのパフォーマンスにのみ影響します。変更の決定は通常、プロジェクト マネージャーによって行われます。

プロジェクトのベースラインに影響を与える変更の場合は、通常、変更を実行するコスト、必要なスケジュール日の変更、リソース要件、および関連するリスクを変更要求に記載する必要があります。このような変更は、CCB (存在する場合) およびクライアントまたはスポンサーによって承認されるものとします。ただし、クライアントまたはスポンサー自身が CCB のメンバーである場合は除きます。承認された変更のみを改訂されたベースラインに組み込むことができます。

構成と変更の管理を容易にするために、多数の手動または自動ツールを使用できます。構成管理は成果物と個々のプロセスの技術仕様に焦点を当てますが、変更管理はプロジェクト文書、成果物、またはベースラインに対する変更の特定、文書化、承認、または拒否に注目します。

ツールの選択は、組織および環境の状況や制約の考慮を含め、プロジェクト関係者のニーズに基づいて行う必要があります。

ツールがサポートすべき構成管理アクティビティ

ツールがサポートする必要がある変更管理アクティビティ

追加する

代替案の分析

費用便益分析

投票する

独裁的な意思決定

多基準の意思決定分析

変更管理委員会 (CCB) と変更管理会議を実施します。変更管理委員会は変更要求を検討し、承認、拒否、または延期の決定を下します。ほとんどの変更は、時間、コスト、リソース、またはリスクに一定の影響を与えるため、変更の影響を評価することも会議の基本的なタスクです。さらに、要求された変更に対する代替案が会議で議論され、提案される場合があります。最後に、会議の決定を変更要求の責任者またはグループに伝えます。

CCB は構成管理活動をレビューすることもあります。変更管理委員会の役割と責任は、すべての関係者からの全会一致の同意を得て、変更管理計画に明確に定義および文書化する必要があります。 CCB の決定は記録され、関係者に通知され、情報を得てフォローアップの措置を講じることができるようにする必要があります。

プロジェクト マネージャー、CCB、または指定されたチーム メンバーは、変更管理計画に従って変更リクエストを処理し、承認、延期、または拒否の決定を下します。承認された変更リクエストは、プロジェクトの指示および管理の作業プロセスを通じて実装されます。変更リクエストが延期または拒否された場合は、変更リクエストを行った個人またはグループに通知する必要があります。

すべての変更リクエストの処理を、プロジェクト ファイルの更新の形式で変更ログに記録します。

任意のコンポーネント

プロジェクト管理計画の正式に管理されているコンポーネントは、このプロセスを通じて変更できます。ベンチマークへの変更は、最新バージョンのベンチマークに基づいて将来の状況に対処することのみが可能であり、過去のパフォーマンスを変更することはできません。これは、ベンチマークと過去のパフォーマンス データの整合性と完全性を保護するのに役立ちます。

変更ログ

正式に管理されているプロジェクト ドキュメントは、このプロセス中に変更できます。通常、このプロセス中に更新されるプロジェクト ドキュメントの 1 つのタイプは変更ログです。変更ログは、プロジェクト中に発生した変更を記録するために使用されます。

プロジェクト憲章には、プロジェクトの成功基準、承認要件、プロジェクト終了の承認者が文書化されています。

すべてのコンポーネント

仮説ログ

推定根拠

変更ログ

問題ログ

教訓登録

マイルストーンリスト

プロジェクトコミュニケーション記録

品質管理測定結果

品質レポート

要件文書

リスクレジスター

リスクレポート

段階的に進行したプロジェクトまたはキャンセルされたプロジェクトには、未完了または中間の成果物が含まれる場合があります。

ビジネスケース

給付管理計画

まず外側、それから内側

ファイル分析

回帰分析

トレンド分析

偏差分析

閉会報告会

お客様総括ミーティング

教訓総括会議

お祝い

教訓登録

プロジェクト活動中に生成され、最終バージョンとしてマークされたさまざまな文書 (計画、リスク影響評価などのさまざまなバージョン)

プロジェクトによって提供される製品、サービス、または結果は、ライフサイクル全体を通じて運用、保守、サポートするために別のチームまたは組織に転送できます。

目標達成（範囲、品質、コスト、スケジュールなど）

ビジネスニーズの達成（期待される効果、ビジネスニーズ）

管理プロセスの概要（リスクまたは問題とその解決策）

運用文書およびサポート文書。完了したプロジェクトまたはフェーズの成果物を運用や次のフェーズなどの他者に引き渡すために使用される正式な文書。

プロジェクトが正式に終了する前に、プロジェクトのすべての要件が満たされていることを確認するために、スコープ プロセスの結果として得られる顧客の承認文書と契約上の合意 (存在する場合) を検証します。

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

得られた教訓ナレッジベース

品質管理計画

プロジェクトのライフサイクルの説明

開発手法

代替案の分析

スコープ管理計画は、プロジェクトのスコープがどのように定義、開発、監視、制御、検証されるかを説明するプロジェクト管理計画のコンポーネントです。スコープ管理計画では、次のアクティビティに使用される管理プロセスを定義します。

要件管理計画は、プロジェクトと製品の要件を分析、文書化、管理する方法を説明するプロジェクト管理計画のコンポーネントです。 『Business Analysis for Practitioners: A Practical Guide』[7] によると、これを「ビジネス分析計画」と呼ぶ組織もあります。

スコープ管理計画

需要管理計画

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

仮説ログ

教訓登録

利害関係者登録

ビジネスケース

利害関係者のニーズはビジネスケースの目標と一致している必要があります (当初の意図)

ブレーンストーミング

インタビュー

フォーカスグループ

アンケート

ベンチマーク

ファイル分析

投票する

独裁的な意思決定

多基準の意思決定分析

親和性図

マインドマッピング

名目上のグループ手法

観察する/話す

ガイド

プロトタイピング手法では、目的の製品のモデルを構築し、実際に製品を製造する前に要件に関する早期フィードバックを求めます。プロトタイプには、ミニチュア製品、コンピュータで生成された 2 次元および 3 次元モデル、物理モデル、またはシミュレーションが含まれます。プロトタイプは有形のオブジェクトであるため、関係者は要件の抽象的な説明に限定されるのではなく、最終製品のモデルを体験できます。プロトタイプ手法はプログレッシブディテールの概念をサポートしており、モデル作成、ユーザーエクスペリエンス、フィードバック収集からプロトタイプ修正までの反復プロセスが必要です。十分なフィードバック ループの後、プロトタイプを通じて十分な要件情報を取得して、設計または製造段階に入ることができます。

ストーリーボード作成は、一連の画像または図を通じてシーケンスまたはナビゲーション パスを示すプロトタイピング手法です。ストーリーボードは、映画、広告、教育デザイン、アジャイルなどのソフトウェア開発プロジェクトなど、さまざまな業界のさまざまなプロジェクトで使用されています。ソフトウェア開発では、ストーリーボードはモックアップを使用して、Web ページ、画面、またはその他のユーザー インターフェイスのナビゲーション パスを示します。

要件文書では、さまざまな単一要件がプロジェクトに関連するビジネス ニーズをどのように満たすかを説明します。最初は高レベルの要件から始めて、要件に関する詳細な情報が入手可能になるにつれて要件を絞り込む場合があります。明確で (測定可能でテスト可能)、追跡可能で、完全で、調整されており、主要な関係者によって認識されることを望んでいる要件のみがベースラインとして機能します。要件文書にはさまざまな形式があります。関係者や優先順位ごとに分類されたすべての要件をリストした単純な文書もあれば、概要、詳細な説明、添付ファイルなどを含む詳細な文書もあります。

要件をビジネス目標またはプロジェクト目標にリンクして、各要件にビジネス価値があることを確認します。

要件追跡マトリックスは、プロジェクトのライフ サイクル全体にわたって要件を追跡する方法を提供し、要件文書内の承認された各要件がプロジェクトの終了時に確実に提供されるように支援します。

要件追跡マトリックスは、製品範囲の変更を管理するためのフレームワークも提供します。

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

スコープ管理計画

仮説ログ

要件文書

リスクレジスター

代替案の分析

多基準の意思決定分析

ガイド

製品分析は製品やサービスを定義するために使用でき、製品やサービスに関する質問と回答を行って、提供される製品の目的、特性、その他の側面を説明します。

すべてのアプリケーション分野には、高レベルの製品またはサービスの説明を意味のある成果物に変換するための、一般的に認識されている 1 つ以上の方法があります。

まず高レベルの要件を把握し、最終的な製品設計に必要な詳細レベルまで要件を調整します。

プロジェクト スコープ ステートメントは、プロジェクトのスコープ、主要な成果物、前提条件、および制約を説明するものです。プロジェクトと製品の範囲を含む範囲全体を文書化し、プロジェクトの成果物の詳細を示し、プロジェクトの範囲に関するプロジェクト関係者の合意を表します。関係者の期待を管理しやすくするために、プロジェクト スコープ ステートメントでは、どの作業がプロジェクトのスコープ外であるかを明確に示すことができます。

プロジェクト スコープ ステートメントにより、プロジェクト チームはより詳細に計画を立てることができ、実行中のプロジェクト チームの作業をガイドし、変更要求や追加作業がプロジェクトの境界を超えるかどうかを評価するためのベースラインを提供します。

プロジェクト スコープ ステートメントで何が行われるか、何が行われないかを記述する詳細レベルによって、プロジェクト管理チームがプロジェクト スコープ全体をどれだけ効果的に制御できるかが決まります。

詳細なプロジェクト スコープ ステートメントに含まれる内容 (直接リストすることも、他のドキュメントから参照することもできます)

仮説ログ

要件文書

要件追跡マトリックス

利害関係者登録

スコープ管理計画

プロジェクトスコープステートメント

要件文書

時間: プロジェクトのライフサイクルの各段階を分解の第 2 レベルとして使用し、製品とプロジェクトの成果物を第 3 レベルに配置します。

構造: 主な成果物を第 2 レベルの分解として使用

ワークパッケージ

プロジェクトスコープステートメント

WBS

ワークパッケージ

企画パッケージ

WBS

WBS辞書

仮説ログ

要件文書

スコープ管理計画

需要管理計画

スコープベースライン

教訓登録

品質レポート

要件文書

要件追跡マトリックス

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

補足: プロジェクト管理の成果ライン

検査とは、作業と成果物が要件と製品の合格基準を満たしているかどうかを判断するための、測定、レビュー、検証などの活動を指します。検査は、レビュー、製品レビュー、検査などと呼ばれることもあります。特定のアプリケーション分野では、これらの用語は独自の特定の意味を持ちます。

このプロセスで使用できる意思決定手法には投票が含まれます (ただし、これに限定されません)。プロジェクトチームおよびその他の利害関係者による承認が行われる場合、結論を形成するために投票が使用されます。

受け入れ基準を満たす成果物は、クライアントまたはスポンサーによって正式に承認される必要があります。関連当事者によるプロジェクト成果物の正式な受諾を証明する正式な文書をクライアントまたはスポンサーから入手する必要があります。これらの書類は、プロジェクトまたはフェーズの終了プロセスに提出されます。

作業パフォーマンス情報には、どの成果物が受け入れられ、何が失敗したか、およびその理由など、プロジェクトの進捗情報が含まれます。この情報は記録され、関係者に渡される必要があります。

完了したが正式な承認に合格していない成果物と失敗の理由を文書化する必要があります。これらの成果物には、変更リクエストと欠陥修正が必要になる場合があります。変更リクエストは、全体的な変更管理プロセスを実装することによってレビューおよび処理される必要があります。

教訓登録

要件文書

要件追跡マトリックス

金メッキとは、例えばあるソフトウェアにある機能を追加すると斬新でセールスポイントになると考えて、プロジェクトメンバーが勝手に機能を追加することです。この動作は、プロジェクトの金メッキ動作につながります。

スコープ クリープとは、顧客が継続的に小さな、目に見えない範囲の変更を提案することを指します。これを制御しないと、蓄積によりプロジェクトが確立されたスコープのベースラインから大幅に逸脱し、プロジェクトが制御を失って失敗します。

スコープ管理計画

需要管理計画

変更管理計画

構成管理計画

スコープベースライン

パフォーマンス測定ベンチマーク

教訓登録

要件文書

要件追跡マトリックス

偏差分析

トレンド分析

このプロセスによって生成される作業パフォーマンス情報は、受け取った変更の分類、特定された範囲の逸脱とその原因、逸脱のスケジュールとコストへの影響、将来の予測など、プロジェクトと製品の範囲の実装（範囲のベースラインに対する）に関する相互に関連した文脈化された情報です。スコープのパフォーマンス。

プロジェクトのパフォーマンスを分析した後、スコープとスケジュールのベースライン、またはプロジェクト管理計画のその他のコンポーネントに対して変更要求を行うことができます。変更リクエストは、全体的な変更管理プロセスの実装を通じてレビューされ、処理される必要があります。

スコープ管理計画

スコープベースライン

進行状況のベースライン

原価ベース

パフォーマンス測定ベンチマーク

教訓登録

要件文書

要件追跡マトリックス

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

スコープ管理計画

開発手法

過去の同様のプロジェクトに関する専門知識や関連トレーニングを受けた個人またはグループから意見を求める必要があります。

このプロセスに適したデータ分析手法には、代替分析が含まれます (ただし、これに限定されません)。代替案の分析には、使用するスケジュール方法の決定や、さまざまな方法をプロジェクトに統合する方法の決定が含まれる場合があります。また、スケジュールの詳細レベル、ローリング計画の期間、レビューと更新の頻度の決定も含まれる場合があります。スケジュール管理に必要な計画の詳細レベルと計画の更新に必要な時間とのバランスは、各プロジェクトに固有である必要があります。

プロジェクト チームは、スケジュール管理計画を作成するために計画会議を開催する場合があります。出席者には、プロジェクト マネージャー、プロジェクト スポンサー、選択されたプロジェクト チーム メンバー、選択された利害関係者、スケジュールまたは実行の所有者、およびその他の必要な担当者が含まれる場合があります。

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

リリースとイテレーションのスケジュールの長さ

正確さ

測定の単位

組織 プログラムリンク

プロジェクトスケジュールモデルのメンテナンス

制御閾値

パフォーマンス測定ルール

レポート形式

進捗管理計画

スコープベースライン

分解は、プロジェクトの範囲とプロジェクトの成果物を、より小さく管理しやすいコンポーネントに段階的に分割する手法です。アクティビティは、作業パッケージを完了するために必要な入力を表します。アクティビティを定義する プロセスの最終出力は、WBS を作成したプロセスの出力である成果物ではなく、アクティビティです。

WBS、WBS 辞書、およびアクティビティ リストは、最終的なアクティビティ リストを作成するための基礎として、WBS および WBS 辞書を基にして、順次または同時に編集できます。 WBS 内の各作業パッケージはアクティビティに分割され、対応する成果物がこれらのアクティビティを通じて完了できるようにする必要があります。チームメンバーを分解プロセスに参加させると、より適切で正確な結果が得られます。

ローリング計画は、より高いレベルで将来の作業を大まかに計画しながら、近い将来に実行する作業を詳細に計画する反復的な計画手法です。これは、アジャイルまたはウォーターフォール手法を使用した作業パッケージ、計画パッケージ、およびリリース計画に適した、進歩的で詳細な計画アプローチです。したがって、作業の詳細レベルはプロジェクトのライフサイクルのさまざまな段階で異なります。戦略計画の初期段階では、情報が十分に明確ではないため、作業パッケージは既知の詳細レベルまでしか分解できませんが、後でさらに多くの情報が得られると、近い将来に実装される作業パッケージを分解できるようになります。具体的な活動に取り入れます。

アクティビティ リストには、プロジェクトに必要なスケジュール アクティビティが含まれています。ローリング プランニングまたはアジャイル手法を使用するプロジェクトの場合、アクティビティ リストはプロジェクトの進行に応じて定期的に更新されます。アクティビティ リストには、プロジェクト チームのメンバーが何を達成する必要があるかを把握できるように、各アクティビティの識別と詳細な作業範囲が含まれています。

アクティビティ属性は、各アクティビティの複数の属性を指し、アクティビティの説明を拡張するために使用されます。アクティビティ属性は時間の経過とともに進化します。プロジェクトの初期段階では、アクティビティ属性には、一意のアクティビティ ID、WBS ID、およびアクティビティ タグまたは名前が含まれます。アクティビティ属性がコンパイルされるとき、アクティビティ属性には、アクティビティの説明、先行アクティビティ、後続アクティビティ、論理関係、リードタイムと遅延、リソース要件、必須の日付、制約と仮定。アクティビティ属性を使用すると、作業が実行される場所を特定したり、アクティビティが実行されるプロジェクト カレンダーや、関連するアクティビティ タイプを編集したりできます。アクティビティ属性はスケジュールの作成にも使用できます。アクティビティ属性に基づいて、レポート内でスケジュール アクティビティをさまざまな方法で選択、並べ替え、分類できます。

マイルストーンは、プロジェクト内の重要なポイントまたはイベントです。マイルストーン リストには、すべてのプロジェクト マイルストーンがリストされ、各マイルストーンが必須（契約で要求されるなど）かオプション（履歴情報に基づいて決定されるなど）かを示します。マイルストーンは重要な時点またはイベントを表すため、期間はゼロです。

進行状況のベースライン

原価ベース

進捗管理計画

スコープベースライン

アクティビティのプロパティ

アクティビティリスト

仮説ログ

マイルストーンリスト

先行ダイアグラム作成 (PDM) は、ノードを使用してアクティビティを表現し、アクティビティを接続する 1 つ以上の論理関係を使用して、アクティビティの実装順序を示すスケジュール モデルを作成する手法です。

PDM には 4 つの依存関係または論理関係が含まれます。先行アクティビティは、スケジュールの論理パス内で非開始アクティビティに先行するアクティビティです。後続アクティビティは、スケジュールの論理パス内のアクティビティに続くアクティビティです。

PDM関係

必須の依存関係

選択的な依存関係

外部依存関係

内部依存関係

収束と分岐を伴うアクティビティは、複数のアクティビティの影響を受けるか、影響を与える可能性があるため、より大きなリスクが生じます。 I アクティビティは複数の先行アクティビティがあるため「パス収束」と呼ばれ、K アクティビティは複数の後続アクティビティがあるため「パス分岐」と呼ばれます。

アクティビティのプロパティ

アクティビティリスト

仮説ログ

マイルストーンリスト

進捗管理計画

スコープベースライン

アクティビティのプロパティ

アクティビティリスト

仮説ログ

教訓登録

マイルストーンリスト

プロジェクト チームが作業指示書を発送します

リソースの内訳構造

リソースカレンダー

リソース要件

リスクレジスター

類似見積りは、類似の活動またはプロジェクトの履歴データを使用して、現在の活動またはプロジェクトの期間またはコストを見積もる手法です。類似見積もりは、過去の同様のプロジェクトのパラメータ値 (期間、予算、規模、重量、複雑さなど) に基づいて、将来のプロジェクトの同様のパラメータまたは指標を見積もります。期間を見積もる場合、類似の見積り手法では、過去の同様のプロジェクトの実際の期間を使用して、現在のプロジェクトの期間を見積もります。これは大まかな見積もり方法であり、プロジェクトの複雑さの既知の違いに合わせて調整する必要がある場合があります。プロジェクトの詳細が不十分な場合、プロジェクトの期間を見積もるためにアナログ見積もりがよく使用されます。

類似推定は、一般に他の推定手法に比べてコストも時間もかかりませんが、精度も低くなります。類似見積もりは、プロジェクト全体またはプロジェクトの一部に対して実行することも、他の見積もり方法と組み合わせて使用​​することもできます。過去の活動が表面的ではなく本質的に似ていて、見積もりに取り組むプロジェクト チームのメンバーが必要な専門知識を持っている場合、類似見積もりが最も信頼できます。

パラメトリック見積もりは、アルゴリズムを使用して履歴データとプロジェクト パラメータに基づいてコストまたは期間を計算する見積もり手法です。これは、コスト、予算、期間などの活動パラメーターを推定するために、過去のデータと他の変数 (建物建設 II の平方フィートなど) の間の統計的関係を使用することを指します。

期間は、実行する作業量と作業単位を完了するのに必要な工数を乗算して計算できます。たとえば、設計プロジェクトの場合は、図面の数に図面ごとに必要な工数を掛けます。また、ケーブル敷設プロジェクトの場合は、ケーブルの長さにケーブル敷設 1 メートル当たりに必要な工数を掛けます。使用されるリソースが 1 時間あたり 25 メートルのケーブルを敷設できる場合、1,000 メートルのケーブルを敷設する所要時間は 40 時間になります (1,000 メートルを 25 メートル/時間で割った値)。

パラメーター推定の精度は、パラメーター モデルの成熟度と基礎となるデータの信頼性に依存します。また、パラメトリック スケジュール見積もりは、プロジェクト全体またはプロジェクトの特定の部分に対して行うことができ、他の見積もり方法と組み合わせて使用​​できます。

プログラム評価およびレビュー手法 (PERT)。3 点推定法 (プログラム評価およびレビュー手法) とも呼ばれます。

期間の見積もりの​​精度は、見積もりの​​不確実性とリスクを考慮することで向上させることができます。 3 点推定を使用して、アクティビティ期間のおおよその範囲を定義します。

過去のデータが不足している場合や判定データを使用する場合には、想定される3点の分布に基づいて三角分布を用いて予想継続時間を推定し、予想継続時間の不確実性区間を記載します。

ボトムアップ見積もりは、WBS コンポーネントからの見積もりを下から上にレイヤーごとに集計することによって、プロジェクトの期間またはコストを見積もる方法です。アクティビティの所要時間を合理的な信頼度で見積もることができない場合は、アクティビティ内の作業をさらに調整し、特定の所要時間を見積もってから、これらのリソース要件の見積もりを集計して各アクティビティの所要時間を算出する必要があります。リソースの使用率に影響を与えるアクティビティ間に依存関係がある場合とない場合があります。依存関係が存在する場合は、対応するリソースの使用状況をアクティビティのリソース要件に記述し、記録する必要があります。

代替案の分析

埋蔵量分析

このプロセスに適した意思決定手法には、投票が含まれます (ただし、これに限定されません)。挙手は投票方法から派生した形式であり、アジャイル プロジェクトでよく使用されます。この手法を使用する場合、プロジェクト マネージャーはチーム メンバーに、拳を上げて反対を表明するか、5 本の指を差し出して完全な支持を表明することで、決定に対する支持のレベルを示すよう求めます。チームの意見に反対。プロジェクト マネージャーは、チーム全体が合意に達する (全員が 3 本指以上挙げる) か、次の決定に進むことに同意するまで挙手を続けます。

プロジェクト チームは、活動期間を見積もるために会合することがあります。アジャイル アプローチを使用する場合は、スプリントまたはイテレーション計画会議を開催して、優先順位付けされた製品バックログ (ユーザー ストーリー) について話し合い、チームが次のイテレーションでどのバックログに取り組むかを決定する必要があります。次に、チームはユーザー ストーリーを時間単位で見積もられる低レベルのタスクに分割し、その見積が期間 (反復) の観点からチームの能力に基づいて実現可能であることを確認します。このミーティングは通常、イテレーションの初日に開催され、製品所有者、開発チーム、プロジェクト マネージャーが参加し、ミーティングの結果にはイテレーションの未完了の項目、仮定、懸念事項、リスク、依存関係、決定事項、およびアクションが含まれます。

期間の見積もりは、アクティビティ、フェーズ、またはプロジェクトを完了するために必要な作業期間の定量的な評価です。これには遅延は含まれませんが、一定の範囲の変動を示します。

期間の見積もりに必要なサポート情報の量と種類は、アプリケーション分野によって異なります。詳細レベルに関係なく、サポート文書には、期間の見積もりがどのように導き出されたかを明確かつ完全に説明する必要があります。

期間の見積もりをサポートする情報としては、次のものが挙げられます。

アクティビティのプロパティ

仮説ログ

教訓登録

進捗管理計画

スコープベースライン

アクティビティのプロパティ

アクティビティリスト

仮説ログ

推定根拠

期間の見積もり

教訓登録

マイルストーンリスト

プロジェクト進捗ネットワーク図

プロジェクト チームが作業指示書を発送します

リソースカレンダー

リソース要件

リスクレジスター

サプライヤーは、契約上の約束を満たすためにプロジェクトの作業をどのように実行するかの詳細を策定する際に、プロジェクトのスケジュールに情報を提供します。

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

その他の分析には以下が含まれます (ただし、これらに限定されません)。

スケジュール ネットワーク分析は、実現可能なスケジュール モデルが作成されるまで継続される反復プロセスです。

クリティカル パス法は、スケジュール モデルにおける最短のプロジェクト期間を見積もり、論理ネットワーク パスのスケジュールの柔軟性を決定するために使用されます。このスケジュール ネットワーク分析テクノロジは、スケジュール ネットワーク パスに沿って順方向および逆方向の方法を使用して、リソースの制約を考慮せずにすべてのアクティビティの最早開始日、最早終了日、最遅開始日、最遅終了日を計算します。

クリティカル パスは、プロジェクト内の最も長い一連のアクティビティであり、プロジェクトの最短期間を決定します。最長のパスの合計浮動小数点は最小であり、通常はゼロです。取得される最も早い開始日と最も遅い開始日と終了日は必ずしもプロジェクト スケジュールではなく、スケジュールに入力された確立されたパラメーター (活動期間、論理関係、リード タイム、ラグ、その他の既知の制約) のみであることを示すモデリング後に取得される結果です。アクティビティはその期間内に実施できます。クリティカル パス法は、スケジュール モデルのクリティカル パス、合計フロートとフリー フロート、または論理ネットワーク パスのスケジュールの柔軟性を計算するために使用されます。

プロジェクトの完了日を遅らせたり、スケジュールの制約に違反したりすることなく、ネットワーク パス上でスケジュール アクティビティを最も早い開始日からどれだけ遅らせることができるかが、トータル フロートまたはスケジュールの柔軟性となります。通常、クリティカル パスの合計フロートはゼロです。先行グラフのシーケンス中、クリティカル パスの合計フロートは、使用される制約に応じて、正、ゼロ、または負になることがあります。逆方向計算で使用されるスケジュール制約が順方向計算で取得された最も早い完了日よりも遅いため、合計フロート時間は正になります。一方、期間と論理関係が最新の完了日制約に違反するため、合計フロート時間は負になります。ネガティブフロート分析は、遅れたスケジュールを軌道に戻す方法を見つけるのに役立つ手法です。進捗ネットワーク図には複数のサブクリティカル パスが含まれる場合があります。多くのソフトウェアでは、ユーザーがクリティカル パスを決定するための独自のパラメーターを定義できます。ネットワーク パスの合計フロートをゼロまたはプラスに維持するには、アクティビティ期間 (リソースを追加またはスコープを縮小できる場合)、論理関係 (選択的な依存関係を対象とする場合)、リード量とラグ量、またはその他のスケジュールの調整が必要になる場合があります。制約。合計フロートとフリー フロートが計算されると、フリー フロートは、後続アクティビティの最も早い開始日を遅らせたり、スケジュールの制約に違反したりすることなく、スケジュール アクティビティを遅延できる時間です。

前向き推論と後ろ向き推論

総フロートとフリーフロート

リソースのスムージング

リソースバランシング

What-if シナリオ分析

シミュレーション

スケジュール圧縮テクノロジーとは、プロジェクトの範囲を縮小することなく、スケジュールの制約、必須の日付、またはその他のスケジュール目標を満たすためにスケジュール期間を短縮または加速することを指します。負の浮動小数点数分析は便利なテクニックです。クリティカル パスは、フロートが最も少ないメソッドです。制約または必須の日付に違反すると、フロートの合計がマイナスになる可能性があります。

スケジュール ベースラインは、正式な変更管理プロセスを通じてのみ変更できる承認されたスケジュール モデルであり、実際の結果と比較するための基礎として使用されます。関係者による受け入れと承認を条件として、スケジュールのベースラインには、ベースラインの開始日とベースラインの終了日が含まれます。監視プロセス中に、実際の開始日と終了日が承認された基準日と比較され、逸脱が存在するかどうかが判断されます。スケジュールのベースラインは、プロジェクト管理計画の不可欠な部分です。

作業の進捗状況は、期限またはステータス日付によって表されます。単純なプロジェクトの場合、スケジュール プランには次の 3 つの形式があります。(1) マイルストーン スケジュール プラン (マイルストーン チャートとも呼ばれます)、(2) 一般スケジュール プラン (水平棒グラフとも呼ばれます)、(3) 詳細スケジュール プラン (プロジェクト スケジュール関連付けとも呼ばれます)。棒グラフ。

プロジェクト スケジュール モデルのスケジュール データは、スケジュールの記述と制御に使用される情報の集合です。スケジュール データには、少なくともスケジュール マイルストーン、スケジュール アクティビティ、アクティビティ属性、およびすべての既知の仮定と制約が含まれますが、その他の必要なデータはアプリケーション分野によって異なります。

サポート詳細としてよく利用できる情報には次のものがあります (ただし、これらに限定されません)

スケジュール データには、リソース ヒストグラム、キャッシュ フロー予測、および発注や配送スケジュールなどのその他の関連情報も含めることができます。

プロジェクト カレンダーでスケジュール アクティビティを実行できる稼働日と作業シフトを指定すると、スケジュール アクティビティの実行に使用できる期間 (日またはより小さな時間単位) と、使用できない期間が区別されます。一部のアクティビティには異なる作業期間が必要となるため、スケジュール モデル内では、プロジェクト スケジュールを計画するために複数のプロジェクト カレンダーを使用する必要がある場合があります。したがって、プロジェクト カレンダーを更新する必要がある場合があります。

進捗管理計画

原価ベース

アクティビティのプロパティ

仮説ログ

期間の見積もり

教訓登録

リソース要件

リスクレジスター

進捗管理計画

進行状況のベースライン

スコープベースライン

パフォーマンス測定ベンチマーク

教訓登録

プロジェクトカレンダー

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

リソースカレンダー

進捗データ

作業パフォーマンス データには、どのアクティビティが開始されたか、その進捗状況 (実際の期間、残りの期間、実際の完了率など)、どのアクティビティが完了したかなど、プロジェクトのステータスに関するデータが含まれます。

収益価値分析

反復バーンダウン チャート

人事考課

トレンド分析

偏差分析

What-if シナリオ分析

作業パフォーマンス情報には、スケジュールのベースラインと比較してプロジェクト作業がどのように実行されているかが含まれます。開始日と終了日の偏差と期間の偏差は、作業パッケージ レベルと制御アカウント レベルで計算できます。達成額分析を使用するプロジェクトの場合、進捗差異 (SV) とスケジュール パフォーマンス インデックス (SP) が作業パフォーマンス レポートに記録されます。

進捗状況の更新、または進捗予測とは、既存の情報や知識に基づいて、将来のプロジェクトの状況やイベントを推定または予測することを指します。プロジェクトが実行されると、作業パフォーマンス情報に基づいて予測が更新され、再発行される必要があります。この情報は、プロジェクトの過去のパフォーマンスに基づいており、是正措置または予防措置によって予想される将来のパフォーマンスに依存し、収益価値パフォーマンス指数や、将来プロジェクトに影響を与える可能性のあるスケジュールの予約情報が含まれる場合があります。

進捗管理計画

進行状況のベースライン

原価ベース

パフォーマンス測定ベンチマーク

仮説ログ

推定根拠

教訓登録

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

リソースカレンダー

リスクレジスター

進捗データ

進捗管理計画

リスク管理計画

コスト管理計画は、プロジェクトのコストがどのように計画、スケジュール、および制御されるかを説明するプロジェクト管理計画のコンポーネントです。コスト管理プロセスとそのツールと手法は、コスト管理計画に文書化する必要があります。

原価管理計画に記載すべき内容

組織 プログラムリンク

制御閾値

パフォーマンス測定ルール

レポート形式

その他の情報

コスト管理計画

品質管理計画

スコープベースライン

教訓登録

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

リソース要件

リスクレジスター

代替案の分析

埋蔵量分析

品質コスト

投票する

コスト見積もりには、プロジェクト作業を完了するために予想されるコストの定量的な見積もり、特定されたリスクに対処するための緊急時準備金、および計画外の作業に対処するための管理準備金が含まれます。コスト見積もりは要約または詳細に表示できます。コスト見積もりには、直接労働力、資材、設備、サービス、施設、情報技術を含む (ただしこれらに限定されない) プロジェクトで使用されるすべてのリソースと、資金調達コスト (金利を含む) などの特殊なコスト カテゴリが含まれる必要があります。インフレ手当、為替レートまたはコストの緊急準備金。間接費もプロジェクトの見積もりに含まれている場合は、活動レベル以上で請求​​できます。

コスト見積もりに必要なサポート情報の量と種類はアプリケーション分野によって異なります。その詳細レベルに関係なく、サポート文書にはコスト見積もりがどのように導き出されたかを明確かつ完全に説明する必要があります。

コスト見積もりの​​サポート情報としては、次のものが挙げられます。

仮説ログ

教訓登録

リスクレジスター

コスト管理計画

資源管理計画

スコープベースライン

推定根拠

原価見積

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

リスクレジスター

ビジネスケース

給付管理計画

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

埋蔵量分析

履歴情報を確認すると、パラメータまたはアナログ推定に役立ちます。履歴情報には、プロジェクトの総コストを予測する数学的モデルを構築するために使用されるさまざまなプロジェクトの特性 (パラメーター) が含まれる場合があります。これらの数学モデルは、単純なもの (たとえば、家の建設にかかる総コストは単位面積あたりの建設コストに依存する) もあれば、複雑なもの (たとえば、ソフトウェア開発プロジェクトのコスト モデルには複数の変数があり、それぞれが次の変数に影響される) もあります。多くの要因）。

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

ファイナンスとは、プロジェクトの資金を調達することを指します。長期にわたるインフラストラクチャー、産業および公共サービスのプロジェクトは、外部からの資金調達を求めることがよくあります。プロジェクトが外部資金を使用する場合、資金提供主体は満たさなければならない特定の要件を課す場合があります。

コストのベースラインに基づいて、総資金要件と定期的 (四半期または毎年など) の資金要件を決定します。原価ベースには、予測支出と予測負債の両方が含まれます。プロジェクトの資金は段階的に投資されることが多く、非均衡になる場合があり、上図に示すようなラダー パターンを示します。管理準備金がある場合、必要資金総額は原価ベースに管理準備金を加えたものと等しくなります。資金要件文書には、資金源も記載される場合があります。

原価見積

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

リスクレジスター

コスト管理計画

原価ベース

パフォーマンス測定ベンチマーク

教訓登録

収益価値分析

偏差分析

トレンド分析

埋蔵量分析