2.1.1. プロジェクト憲章の作成は、プロジェクトまたはフェーズを正式に承認する文書です。プロジェクト憲章の承認は、プロジェクトの開始者によって署名され、プロジェクトが承認されたことを意味します。憲章に基づいて、プロジェクトは組織の戦略的および日常的な運用作業にリンクすることができます。

2.1.2. プロジェクト憲章プロセスの基礎: 契約書、プロジェクト作業明細書、ビジネスケース、ビジネス環境要因、組織プロセス資産。使用されるツールとテクニック: 専門家の判断、指導テクニック。結果: プロジェクト憲章

2.1.3. プロジェクト憲章に含まれる内容: プロジェクトの測定可能な目標と関連する成功基準、プロジェクトの全体的なマイルストーンのスケジュール、 (プロジェクトの成功を評価するためにどのような基準が使用されるか、誰がプロジェクトの成功を結論付けるか、誰がプロジェクトの終了を承認するか)、およびその責任と権限、スポンサーまたはその他の承認者の名前、および権限。プロジェクト憲章

2.2.1. 契約: 契約は、プロジェクト開始の当初の意図を定義します。契約には、契約書、覚書、サービス品質契約、合意書、意向書、口頭合意、電子メール、またはその他の書面による合意など、さまざまな形式があります。

2.2.2. プロジェクトの作業明細書: 作業明細書は、プロジェクトによって提供される製品またはサービスに対応するテキストの説明です。外部プロジェクトの場合、作業明細書は、提案への招待や依頼など、顧客の入札文書の一部です。情報、入札への招待、または契約の一部。作業範囲記述書には、ビジネス要件、製品範囲記述書、および戦略計画が含まれます。

2.2.3. ビジネス ケース: ビジネス ケースまたは同様の文書は、プロジェクトが投資する価値があるかどうかを判断するために商業的な観点から必要な情報を提供します。通常、ビジネス ニーズと費用対効果の分析はビジネス ケースに含まれます。

2.2.4. ビジネス環境要因: プロジェクト憲章を作成するときは、プロジェクトの周囲に存在し、プロジェクトの成功に影響を与えるあらゆる組織のビジネス環境要因とシステムを考慮する必要があります。これには次のものが含まれます。組織または会社の文化と構造。政府または業界の標準（管理部門の規則や規制、製品標準、品質標準、プロセス標準など）（既存のソフトウェアおよびハードウェア インフラストラクチャなど）、既存の人的リソース（設計、開発、法務、契約および調達など）; 人事管理（雇用および解雇のガイドライン、従業員の業績評価および研修記録など）; プロジェクト関係者のリスク許容度、業界リスク調査情報およびリスクデータベース）; プロジェクト管理情報システム。

2.2.5. 組織プロセス資産: ① 作業を組織するプロセスと手順：組織の標準プロセス、プロジェクトの特定のニーズに応じて組織の標準プロセスを変更するための指針とガイドライン。組織的なコミュニケーション要件、財務管理手順、問​​題および欠陥の管理手順、および変更管理手順、および承認と発行の手順。労働許可。 ② 組織の全体的な情報の保存および検索の知識ベース: プロセスおよび製品の測定データを収集および提供するために使用される、問題および欠陥管理の知識ベース。 。

2.3.1. プロジェクト憲章の作成に必要な基礎を評価するために、専門家の判断がよく使用されます。

2.4.1. 組織がどのプロジェクトを選択するかを決定する

2.4.2. 一般に、便益測定方法と数学的モデルに分けられ、プロジェクトの財務価値の 3 つの主要な評価方法には、正味現在価値分析、投資収益および投資回収率分析が含まれます。

2.4.3. 正味現在価値分析 NPV: 正味現在価値分析は、プロジェクトの予想される純金銭的損益を計算するために、予想される将来のすべての現金流入および流出を現在価値に変換することを指します。

2.4.4. 投資収益率分析 ROI：純利益を投資額で割った値です。 ROIが大きいほど良い

2.4.5. 投資回収期間分析: 純投資を純キャッシュ流入で補うのにかかる時間です。平たく言えば、累積的な便益が累積的なコストとその後のコストを超えるまでにどれくらいの時間がかかるかを意味します。プロジェクトの財務上の期待では、通常、IT プロジェクトの投資回収期間が 3 年以内、場合によっては 2 年以内であることが求められます。

2.5.1. プロジェクトのキックオフ ミーティングは通常、プロジェクト マネージャーによって組織され、開催されます。主な目的は、プロジェクトの主要な関係者に目標、範囲、ニーズ、背景、およびそれぞれの責任と権限を明確にすることです。

2.5.2. プロジェクトのキックオフ会議を適切に開催するには、次の 5 つの側面を行う必要があります。会議の目標を決定し、会議の主要な議題を明確にして、会議の参加者に通知します。 。

2.6.1. 目標は定量化され、測定可能である必要があります

2.6.2. 達成目標と制約目標の間には、矛盾や矛盾が生じることがよくあります。一般的に言えば、制約の目標は結果の目標に取って代わられるべきです。

2.7.1. 促進テクニックを使用して、プロジェクト憲章の作成をガイドできます。ブレーンストーミング、対立管理、問題解決、会議管理はすべて、チームや個人がプロジェクト活動を完了するのを支援するためにファシリテーターが使用できる重要なテクニックです。

3.1.1. プロジェクト管理計画には、プロジェクト管理チームによって選択されたさまざまなプロジェクト管理プロセスの実装レベル、およびこれらのプロセスの実装に使用されるツールと手法の説明が含まれます。特定のプロジェクトを管理するプロセス。これには、プロセス間の依存関係と相互作用、およびプロジェクトの目標を達成するために実行される作業の方法と方法が含まれます。効果測定 プロジェクトの関係者間のコミュニケーションのニーズと手法、未解決の問題の解決を促進し、未解決の問題の決定に対処するためのトップマネジメントの取り組み。内容、範囲、タイミング。

3.1.2. プロジェクト管理計画は、プロジェクトを実行、監視、制御し、終了する方法と手段を決定します。

3.2.1. 基礎: 他のプロセスの組織プロセス資産からの成果物。

3.2.2. ツールとテクニック: 専門家の判断、指導テクニック

3.2.3. 結果: プロジェクト管理計画

3.3.1. 計画システムと制御システムで構成

3.3.2. 構成管理システム: 変更提案の提出、変更提案のレビューおよび承認システムの追跡、変更の承認レベルの決定、および承認された変更方法の確認に使用されます。構成管理システムは、次のことについての技術的および管理的な指導と監督を提供する、正式に文書化された手順の集合でもあります。 製品またはコンポーネントの機能的および物理的特性の特定と文書化、それらの特性に対するすべての変更の管理、および各変更の記録と報告。要件への準拠を検証するための補助製品またはコンポーネントの実装ステータス。現在一般的に使用されている構成管理ソフトウェア ツール: CVS、VSS、ClearCase

3.3.3. 変更管理システム: プロジェクトの成果物と文書を管理、変更、承認する方法と手段を決定する、正式に文書化されたプロセスの集合。変更管理システムは構成管理システムのサブシステムです

4.1.1. プロジェクト管理計画: プロジェクト計画を実行するための主な基盤はプロジェクト管理計画です。

4.1.2. 承認された変更リクエスト: 承認された変更リクエストは、全体的な変更管理プロセスの実装の出力です。

4.1.3. 事業環境要因

4.1.4. 組織プロセス資産

4.2.1. 専門家の判断: プロジェクト管理計画の実行を指導および管理するために必要な入力を評価するために使用されます。

4.2.2. プロジェクト管理情報システム: スケジュール計画ツール、作業承認システム、構成管理システム、情報収集およびリリース システム、または他のオンライン オートメーション システムへのネットワーク インターフェイスを提供します。主要業績評価指標 (KPI) の収集とレポートの自動化にも使用できます。

4.2.3. 会議: 通常、情報交換、プログラム評価、またはプログラム設計の意思決定の 3 種類の雰囲気があります。

4.3.1. 成果物: 成果物とは、プロジェクトを完了するために作成および納品する必要がある、プロジェクト管理計画文書に文書化されたサービスを提供する固有の検証可能な製品、結果、または機能です。

4.3.2. 作業パフォーマンス データ: プロジェクト作業の実行中に実行される各アクティビティから収集された生の観察と測定値です。

4.3.3. 変更リクエスト: ドキュメント、成果物、またはベースラインを変更するための正式な提案。

4.3.4. プロジェクト管理計画の更新

4.3.5. プロジェクト文書の更新: 要件文書、プロジェクトログ、リスク登録簿、利害関係者登録簿。

5.1.1. プロジェクト管理計画

5.1.2. 進捗予測

5.1.3. コスト予測

5.1.4. 確認された変更点

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

5.1.6. 事業環境要因

5.1.7. 組織プロセス資産

5.2.1. 専門家の判断: プロジェクト管理チームは専門家の判断を使用して、各監視プロセスから提供される情報を解釈します。

5.2.2. 分析手法: プロジェクト管理では、分析手法を使用して、プロジェクトまたは環境変数の変化の可能性およびそれらの他の変数との関係に基づいて潜在的な結果を予測します。プロジェクトで使用できる分析手法には、回帰分析、根本原因分析、故障モードおよび影響分析などがあります。積立金の傾向分析、ギャップ分析。

5.2.3. プロジェクト管理情報システム: プロジェクト管理チームは、プロジェクト管理情報システムを使用して、プロジェクト管理計画およびスケジュール内のアクティビティの実行を監視します。プロジェクト管理情報システムは、必要に応じて新たな予測を行うためにも使用されます。

5.2.4. 会議: 会議は、対面または仮想、公式または非公式のいずれかで行うことができます。出席者には、プロジェクト チームのメンバー、利害関係者、およびプロジェクトに関与または影響を受けるその他の人々が含まれる場合があります。会議の種類には、ユーザー グループ ミーティングやユーザー レビュー ミーティングなどがあります (ただし、これらに限定されません)。

5.3.1. 変更リクエスト: 実際の状況と計画された要件を比較することにより、プロジェクトの範囲や製品の範囲を拡大、調整、または削減したり、品質要件やスケジュールまたはコストのベースラインを増加、調整、または削減したりするために、変更リクエストが必要になる場合があります。変更には次のものが含まれます (ただし、これらに限定されません): 是正措置、プロジェクト作業のパフォーマンスをプロジェクト管理計画に準拠させるために行われる目的のある活動、予防措置、プロジェクト作業の将来のパフォーマンスがプロジェクト管理計画と一致していることを確認するために行われる目的のある活動。プロジェクト管理計画活動。欠陥修復。一貫性のない製品または製品コンポーネントを修正するために実行される目的のある活動。

5.3.2. 職務遂行レポート: 意思決定、行動の実行、または懸念の表明を目的として職務遂行情報をまとめた物理的または電子的なプロジェクト文書。

5.3.3. プロジェクト管理計画の更新: プロジェクト作業の監視中に提案された変更は、プロジェクト管理計画全体に影響を与える可能性があります。

5.3.4. プロジェクト文書の更新: スケジュールとコストの予測、作業実績レポート、問題ログ

6.1.1. プロジェクト管理計画: 範囲管理計画の範囲変更手順、範囲変更管理計画の製品定義。

6.1.2. 作業パフォーマンス レポート: リソースの可用性、スケジュールとコストのデータ、稼得額管理レポート、バーン チャートまたはバーンダウン チャート

6.1.3. 変更リクエスト: すべての監視プロセスと多くの実行プロセスが「変更リクエスト」を出力します。

6.1.4. ビジネス環境要因: プロジェクト管理情報システム

6.1.5. 組織プロセス資産

6.2.1. 専門家の判断: 専門家の判断と専門知識は、さまざまな技術上および管理上の問題で利用でき、さまざまな情報源から入手できます。

6.2.2. 会議: 通常、変更管理会議と呼ばれます。プロジェクトのニーズに応じて、変更管理委員会が開催され、変更要求を検討し、承認、拒否、またはその他の決定を下す場合があります。

6.2.3. 変更管理ツール: 構成と変更管理を容易にするために、いくつかの手動または自動ツールを使用できます。変更リクエストとその後の決定を管理するためのツールが利用可能です。

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

6.3.2. 変更ログ: 変更ログは、プロジェクト中に発生した変更を記録するために使用されます。拒否された変更リクエストも変更ログに記録されます。

6.3.3. プロジェクト管理計画の更新: 個々のサブ計画は正式な変更管理プロセスの対象となります。ベースラインの変更は、過去のパフォーマンスではなく将来の状況にのみ基づいて行うことができるため、ベースラインと過去のパフォーマンス データの整合性を保護するのに役立ちます。

6.3.4. プロジェクトドキュメントの更新: プロジェクトの正式な変更管理プロセスの対象となるすべてのドキュメント

7.1.1. プロジェクト管理計画: プロジェクト管理計画は、プロジェクトの完了の基準を設定する、プロジェクト マネージャーとプロジェクト スポンサーの間の合意です。

7.1.2. 受領のための成果物: 承認された製品仕様、納品受領書、および作業実績文書。

7.1.3. 組織プロセス資産: プロジェクトまたはフェーズの終了ガイドラインまたは要件 (管理手順、プロジェクト監査、プロジェクトの評価および引き継ぎ基準など)過去のプロジェクト選択の決定結果に関する情報、過去のプロジェクトの実績に関する情報、およびリスク管理活動から得られる情報）

7.2.1. 行政閉鎖活動は専門家の判断に基づいて行われます。関連する専門家は、プロジェクトまたはフェーズの終了が該当する基準に準拠していることを確認します。

7.2.2. 分析手法: 回帰分析、傾向分析。

7.2.3. ミーティング

7.3.1. 最終製品、サービス、または成果の引き渡し: 承認されたプロジェクトによって提出された最終製品、サービス、または成果の正式な受け入れと引き渡し。

7.3.2. 組織プロセス資産の更新: プロジェクトのアーカイブ、プロジェクト活動中に生成されるさまざまな文書、プロジェクトまたはフェーズの終了文書、履歴情報、教訓情報は、将来のプロジェクトまたはフェーズで使用するために教訓知識ベースに保存されます。

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

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

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

成果物

検証された成果物

受領のための成果物

最終製品、結果、またはサービス