【高度な項目】プロジェクト全体管理、スコープ管理、進捗管理（トップテン管理）

【上級編】プロジェクト全体管理とスコープ管理

記事ディレクトリ

ここに画像の説明を挿入

1. プロジェクト全体の管理

1.1 全体管理の流れ

全体的な管理のためのプロセス、インプット、アウトプット、ツール、テクニックの要約表:

全体的なプロジェクト管理は、プロジェクト管理プロセスグループ内のさまざまなプロセスと活動を特定、定義、統合、統合、および調整するプロセスです。全体的な管理は、プロジェクトの要件、範囲、スケジュール、コスト、品質、人的資源、コミュニケーション、リスク、および調達を管理する責任があります; コスト) 人 (人的資源、利害関係者) スタイル (リスク) 調達 (調達)。
主に次の 6 つのプロセスがあります。 (マスター)
(1) プロジェクト憲章の作成:プロジェクト憲章である正式な文書を作成するプロセス。プロジェクトスケジュールを発行することにより、プロジェクトは正式に承認され、プロジェクトマネージャーはプロジェクト活動で組織のリソースを使用する権限が与えられます。
(2) プロジェクト管理計画の作成:すべてのサブ計画を定義、準備、調整し、それらを包括的なプロジェクト管理計画に統合するプロセス。項目 H の管理計画には、統合されたプロジェクトビジョンとサブ計画が含まれます。
(3) プロジェクト作業の指揮と管理:プロジェクト H の目的を達成するために、プロジェクト H の管理計画で決定された作業を指揮および実行し、承認された変更のプロセスを実施します。
(4) プロジェクト作業の監視:プロジェクト管理計画で特定されたパフォーマンス目標を達成するために、プロジェクトの進捗状況を追跡、レビュー、および報告するプロセス。
(5) 全体的な変更管理の実装:すべての変更要求をレビューし、成果物、組織プロセス資産、プロジェクトドキュメント、およびプロジェクト管理計画に対する変更管理の変更を承認し、変更処理の結果を伝達するプロセス。
(6) プロジェクトまたはフェーズのクローズ:すべてのプロジェクト管理プロセスグループのすべてのアクティビティを完了して、項目 H またはフェーズのプロセスを正式にクローズします。

1.2 プロジェクト憲章の策定（開始）

プロジェクト憲章とは何ですか？

l. Item H Charter は、プロジェクトを正式に承認する文書です。
プロジェクト憲章は、プロジェクトマネージャがプロジェクト活動で組織のリソースを使用することを許可するため、プロジェクトマネージャは、計画が開始される前のいつでも、できればプロジェクト憲章が作成されたときに任命されるべきです。
2. H項の憲章はプロジェクト実施機関が発行する. プロジェクトが憲章を発行した後、プロジェクトと組織の日常業務との関係が確立される。(マスター)プロジェクトマネージャーがリリースしたものではないことを覚えておいてください。
3.プロジェクト憲章の内容:
@プロジェクトの目的またはプロジェクトを承認する理由@測定可能な基準成功
目標と関連するプロジェクトの＠プロジェクトの承認要件＠任命されたプロジェクトマネージャーとその責任と権限。@丨スポンサーまたはプロジェクト憲章を承認するその他の人物の名前と権限。

プロジェクト憲章の作成方法

プロジェクト憲章の作成とは、プロジェクトまたはフェーズを正式に承認する文書を作成することであり、プロジェクト憲章の承認は、プロジェクトの正式な立ち上げを示します。プロジェクトでは、プロジェクトマネージャーをできるだけ早く特定して任命する必要があります。プロジェクト憲章は、プロジェクトマネージャーがプロジェクト活動で組織のリソースを使用することを承認するため、プロジェクトマネージャーはプロジェクト憲章の作成に参加する必要があります。
プロジェクト憲章は、スポンサー、プロジェクト管理オフィス、ポートフォリオ運営委員会など、プロジェクト外の人物によって承認されます。
プロジェクトの開始者または開始者は、特定の権限を持ち、プロジェクトに資金を提供できる必要があります。彼らはプロジェクト憲章を自分で作成するか、プロジェクトマネージャーに作成を許可します。プロジェクト憲章は発起人によって署名され、プロジェクトの承認を示します。プロジェクト憲章を策定することで、プロジェクトを組織の戦略や日常業務に結び付けることができます
作業明細書は、対応するプロジェクトによって提供される製品またはサービスのテキスト記述です。
項目 H の場合、スポンサーまたはスポンサーは、ビジネスニーズ、製品またはサービスの要件に基づいて作業明細書を提供します。何千もの場所で、作業明細書は顧客の入札文書の一部です。たとえば、提案の招待、情報の要求、入札の招待または契約の一部です。
作業明細書とは、＠ビジネス要件、＠製品スコープステートメント、＠戦略計画の内容を指します。
ビジネス環境要因: [組織プロセス資産 (エンタープライズ環境要因とも呼ばれる) の違いに注意してください。これらは、プロジェクトマネージャーの制御を超えており、調整することはできません。組織外の一般的な情報源]
(1) 組織または会社の文化と構成。
( 2 ) 政府または業界の基準 (管理部門の規則および規則、製品基準、品質基準、プロセス基準など)。
(3) インフラストラクチャ (既存のソフトウェアおよびハードウェアインフラストラクチャなど)。
(4) 既存の人的資源 (設計、開発、法務、契約、調達などのスキル、専門知識、知識など)。
(5) 人事管理（採用・解雇の指針、社員の業績評価、研修記録等）
(6) 当社の業務承認制度。
(7) 市況。
( 8 ) プロジェクト利害関係者のリスク許容度。
(9) 商用データベース (標準コスト見積もりデータ、業界リスク調査情報、リスクデータベースなど)。
( 10 ) プロジェクト管理情報システム
組織プロセス資産:
(1)プロセスと手順: 組織基準; @標準ガイドライン、テンプレート、作業指示書; @プロジェクト固有のニーズを満たすための標準プロセスの改訂ガイドライン; @組織コミュニケーション要件、報告システム; ＠プロジェクト終了のガイドラインまたは要件; ＠財務管理手順; ＠問題および欠陥
管理手順; ＠変更管理手順; ＠リスク管理手順; @プロセス測定データベース; @経験学習システム; @問題および欠陥管理データベース; @構成管理知識ベース; @財務データベース.
ビジネス環境要因と組織プロセス資産を区別する：
＠調整して選択できるものは組織プロセス資産選択できず、適応することしかできないものはビジネス環境要因
＠システムを持つものは一般的にビジネス環境要因（例：作業承認システム、プロジェクト管理情報システム）
@手順を持つものは、一般的に組織のプロセス資産です（例：財務管理手順、変更管理手順、リスク管理手順）
財務面
3 つの主なプロジェクト財務価値評価方法には、正味現在価値分析、投資収益、および投資収益率分析が含まれます。- 3 つの方法の計算をマスターする必要があります。
(1) 正味現在価値の分析 (57 on 18)
(2) 投資収益率の分析: ROI は、純利益を投資額で割った値です。ROI が大きいほど良い。ROI= (総割引収入 - 総割引コスト) / 割引コスト (18 アンダー 31)
( 3 ) 投資回収期間の分析 - 静的および動的投資回収期間を計算する必要があります
プロジェクトキックオフミーティングは
、プロジェクトマネージャーによって組織および開催されます. プロジェクトキックオフミーティングを開催する主な目的は、プロジェクトの主要な利害関係者に、プロジェクトの目標、範囲、ニーズ、背景、およびそれぞれの責任を明確にすることです。当局
一般的に言えば、目標は定量化され、測定可能でなければなりません。プロジェクト H には次のような特徴があります:
プロジェクトの目標には優先順位が異なります; @project の目標には階層 (マスタリー) があり、プロジェクトの特性の違いがあります。
プロジェクトマネジメントの賛否や効率性を計る目的や、プロジェクトメンバーのモチベーションを高める手段として目標を設定する場合、以下の点に注意する必要があります。 (1) 達成目標と制約目標を分離する
。
(2) 目的と手段を区別する。
( 3 ) 定量化または達成できない H 基準を策定しないでください。
(4) プロジェクトマネージャーの努力をそらさない。
ファシリテーションテクニック: ブレーンストーミング、コンフリクト解決、問題解決、およびミーティング管理は、ファシリテーターがチームや個人がプロジェクト活動を完了するのを支援するために使用できる重要なテクニックです。

1.3 プロジェクト管理計画の作成 (計画)

プロジェクト管理計画とは

プロジェクト管理計画には、通常、
プロジェクト範囲管理計画、スケジュール管理計画、コスト管理計画、品質管理計画、プロセス改善計画、人員配置管理計画、コミュニケーション管理計画、リスク管理計画、調達管理計画、およびその他のサブ計画が含まれます。プロジェクト管理計画は詳細にすることができ、1 つまたは複数の部分計画やその他の項目で構成することができます。各サブプログラムおよびその他のコンポーネントの詳細レベルは、特定のプロジェクトのニーズを満たすように調整されています。
その他のコンポーネントには、マイルストーンリスト、リソースカレンダー、スケジュールベースライン、コストベースライン、品質ベースライン、リスクレジスタなどを含めることができます。（マスター）
プロジェクト管理計画は、選択された各プロセスの実装レベルで、計画プロセスグループの各計画サブプロセスの全体的な出力を記録します。@ これらのプロセスを実装するために使用されるツールと技術の説明。@ 特定のプロジェクトを管理する際に選択されたプロセスを使用する方法と手段。これには、プロセス間の依存関係と相互作用、および重要な証拠と結果が含まれます。＠Ｈ項の目的を達成するために行う作業の方法と方法＠モニタリングの方法と方法が変わる。@ 構成管理を実装する方法と方法。＠効果測定ベンチマークを実施し、それを完全に維持する方法と方法を使用する。＠プロジェクト関係者間のコミュニケーションのニーズと技術。マルチステージプロジェクトの選択したプロジェクトライフサイクルとプロジェクトフェーズを丸で囲みます。未解決の問題の解決を促進し、未解決の決定に対処するために、トップマネジメントによるコンテンツ、範囲、およびタイミングの重要なレビュー。
プロジェクト管理計画とドキュメントの違い、計画には 13+3 のサブ計画が含まれます

プロジェクト管理計画を作成するにはどうすればよいですか?

プロジェクト H の管理計画が初めて策定されたとき、Shanqian のすべての側面に関する情報はあまり明確ではなかったので、プロジェクトマネージャーはマクロの観点からプロジェクトの主要な管理アイデアを把握するだけで済みました。全体的な変更管理プロセスを通じて、プロジェクト管理計画を修正します。
補完的な原則:すべての利害関係者の参加(完全な参加);漸進的な精度(反復)
変更管理システムとは、プロジェクトの成果物と文書を管理、変更、および承認する
方法と手段を決定するために使用される、正式に文書化されたプロセス全体です。変更管理システムは、構成管理システムのサブシステムです。

1.4 プロジェクトの実行を指示および管理する (実行)

l. 承認された変更要求は、是正措置、予防措置、または欠陥の修正である場合があります。含む：

♦ ©是正措置:プロジェクト実施の期待される結果が常にプロジェクト管理計画の要件を満たすようにする(
実際に発生した逸脱について)。
♦ @予防措置:潜在的な悪影響の可能性を減らします(将来の逸脱の可能性)。
♦ @ 欠陥修正:品質プロセスで見つかった製品欠陥を修正します(製品または製品コンポーネント、欠陥修正措置はプロジェクトの
品質問題のみに適用されます)。

2. プロジェクトマネージャーの権限には、権限、影響力、知識の3 つの側面があります。

(1)権限とは、プロジェクトマネージャーが組織内での地位に基づいて保持する権限です。権威が他者に認められる程度は限られており、
他者の行動への影響は一般的に大きくありません。
(2)影響力は、個人の知識、経験、個性、カリスマ性に基づく. プロジェクトマネージャーは、この
種の力を使用して、プロジェクトに直接関与していないが協力したい人々に影響を与えることができます.
( 3 )知識はより重要です。「調査がなければ、発言する権利はありません。」
プロジェクト H (または情報) のすべての側面を包括的、タイムリーかつ正確に把握することは、判断、決定、およびプロジェクト作業の指導の基礎となります。私

1.5 プロジェクト作業の監視と統合変更管理の実施 (監視)

統合変更管理の実装

l. 全体的な変更管理プロセスは、プロジェクト全体を通して実行されます。Shanqian プロジェクトがプロジェクト管理計画に従って正確に実行されることはめったにないため、変更管理は不可欠です。（マスター）
多くの場合、全体的な変更管理プロセスには、変更要求の承認または拒否を担当する変更管理委員会が含まれます。変更要求は、プロジェクトマネージャーによってレビューおよび評価され、CCB によって承認または拒否されます。
2. 構成管理活動には、@構成の識別、@構成ステータスの記録、@構成の検証と監査が含まれます。

1.6 プロジェクトまたはフェーズのクローズ (クロージング)

l.プロジェクトまたはフェーズの終了とは、プロジェクトまたはフェーズを正式に終了するために、すべてのプロジェクト管理プロセスグループのすべてのアクティビティを完了するプロセスです
。このプロセスの主な効果は、教訓を引き出し、正式にプロジェクト作業を終了し、新しい作業のために組織のリソースを解放することです。
2. プロジェクトの最後に、プロジェクトマネージャーは、前の段階の完了情報を確認して、すべての項目 H が完了し、プロジェクトの目的が達成されたことを確認する必要があります。プロジェクトが完了前に早期に終了した場合、プロジェクトまたはフェーズのクローズプロセスでは、早期終了の理由を調査して文書化する手順も必要になります。上記の目的を達成するために、プロジェクトマネージャーは、すべての適切な利害関係者をこのプロセスに参加するよう招待する必要があります。(マスター)

プロジェクト終了の内容：管理終了、契約終了

(1) 管理の締めくくり: ドキュメントの分類を適切に行い、プロジェクトが終了してメンテナンス期間に移行できることを外部に宣言し、経験と教訓をまとめます
。（2）契約の締結：正式な承認、製品の承認、契約に従って、プロジェクトチームと所有者は、契約のすべての要件が完了したかどうか、およびプロジェクトを完了できるかどうかを確認します。
受入段階の業務内容：受入テスト、システム試運転、システム文書受入、プロジェクト最終検査：システム検査
5つのシステムインテグレーションプロジェクトの場合、関連するドキュメントには、
①システムインテグレーションプロジェクトの紹介、②システムインテグレーションプロジェクトの最終レポート、③情報システム取扱説明書、④情報システム保守マニュアル、⑤ソフトウェアおよびハードウェア製品マニュアル、品質保証証明書が含まれている必要があります。

2. プロジェクトスコープ管理

2.1 スコープ管理とは

プロジェクト範囲の管理は、6 つの管理プロセスを通じて実現されます。
(1) 範囲管理の計画: プロジェクト範囲を定義、確認、および管理する方法のプロセスを記述します。
(2) 要件の収集: 項目 H の目標を達成するために、プロジェクトの利害関係者の関連する要件を明確にし、記録するプロセス。
(3) 範囲を定義する: 製品の範囲とプロジェクトの範囲を詳細に記述し、将来のプロジェクト決定の基礎としてプロジェクト範囲ステートメントを作成します。
(4) WBS の作成: プロジェクト H の作業全体を、より小さく管理しやすいコンポーネントに分解して、トップダウンの分解構造を形成します。
(5) 確認の範囲：完成した成果物の正式な受理。
(6) スコープコントロール: プロジェクトと製品のスコープステータスを監視し、スコープベースラインの変更を管理します。

プロジェクトスコープマネジメントの考え方

1. プロジェクトスコープ管理では、次の 3 つの作業を行う必要があります。1
. プロジェクトの境界を明確にする、2. プロジェクトの実行を監視する、3. プロジェクトのスコープが広がるのを防ぐ。
2.プロダクトスコープとプロジェクトスコープ:
(1)プロダクトスコープとは、プロダクトまたはサービスが含むべき機能を指し、プロジェクトスコープとは、プロダクトを提供できるようにするためにプロジェクトが行わなければならない作業を指します。
(2)プロダクトスコープはプロジェクトスコープの基礎プロダクトスコープの定義はプロダクト要件の記述であり、プロジェクトスコープの定義はプロジェクトマネジメントプランを作成するための基礎です。 2 つのスコープの適用。
3)プロジェクトのスコープベースラインは、承認されたプロジェクトスコープステートメント、WBS および WBS コードです。プロジェクトスコープが完全であるかどうかの判断は、スコープベンチマークに対して測定されます。製品範囲の完成は、製品が製品説明を満たしているかどうかによって判断されます。
(4) プロダクトスコープの記述は、プロジェクトスコープステートメントの重要な部分であるため、プロダクトスコープの変更後、最初にプロジェクトのスコープが影響を受けます。

2.2 プロジェクトの範囲を管理するには? （予定）

1. 計画範囲管理

l.範囲管理計画を作成し、プロジェクトの範囲を定義、確認、および管理する方法のプロセスを書面で説明し、プロジェクト全体で範囲を管理する方法についてガイダンスと指示を提供します。スコープ管理計画には、プロジェクト管理チームのすべてのメンバーの参加が必要です。（マスター）
2. スコープ管理計画の内容: プロジェクトスコープステートメントの作成方法。
＠スコープステートメントに従ってWBSを作成する方法。
＠WBSの維持・承認方法
@ 完了したプロジェクト H の成果物を確認し、正式に承認する方法。
＠プロジェクトスコープステートメントの変更をどのように処理するか、この作業は全体的な変更管理プロセスの実装に直接関係します。
たとえば、WBS の作成ガイドラインには次の内容が含まれる場合があります (ただし、これらに限定されません)
。
(2) WBS がすべての項目 H の作業について論理的な内訳を提供しているかどうかを確認します。
( 3 ) 特定の各層の総コストが、次の層の構成要素のコストの合計に等しいことを保証します。
(4) 全体の適応性と継続性の観点から WBS を検討する。
( 5 ) すべての仕事の責任は、個人または組織単位に割り当てる必要があります。
3. スコープマネジメント計画書には、プロジェクトスコープをどのように管理するか、項目 H のスコープをプロジェクトの要件と一致するように変更する方法などが記述されています。変更する頻度、変更する量。範囲管理計画には、変更の範囲がどのように決定されるか、および変更がどのカテゴリに分類されるかについての明確な説明も含める必要があります。
プロジェクトスコープマネジメントプランは、プロジェクトマネジメントプランに含まれている場合もあれば、別の項目である場合もあります。プロジェクトに応じて、詳細または一般、公式または非公式の場合があります。.
スコープマネジメント計画がないと、要件の変更や設計ミスなどの「予期しない」状況など、スコープマネジメントの問題に直面したときのプロジェクトチームの行動指針が不足してしまいます。スコープマネジメント計画は、プロジェクトスコープマネジメントのガイドです。
4.要件管理はプロセス全体を実行します。その最も基本的なタスクは、要件を明確にし、プロジェクトチームとユーザーが合意に達するようにすること、つまり要件のベースラインを確立することです。さらに、一連の要件追跡機能を確立して、すべてのユーザー要件が正しく適用されるようにする必要があります。要件が変更された場合、影響範囲を完全に制御でき、製品と要件の一貫性を常に維持できます。 . (マスター)
5. 要件管理計画は、プロジェクトのライフサイクル全体を通じて、要件を分析、記録、および管理する方法を記述します。研修計画、＠数千人を要件管理に巻き込むための戦略、＠プロジェクトスコープと要件の矛盾を判断するための基準と是正手順、＠要件追跡構造、＠構成管理活動（習熟）
7. 明確で (測定可能でテスト可能)、追跡可能で、完全で、調整されており、主要な利害関係者によって認識されることを望んでいる要件のみをベンチマークとして使用できます。

2. 要件を収集する

要件には以下が含まれます:
.•@ビジネス要件: 組織全体の高レベルのニーズ。
.• @Stakeholder Requirements: 利害関係者または利害関係者グループのニーズを指します。＠Solution Requirements
• ＠Transition Requirements: データ変換やトレーニングの必要性など、現在の状態から将来の状態に移行するために必要な一時的な機能。
• @Project の要件: プロジェクトが満たすべきアクション、プロセス、またはその他の条件。
• @Quality Requirements: プロジェクトの成果物が正常に完了したこと、またはその他のプロジェクト要件が満たされていることを確認するために使用される条件または基準。QFD は、品質要件を基本要件、期待要件、予期しない要件に細分化します。
2.要件を収集するためのツールと手法には、主に、
インタビュー、フォーカスグループ、ガイド付きセミナー、グループイノベーション手法、グループ意思決定手法、アンケート調査、観察、プロトタイピング、ベンチマーキング、システム相互作用図、およびファイル分析が含まれます@Interview
: Formalまたは利害関係者との直接の会話を通じて情報を入手する非公式な方法は、要求を収集する最も基本的な手段です♦ @Focus Group : 事前に選択された利害関係者と主題を集めます提案された製品、サービス、または結果に対する期待と態度。訓練を受けたモデレーターがインタラクティブなディスカッションをリードします。フォーカスグループは、1 対 1 のインタビューよりも集中する傾向があります。1 対 1 ではなくグループ面接であり、6 ～ 10 人の面接対象者が関与する可能性があります。インタビュアーからの質問に対して、インタビュイーはインタビュイー同士で活発な議論を行い、より価値のある意見を求めます。♦ @Guided Seminar : 集中的な議論と製品要件の定義。ワークショップは、機能横断的な要件を迅速に定義し、何千もの利害関係者間の違いを調整するための重要な手法です。グループの相互作用の特性により、効果的なガイド付きセミナーは、信頼を築き、関係を促進し、コミュニケーションを改善し、参加者間の合意を促進するのに役立ちます。♦ @Group Innovation Technology : ブレーンストーミング、ノミナルグループテクノロジー、Delphi テクノロジー、コンセプト/マインドマップ、アフィニティマップ、多基準意思決定分析などを含む、プロジェクトと製品の要件を特定するためのグループ活動を組織することを指します。(30 歳未満の 20 名) • ブレーンストーミング法: アイデアを共有し、アイデアをブレインストーミングします。これはブレインストーミング方法の応用を深めたものであり、より構造化されたブレインストーミング方法です; ( 30 歳未満の 19 人) ( 30 歳未満の 21 人)

• Delphi テクノロジー: 匿名またはバックツーバックの方法を使用して、予測プロセス中に数回のフィードバックを提供します。これにより、専門家の意見が徐々に収束し、データの偏りが減り、個人がデータに不適切な影響を与えるのを防ぐことができます。結果。
• マインドマップとも呼ばれるマインドマップ: ブレーンストーミングで得られたアイデアを簡単な絵に結び付けて、これらのアイデアの共通点と相違点を反映し、新しいアイデアに導きます。
• アフィニティダイアグラムは KJ 法とも呼ばれます: ある問題に対する経験、知識、アイデア、意見などのさまざまな言語およびテキストデータを十分に収集し、それらをグラフにまとめて、相互のアフィニティに従ってこれらのデータを要約および整理することです。問題を明確にし、統一的な理解を求め、メリットのある解決方法を模索します。
• 多基準意思決定分析: 意思決定マトリックスを使用し、リスクレベル、不確実性、および価値便益などのさまざまな基準を確立するための体系的な分析方法を使用して、多くのスキームを評価およびランク付けする手法です。
♦ @グループの意思決定: 特定の望ましい結果を達成するために、複数の将来のアクションプランを評価します。グループの意思決定手法を使用して、製品要件を開発したり、製品要件を分類および優先順位付けしたりできます。グループの意思決定を達成する方法は次のとおりです。@ — 全会一致、@ 多数決原則、@ 相対多数原則、@ 独裁 —
@) 全会一致: 全員が特定の行動方針に同意します。
— @) 多数決の原則: グループ内の 50% 以上の人々の支持を得て決定を下すことができます。— 不変）相対多数の原則：一部の人々の支持
を得られなくても、グループ内の相対多数の意見に基づいて決定が下されます。この原則は通常、2 つ以上の候補がある場合に使用されます。たとえば、特定のソフトウェアコンポーネントの機能に対して
3 つの実現スキームがある場合(A、B、C とマーク)、35% の人がプラン C に同意し、 25%がプランCに賛成し、プランAが最終的に決定されます。— @) 独裁: 1 人の人物 (プロジェクトマネージャーなど) がグループの意思決定を行います。♦ @

ベンチマーク
:ベストプラクティスを特定し、改善のためのアイデアを生成し、パフォーマンス測定の基礎を提供するために、実際のまたは計画されたプラクティスを他の同様の組織のプラクティス (プロセス、運用手順など) と比較すること。
要件の収集プロセスの出力は、要件ドキュメントと要件トレーサビリティマトリックスです。
要件ドキュメントには、さまざまな個々の要件がプロジェクトに関連するビジネス要件をどのように満たすかが記述されています。要件ドキュメントは、すべての要件を利害関係者および優先順位別にリストした単純なドキュメントにすることも、エグゼクティブサマリー、詳細な説明、および添付ファイルを含む詳細ドキュメントにすることもできます。
要件ドキュメントの内容には、次のものが含まれます。
要件管理
には、要件ベースラインの管理、項目 H の計画と要件の一貫性の維持、個々の要件と要件ドキュメントのバージョンの管理、要件とリンクチェーン間のリンクの管理など、製品開発中に要件の一貫性と正確性を維持するためのすべてのアクティビティが含まれます。リンク、または個々の要件とプロジェクトの他の成果物との間の依存関係を管理し、ベースライン内の要件のステータスを追跡します。
トレーサビリティとは、個々の要件と他の要素との間の依存関係および論理的な接続を確立および追跡することです。
各構成アイテムの要件には、関連する製品 (またはコンポーネント) の要件への双方向のトレーサビリティが必要です。いわゆる双方向追跡には、順方向追跡と逆方向追跡が含まれます。
順方向追跡とは、要件 1 の各要件が「次の」作業セクション (結果) で見つかるかどうかを調べて、対応関係を見つける (要件が見落とされないようにするため) ことを指します。、バイアスを行う)
リバーストラッキングはリバーストラッキングとも呼ばれ、設計ドキュメント、製品コンポーネント、テストドキュメント、およびその他の作業結果が要件ファイルでソースを見つけることができるかどうかを確認することを指します (理由を理解するには、要件のソースを確認してください)。要件が作成された場合、ソースの背景とその理由)
具体的には、要件追跡には5つのタイプがあり、図に示すように、矢印は要件追跡機能の関係チェーンを表しており、要件使用のサイクル全体、つまり要件提案から納品までのプロセス全体を追跡できます。（マスター）
要件のトレーサビリティマトリックス要件と他の製品要素の間の連鎖を表す最も一般的な方法は、要件のトレーサビリティ (機能) マトリックスを使用することです。

3. スコープを定義する

4. 作業分解図 (WBS) を作成する

l.マイルストーンは、成果物またはフェーズの正式な完了を示します。重要なチェックポイントはマイルストーン、重要なマイルストーンはベースライン
2.ワークパッケージは、さまざまな人または組織単位に簡単かつ完全に割り当てる必要があります。作業パッケージは、事業者が自分の仕事、努力すべきこと、引き受けるべき責任を明確にするために、非常に具体的である必要があります。経験則として、8/80 ルール (80 時間ルール) では、作業パッケージのサイズが完了するまでに少なくとも 8 時間かかる必要があり、合計完了時間が 80 時間を超えないようにすることを推奨しています (習熟度)。
3.コントロールアカウントは管理コントロールポイントです。
このコントロールポイントでは、スコープ、予算 (リソース計画)、実際のコスト、およびスケジュールが統合され、アーンドバリューと比較されてパフォーマンスが測定されます。
コントロールアカウントは、WBS の特定のレベルの要素であり、作業パッケージまたは作業パッケージよりも高いレベルの要素である可能性があります。後者の場合、コントロールアカウントには複数のワークパッケージが含まれますが、ワークパッケージは 1 つのコントロールアカウントにのみ属します。項目 H 管理チームは、項目 H の実装をコントロールアカウントで評価します。つまり、コントロールアカウントの対応する要素の下で、プロジェクトの実装を計画と比較して、実装を評価し、逸脱を発見して修正します。
4.計画パッケージは、統制勘定の下にある WBS コンポーネントを参照します。作業内容はわかっていますが、詳細なスケジュール活動はまだ利用できません。
計画パッケージは、統制勘定の下で作業パッケージの上にある WBS 要素です。計画パッケージは一時的に計画に使用されますが、状況が明らかになると、計画パッケージは最終的に作業パッケージと対応する特定の活動に分解されます。
5. WBS ディクショナリには、アカウントコードの識別、ジョブの説明、仮定と制約、責任者または組織単位、スケジュールのマイルストーン、関連するスケジュールの活動、必要なリソース、コストの見積もり、品質要件、受け入れ基準、技術参照、契約情報が含まれます。（マスター）（WBS辞書は、実際にはWBSの各要素の説明である新華辞書に相当します）
6. 分解とは、プロジェクトの成果物とプロジェクトの作業を、より小さく管理しやすいコンポーネントに分解するための手法です。
7. プロジェクト作業全体を作業パッケージに分解するには、通常、次のアクティビティが必要です。
@成果物と関連作業を特定して分析する。
@WBSの構成と配置を決める。
＠上から下へレイヤーごとに分解。
@WBS コンポーネントの識別コードを開発して割り当てる。
@ 成果物の分解の程度が適切であることを確認します。
8. WBS を作成する際の作業分割の原則には以下が含まれます。
@機能的または技術的な原則: WBS を作成する場合、異なる担当者の作業を分離することを考慮する必要があります。
@組織構造: 多機能プロジェクト組織の場合、WBS はプロジェクトの組織構造にも適応する必要があります。
@システムまたはサブシステム: システム全体がいくつかの主要なサブシステムに分割され、最初のサブシステムが分解されます。
WBSの分解方法：
＠）プロジェクトのライフサイクルの各段階を分解の第2レベルとし、成果物とプロジェクトの成果物を第3レベルに配置
＠主な成果物を分解の第2レベルとする＠
統合プロジェクトチーム以外の誰かによって行われる可能性があります組織によって実装されるさまざまなコンポーネント (たとえば、アウトソーシング作業)、およびその後、
アウトソーシング作業の一環として、販売者は対応する契約を準備する必要があります WBS
WBS はプロジェクトチームメンバーの責任ではなく、すべてのプロジェクトチームメンバー、ユーザー、およびプロジェクト関係者によって完成され、全会一致で確認されなければなりません)
。ツリー構造図の WBS li!t::me、zhiru、jieyeguai ですが、大きな、、、^、および hengme については、プロジェクト (小さなプロジェクト) の全体像を示すのが難しく、修復するのは容易ではありません。表形式の直感性は比較的低いですが、プロジェクトのすべての作業要素を反映できます
WBS 分解は 8 つの側面に注意を払います。
@WBS は成果物指向でなければなりません: すべての下位レベル要素の合計が上位レベル要素の 100% を表す必要があります。
@WBS は、プロジェクトの範囲内に収まる必要があります。WBS には、プロジェクトの成果物を完成させるために必要な活動のみを含める必要があります。WBS
の最下層は、計画と管理をサポートする必要があります。WBS は、プロジェクト管理計画とプロジェクト範囲の間の架け橋であり、
WBS の最下層は、プロジェクト管理計画をサポートするだけでなく、管理者がプロジェクトのスケジュールと予算を監視および管理できるようにします。
@WBS の要素は、1 人の人物のみが所有する必要がありますが、実際には複数の人物が関与している場合があります。
@WBS のガイダンスによると、WBS は Danbi 内で制御する必要があります。もちろん、大規模なプロジェクトでは 6 つ以上のレイヤーを持つことができます。
@WBS には、プロジェクト管理作業 (管理はプロジェクト固有の作業の一部であるため) と下請け作業を含める必要があります。
@WBS の開発には、プロジェクトチームメンバーを含むすべての (主要な) プロジェクト利害関係者の参加が必要です。
@WBS は決まったものではありません。WBS が完成した後の作業では、WBS の修正が必要になる場合があります。
プロジェクトの WBS 分解が完了すると、プロジェクト部門は完成した WBS を確認し、合意に達する必要があります。WBS の目的と使用法は、主に次の 8 つの側面に反映されています
。
(2) プロジェクトの境界を明確に定義する
(3) 各独立したユニットに人員を割り当て、これらの人員の責任を明確にし、項目 H を完了するために必要な技術的および人的資源を決定する。
( 4 ) 独立したユニットの時間、コスト、およびリソースの需要を見積もり、見積もりの精度を向上させます。
( 5 ) 計画、予算、スケジュール調整、およびコスト管理の共通基盤を築き、プロジェクトの進捗と管理の基準を決定します。
( 6 ) 項目 H の作業をプロジェクトの財務会計にリンクします。
(7) 作業内容と作業順序を決定し、プロジェクトを具体的な作業タスクに分解し、作業タスクの論理的な順序に従って項目 H を実施します。
(8) デマンドクリープの防止に役立ちます。

2.3 妥当性確認と管理（モニタリング）の範囲

5. スコープの確認

l. スコープの確認は、プロジェクトの完成した成果物を正式に受け入れるプロセスです。これには、成果物が満足のいく形で完成し、クライアントまたはスポンサーによって正式に承認されたことを確認するために、クライアントまたはスポンサーと一緒に成果物をレビューすることが含まれます。（学び）
2. 範囲を確認するための主なツールと手法は、検査とグループの意思決定手法です。
検査は、レビュー、レビュー、監査、ウォークスルー、検査、テストなどとも呼ばれ、作業と成果物が要件と製品の受け入れ基準を満たしているかどうかを判断するための測定、レビュー、確認などの活動を指します。（マスター）
3. スコープがプロジェクトの最初から最後まで続くことを確認します。
4. 範囲を確認するための一般的な手順: 範囲確認をいつ実行する必要があるかを決定する＠範囲確認に必要な入力を特定する＠範囲を正式に承認するための基準と要素を決定する＠範囲の組織的手順を決定する確認会＠スコープ確認会を開催
利害関係者の懸念: (マスター)
(1) 管理: 関係するプロジェクトのスコープは、プロジェクトの進捗状況、資金、およびリソースに対するスコープの影響を指します。(31 未満の 20) (31 未満の 21) l
(2) 顧客: 顧客は、製品の範囲、およびアイテム H の成果物が製品またはサービスを完成させるのに十分かどうかについて懸念しています。{2 1 on 31)
(3) プロジェクトマネージャー: 成果物が十分であり、完了する必要があるかどうか、時間、資金、およびリソースが十分かどうか、主要な潜在的リスク、および準備ソリューションに焦点を当てます。
( 4 ) プロジェクトチームメンバー: プロジェクトスコープ内の参加要素と責任要素に注意し、スコープ内の時間を定義して労働時間が十分かどうか、プロジェクト H のスコープ内に複数の仕事があるかどうかを確認します。これらの仕事は対立があるところです
6. プロジェクトでは、顧客とプロジェクトチームのメンバーは、多くの場合、現在のバージョンにすべての機能と機能を追加する意欲を持っています。これは、何千ものプロジェクトにとって潜在的なリスクであり、組織と顧客に損害と損失をもたらします。スコープ確認作業において、プロジェクトスコープステートメントやWBSに抜けや誤りがあった場合は、間違った内容をプロジェクトチームに明確に指摘し、修正を提案する必要があります。プロジェクトチームは、修正された意見に従って、プロジェクトスコープステートメントと WBS を修正する必要があります。また、スコープ確認の過程でスコープ変更要求が出される場合があり、スコープ変更要求が承認された場合、プロジェクトスコープステートメントとWBSも改訂されます。
7. 成果物の検証は、成果物が完成したかどうかを目的とする. プロジェクト (またはフェーズ) の終わりに、開始者または顧客は、成果物が完成したかどうかを強調して、成果物を検証します. 確認範囲はプロジェクトを対象としています.成果物、および顧客または開始者は、ダーティセクションの受け入れプロセスで確認します。
検証の範囲と品質管理の違いは次のとおりです
: (1) 検証の範囲は、主に成果物が顧客またはスポンサーによって受け入れられることを強調します; 標準)。
( 2 ) 品質管理は、通常、スコープを確認する前に実行されますが、同時に実行することもできます; 範囲確認の範囲は、段階の最後に実行され、品質管理は必ずしもステージの最後に実行されます。ステージの終わり。
(3) 品質管理は、執行組織の対応する品質部門によって実施される内部検査であり、確認の範囲は、外部の利害関係者 (顧客またはスポンサー) によるプロジェクト成果物の検査および受け入れです。
スコープ確認とプロジェクトクロージャの違いは次のとおりです
。 (1) スコープ確認とプロジェクトクロージャの作業は段階では行われませんが、スコープ確認は
成果物の検証と受け入れを重視し、プロジェクトクロージャはプロジェクトの完了 (または段階) を重視します。 ) 行われるプロセス作業。
( 2 ) 確認の範囲とプロジェクトの終了の両方に受け入れ作業があり、確認の範囲はプロジェクト成果物の受け入れを強調し、プロジェクトの終了は製品の受け入れを強調します。

6. 制御範囲

スコープの制御は、プロジェクトと製品のスコープステータスを監視し、スコープベースラインへの変更を管理するプロセスであり、その主な役割は、プロジェクト全体でスコープベースラインを維持することです。
プロジェクトの範囲を制御するには、要求されたすべての変更、推奨される是正措置、または予防措置が、統合変更管理の実装プロセスによって対処されるようにする必要があります。実際に変更が発生した場合、これらの変更を管理するためにスコープコントロールプロセスも使用されます。
プロジェクト範囲の変更の主な理由は、プロジェクト Hの外部環境が変化したことです。たとえば、 (理解)
(1) 政府の政策課題。
( 2 ) プロジェクトスコープの計画が完全かつ詳細ではなく、特定のエラーまたは省略があります。
(3) 新しい技術、新しい方法、または新しいスキームが市場に登場するか、設計者が提唱する。
(4) プロジェクトの実施組織自体が変わる。
(5) 項目 H、プロジェクトの製品またはサービスに対する顧客の要件が変更された場合
(時間、コスト、およびリソースを調整せずに) 製品またはプロジェクトのスコープを無制限に拡大することを、スコープクリープと呼びます。[顧客は要求と変更を続け、最終的な成果物は要件を満たしていません!
金メッキ: プロジェクトの実装者は、多くの場合、新しいテクノロジを試したり、情報システムプロジェクトに追加したりすることをいとわない] 変更は避けられず、コントロールスコーププロセスはスコープ変更コントロールに依存します。システム、スコープの変更管理とは、変更を承認するために必要な文書、追跡システム、および承認レベルを含む、プロジェクトの範囲の変更を管理および承認するプロセスを指します。
スコープ変更制御の作業:
(1) スコープ変更につながる要因に影響を与え、これらの要因を好ましい方向に発展させようとします。
( 2 ) スコープの変更が発生したかどうかを判断します。
( 3 ) スコープの変更が発生したときに実際の変更を管理し、要求されたすべての変更がプロジェクトの全体的な変更管理プロセスに従って確実に処理されるようにする

3. 進捗管理（時間管理）

スケジュール管理は、667-4343-644 で 7 番目のコースです。これは、計画、アクティビティの定義、順序付け、リソースの見積もり、期間の見積もり、スケジュールの確立、およびスケジュールの制御を含む、管理スケジュールを確立するプロセスです。

3.1 計画進捗管理（計画）

プロジェクト管理計画と組み合わせて、手のひらプロセスで上級幹部によって設定された計画と承認要件を調べ、プロジェクトの時間管理のさまざまなプロセス、進行を計画するための方法とツールを指定し、形式とガイドラインを決定します。

3.2 活動の定義（計画）

スコープベースラインでアクティビティとマイルストーンを分割します。何をすべきかを正確に定義することです。
最初に WBS を見つけ、[Scope Benchmarks] で、Scope Benchmarks が必要であることを忘れないでください。Scope 仕様のように分厚いものを用意するだけでは十分ではありません。それぞれの特定のアクティビティ (Activity List) は、より具体的であるほど良いため、それぞれの小さなアクティビティを作成する必要があります。複雑になりすぎないように、分割を続け、最後に各アクティビティに説明を追加し ([アクティビティ属性])、チェックポイントを設定します ( [マイルストーンリスト])。
ツールと手法: 専門家の判断、代替案の分析、公開された推定データ、ボトムアップ推定

3.3 シーケンス活動（計画）

活動に優先順位がある場合は優先順位を付ける必要がありますが、製品ごとに特徴が異なるため、先ほどの【活動一覧】を【活動属性】と【マイルストーン一覧】に整理し、ソフトロジックとハードロジックを考えるのが一番簡単です（例えば、家を建てるにはまず畑を耕さなければならない）ので、【スコープ指定】を読ませる。
理解した上で順番を並べ始めました並べ方は? (進行ネットワーク図) を使って並べて円を描いたり、活動名を記入したり、矢印で接続したりしてくださいもっと活動があると考えられます、そして図はクモの巣のようです（進行ネットワーク図）]。
ツールとテクニック: シーケンシャルマッピング (FS/FF/SS/SF)、依存関係の決定、リードとラグ

3.4 活動資源の見積もり（計画）

各アクティビティで使用する人数とアイテム (どちらも調達可能) を決定します。アクティビティにリソースのタグを付けるには、リソースカレンダーを参照してください。活動間の関係の順序を整理するには、物事が何であるかを知る必要がありますが、リソースは不要であると推定されます. 個々の具体的なもの自体 [活動リスト] [活動属性] を見て、誰が割り当てられるかがわかります.もちろん【リソースカレンダー】で確認してみてください。
「推定コスト」の出力 [アクティビティコストの見積もり] を調べ、次に [リスクレジスター] を調べ、最後に、各アクティビティを誰が実行し、何を使用するかを含むリストを作成する必要があります。これは (アクティビティリソースRequirements ] だけでなく、割り当てられたリソースカテゴリ (Resource Breakdown Structure RBS] も含まれます。これは非常に直感的で管理が容易です。
ツールと手法: 専門家の判断、代替案の分析、公開された推定データ、ボトムアップ推定

3.5 活動期間の見積もり（計画）

リソースのニーズをマークするには、スコープステートメントとリソースカレンダーを参照してください。各アクティビティの実行にかかる時間を決定します。
同じように、アクティビティリストと属性テーブルを見つけます [アクティビティリスト] [アクティビティ属性] を入力します。たとえば、「ログイン Web ページデザイン」は Zhang San によって設計されています。Zhang San のレベルはどうですか。[リソースカレンダー] に移動する必要があります。見てみると、私はジュニアエンジニアなのでゆっくりできるはずなので、長めの時間を設定するのですが、【Scope Statement】から非常に重要であることが示されています。属性テーブルの後に追加されます (推定活動期間]
ツールと手法: 専門家の判断、類推推定、パラメーター推定、3 点推定、グループ意思決定手法 (コンセンサス (Delphi 手法)、多数決原理、相対多数原理、独裁を含む)、リザーブ分析

3.6 スケジュールを立てる（計画）

以前のすべてのドキュメントを要約して、スケジュールを決定します。
ツールと進捗モデル (マイクロソフトプロジェクトやガントチャートなど) を選択し、進捗の描画を開始します。
[アクティビティリストを [アクティビティ属性] に、[ネットワークダイアグラムをスケジュールに] [アクティビティリソース要件を] [リソースの内訳構造に] [リソースカレンダーに] [アクティビティの所要時間の見積もりに] 【プロジェクト要員配置先】【リスク登録簿】の【スコープ明細書】を確認し、未記入事項がないか確認し、全て記入されていれば【進捗計画書】を取得し、進捗計画から標準化された評価文書（進捗仕様書）であり、同時に進捗データ、プロジェクトカレンダーも形成されます。
ツールとテクニック: クリティカルパス法、クリティカルチェーン法、リソース最適化テクニック: リソースバランシングとリソーススムージング、スケジュール圧縮: クラッシュとファストトラッキング

3.7 進捗管理（モニタリング）

プロジェクトの進捗状況をリアルタイムで監視し、進捗状況を判断し、現在の状況に応じて進捗を予測し、計画どおりに実行できるかどうかを確認します。
これは管理範囲と同じです。日々収集する指導・実施作業から生成される【作業実績データ】と【スケジュール計画】と「進捗ベンチマーク」を比較すると、「なぜ見えないのか」が分かります。本来は【プロジェクトマネジメント計画】に隠れていた「進捗ベンチマーク」を最終的に取得し（作業実績情報）、問題があれば修正を提案する（変更依頼）
ツールとテクニック: パフォーマンスレビュー (トレンド分析、クリティカルパス法、クリティカルチェーン、アーンドバリューマネジメント)、リソース最適化テクニック: リソースの平準化とリソースの平滑化、リードとラグ、スケジュールの圧縮: クラッシュとトラッキング