プロジェクトの範囲を定義、検証、制御するプロセスを書面で説明した範囲管理計画を作成します。

インプット: プロジェクト管理計画、プロジェクト憲章、企業環境要因、組織プロセス資産

出力: スコープ管理計画、要件管理計画

ツールとテクニック: 専門家の判断、ミーティング

プロジェクトの目標を達成するために、利害関係者のニーズと要件を特定、文書化、管理するプロセス

入力: 範囲管理計画、要件管理計画、利害関係者管理計画、プロジェクト憲章、利害関係者登録簿

出力: 要件ドキュメント、要件追跡マトリックス

ツールと手法: インタビュー、フォーカス グループ、ガイド付きワークショップ、グループ イノベーション手法、グループ意思決定手法、アンケート、観察、プロトタイピング、ベンチマーク、システム相互作用図、文書分析

詳細なプロジェクトと製品の説明を作成するプロセス

入力: 範囲管理計画、プロジェクト憲章、要件文書、組織プロセス資産

出力: プロジェクト スコープ ステートメント、プロジェクト ドキュメントの更新

ツールとテクニック: 専門家の判断、製品分析、代替生成、ガイド付きワークショップ

プロジェクトの成果物とプロジェクトの作業を、より小さく、より管理しやすいコンポーネントに分割するプロセス

入力: スコープ管理計画、プロジェクトスコープステートメント、要件文書、企業環境要因、組織プロセス資産

出力: スコープのベースライン、プロジェクト ファイルの更新

ツールとテクニック: 内訳、専門家の判断

完了したプロジェクト成果物を正式に受領するプロセス

入力: プロジェクト管理計画、要件文書、要件追跡マトリックス、確認された成果物、作業実績データ

出力: 受け入れられた成果物、変更要求、作業パフォーマンス情報、プロジェクト文書の更新

ツールと手法: 検査 (レビュー、製品レビュー、監査、ウォークスルー、検査)、グループ意思決定手法

プロジェクトと製品のスコープのステータスを監視し、スコープのベースライン変更のプロセスを管理します

入力: プロジェクト管理計画、要件文書、要件追跡マトリックス、作業パフォーマンス データ、組織プロセス資産

出力: 作業パフォーマンス情報、変更要求、プロジェクト管理計画の更新、プロジェクト文書の更新、組織プロセス資産の更新

ツールとテクニック: バイアス分析

面接では通常、面接対象者に事前に決められた質問や即興の質問をし、その回答を記録することが含まれます。

通常は 1 対 1 形式ですが、複数の面接対象者および/または複数の面接官が参加することもあります。

経験豊富なプロジェクト参加者、関係者、または対象分野の専門家にインタビューする

関係者は忙しく、時間を調整することが難しい場合が多い

インタビューは情報量が多く、記録するのが大変です。

コミュニケーションには多くのスキルと十分なドメイン知識などが必要です。

面接中に遭遇した問題

フォーカス グループは、事前に選択された関係者と対象分野の専門家を集めて、提案された製品、サービス、または結果に対する期待と態度を理解します。

フォーカス グループは、訓練を受けたモデレーターによる対話型のディスカッションを通じて実施されます。

ファシリテート型ワークショップでは、主要な部門横断的な関係者を会議に招待し、製品要件の議論と定義に重点を置いています。

ワークショップは、部門を超えた要件を迅速に定義し、関係者間の相違を調整するための重要な手法です。

品質機能を使用してガイド付きワークショップを実施することもできます

このテクノロジーの利点は、1 回の会議よりも早く問題を特定して解決できることです。

品質機能導入ワークショップの手順

ブレーンストーミング

名目上のグループ手法

デルフィ技法

コンセプト/マインドマップ

親和性図

多基準の意思決定分析

これは、望ましい結果を達成するための複数の将来の行動計画の評価です。

グループ意思決定手法を使用して、製品要件の開発、分類、優先順位付けを行うことができます。

個人が自分の環境でどのように仕事をし、プロセスを実装するかを直接観察することを指します。

ジョブ追跡とも呼ばれます

ビジネス要件: 追跡可能なビジネス目標とプロジェクト目標、組織のビジネス ルールの実行、組織の指導原則など

利害関係者のニーズ（組織の他の領域への影響、実行組織の内部または外部のグループへの影響、コミュニケーションと報告に対する利害関係者のニーズなど）

ソリューション要件には、機能要件と非機能要件、技術要件と標準準拠のニーズ、サポートとトレーニングのニーズ、品質のニーズ、レポートのニーズが含まれます。

サービス レベル、パフォーマンス、セキュリティ、コンプライアンスなどのプロジェクト要件と承認基準

過剰な要求

要件に関連する前提、依存関係、および制約

各構成アイテムの要件は、関連する製品 (またはコンポーネント) の要件まで双方向で追跡可能である必要があります。

要件の追跡には 5 つのタイプが含まれます

図の矢印は、需要追跡機能のコンタクト チェーンを表しており、需要の使用サイクル全体、つまり需要の提案から配信までのプロセス全体を追跡できます。

図の左半分では、ユーザーの元の要件を要件文書まで遡ることができるため、プロジェクト中またはプロジェクト後の変更によって影響を受ける要件を区別できます。ユースケースと機能要件間の追跡も可能

図の右半分では、プロジェクトの実装プロセス中に、製品要件が設計やテストなどの実装要素に変換されるため、

4 番目のタイプのコンタクト チェーンは、製品要素から要件文書まで遡り、プロジェクト チームのメンバーが各製品要素の存在理由を知ることができるようにします。

5 番目のタイプのコンタクト チェーンは、要件ドキュメント間の追跡です。この追跡により、さまざまな要件間の論理的な相関関係の処理が容易になり、要件の分解で発生する可能性のあるエラーや欠落がチェックされます。

要件マトリックスは、製品要件をそのソースからそれを満たす成果物まで結び付ける表です。

要件マトリックスには以下が含まれます

要件追跡マトリックスに記録される一般的な属性には、一意の識別子、要件のテキスト説明、要件を含める理由、所有者、ソース、優先度、バージョン、現在のステータス、およびステータスの日付が含まれます。

製品固有の質問をして回答し、開発する製品の流入、機能、その他の側面について説明します。

製品分析手法には、製品分解、システム分析、要件分析、システムエンジニアリング、価値エンジニアリング、価値分析が含まれます。

価値工学活動と価値分析活動はどちらも、商品の価値、機能、コストをさらに考えて探求し、グループ活動の形でアイデアをブレインストーミングすることです。

バリューエンジニアリングは、製品の開発および設計段階で実行される価値とコストの革新活動です。

代替案の分析

水平思考

製品範囲の説明

合否基準

成果物

プロジェクトの除外

制約

仮定

範囲

コミュニケーションの基本

開発の計画と管理

変更基準

計画の基本

これは、WBS の各ブランチの下部にある成果物またはプロジェクト作業コンポーネントです。

作業パッケージのサイズが完了するまでに少なくとも 8 時間かかり、合計完了時間が 80 時間を超えないようにすることをお勧めします。

これは、WBS の特定のレベルの要素である場合もあれば、作業パッケージよりも上位のレベルの要素である場合もあります。

制御アカウントは、範囲、予算 (リソース計画)、実際のコスト、スケジュールが統合され、収益と比較されてパフォーマンスを測定する管理制御ポイントです。

作業内容はわかっているものの、詳細な進捗アクティビティが不足している、管理アカウント下の WBS コンポーネントを指します。

計画パッケージは、制御アカウントの下、作業パッケージの上の WBS 要素です。

口座番号

各層のすべての要素の合計は、次の層の作業の合計になります。

各作業要素は 1 つのレベルに明確に割り当てる必要があり、複数のレベルに割り当てないでください。

WBS には、全員が何をすべきかを完全に理解できるように、作業の範囲を説明する必要があります。

成果物と関連作業を特定して分析する

WBSの構造と配置を決定する

上から下への分解

識別コードを開発して WBS コンポーネントに割り当てる

成果物の分解レベルが適切であることを検証する

機能的または技術的原則: 段階が異なれば、異なる要員が必要となるため、異なる要員の作業を分離することを考慮する必要があります。

組織構造

システムまたはサブシステム: システム全体がいくつかの主要なサブシステムに分割され、各サブシステムが分解されます。

WBS は成果物指向でなければなりません

WBS はプロジェクトの範囲内に収まる必要があります

WBS の基礎となる層は、計画と管理をサポートする必要があります。

誰かが WBS の要素に対して責任を負わなければなりません

WBS ガイダンス

WBS には、プロジェクト管理作業と下請け作業も含める必要があります。

WBS の作成には、プロジェクト関係者全員の参加とプロジェクト チーム メンバーの参加が必要です。

WBS が完成した後でも、変更や修正を行うことができます。