大規模なプロジェクトの場合は、要件トレーサビリティマトリックスを作成することをお勧めします。詳細はこちら：

プロジェクト管理における要件トレーサビリティマトリックス（例+テンプレート）

プロセス＃2：要件を取り締まりスコープを定義する方法

要件は次のとおりです。 ：

「pmbasics101.comWebサイトには、電子メールを収集し、その代わりにPDFドキュメントを送信する機能が必要です。」

この要件を満たすには何が必要ですか？

1. メールサービスプロバイダーを選択します。
2. アカウントを作成します。
3. メールを収集するためのフォームを設計します。
4. 設計したフォームを実装します。
5. メールサービスプロバイダーからプラグインをインストールします。
6. PDFドキュメントをアップロードします。
7. フォームをアクティブ化します。
8. フォームをテストします。

これは必要なアクションのリストにすぎません。成果物と作業パッケージとして正しく配置すると、次のようになります。

1. Email Opt -フォーム内
   1.1メールサービスプロバイダーに関するレポート
   1.2承認されたフォームデザイン
   1.3テスト環境でのオプトインフォーム
   1.4テストレポート

つまり、どのようにその1文の要件から実際の作業範囲に到達しますか？

A）関連する経験または知識を持っている人を見つけることができます

それは利害関係者、顧客、または外部の可能性がありますコンサルタント、対象分野の専門家、またはその他の関係者。

したがって、あなたの目標は、プロジェクトチームからそれらを取得するか、連絡を取り合って連絡を取ることです。彼らはすでに解決策を持っているかもしれません。

そうでなければ、あなたは指示やアドバイスを得るかもしれません。これは、広く適用される基本的な手法です。

B）製品分析を実行する

サービスや結果ではなく、製品を作成する必要がある場合に適用できます。

この手法は、製品価値の分解に焦点を当てています。 WBSがスコープで行うのと同じように。

さらに、人間工学的および機能的な観点から製品を分析する必要があります。次に、パフォーマンス要件に準拠する材料またはプロセスを決定します。

25製品分析の例

全体として、目標は具体的な成果物を定義することです。

C）代替案生成手法を使用する

この手法は、プロジェクトの性質に関する専門知識がある場合にうまく機能します。

したがって、次のような最適なソリューションを見つける必要があります。要件を満たします。ほとんどの場合、ブレインストーミングを使用して代替案を取得します。

目標は何ですか？

プロジェクトスコープの一部であるものと含まれないものを明確に定義する必要があります。

プロセス＃3：PMソフトウェアを使用してプロジェクトスコープを管理する

確かに、利用可能な任意のアプリでプロジェクトスコープを追跡できます。たとえば、Googleドライブ、Evernote、MSWordで十分です。

ただし、統合されたプロジェクト管理ソフトウェアを使用してすべてを1か所にまとめることには大きなメリットがあります。

理想的には、要件をプロジェクトの成果物にリンクできる必要があります。

次に、成果物から、見積もり、関連するリスク、および欠陥を伴う特定のタスクまで。

たとえば、Paymoをお勧めします。個人使用や小規模プロジェクトに最適なアプリの1つです。さらに、優れたタイムトラッキング機能と請求機能を備えています。

プロセス＃4：プロジェクトスコープを制御する方法

最初にプロジェクトスコープを100％特定するだけでは不十分です。 。その100％は、プロジェクトの存続期間中に変更されます。

したがって、スコープを監視、制御、および変更する方法が必要です。

治療法はよく知られています。これは作業分解図です。

また、作業量が変更されるたびにプロジェクトのすべての領域に変更を導入するための明確なワークフローが必要です。

ただし、これは統合された変更管理プロセスの問題です。

では、何が問題なのでしょうか？

高品質のWBSが必要です。さらに、プロジェクトの範囲を説明するための非オタクな方法が必要です。したがって、プロジェクトスコープステートメントも必要です。以下で説明します。

アジャイルプロジェクトを使用している場合は、明確に定義された増分または反復の範囲がさらに重要になります。アジャイルが、行われるべき作業の完全な文書化からあなたを救うとは思わないでください。スプリントバックログとユーザーストーリーを整理してください。簡単なルールを適用します。「初心者は、ユーザーストーリーの説明から何をする必要があるかを理解する必要があります。」

スコープを検証する方法

たまに、正式なものを入手する必要があります成果物が利害関係者の期待に応えることを承認します。

プロジェクト全体を通じて継続的にそれを行うことが重要です。計画主導のプロジェクトを主導している場合でも、レビューのために製品の増分を提供することを妨げるものは何もありません。

なぜこれが必要なのですか？

すべてを取得したくない変更要求、すべての欠陥、そして最終的には「プロジェクトへのマイナーな変更」。

実際に変更をプロジェクトに統合する機会を奪うことになります。

プロジェクトの終了に近づくほど、残される時間とリソースが少なくなります。さらに、利害関係者は、範囲、タイムライン、または予算の変更について交渉する傾向が少なくなります。また、チームに次のようなプレッシャーをかけることになります。必要なものを手に入れましょう。

明白なことを述べるだけです：

最初から明確に説明され承認されたプロジェクトの範囲を持つことが非常に重要です。

成果物が期待を満たしていない場合、修正があります。

修正が変更要求であるかどうかを証明するのはあなたの責任であるため、適切に統合する必要があります。そうでない場合は、欠陥であり、あなたは償いをしなければなりません。自己負担の場合もあります。

実際に顧客とスコープを検証するにはどうすればよいですか？

どのプロジェクトでも、スクラムのようなデモ会議を使用できます。

成果物の短いデモンストレーションを準備します。現在のプロジェクトの状況と進捗状況を説明します。その後、既知の欠陥と進行中の部品を指摘します。

また、お客様からフィードバックを収集します。後で、ポリシーに必要なサポートドキュメントとレポートを提供できます。

結論：

関係者からのフィードバックを継続的に収集します。新しい変更要求の導入条件について交渉します。プロジェクトスコープベースラインを最新の状態に保ちます。

プロジェクトスコープ管理テンプレートを入手します

車輪を発明しないでください！費用がかかる可能性があります。

下のボタンをクリックして、空欄を埋めるテンプレートを入手してください。スコープ管理について知っておく必要のあるすべてのリソースガイドが付属しています。

スコープ全体を選択する理由プロジェクトにとってベースラインは重要ですか？

通常、プロジェクトが開始され、さまざまな形式で要件を受け取ります。

例：メール、PDF、会議、モックアップ、バグレポートなど。

もちろん、プロジェクト憲章などは作成していません。悪い習慣です！

ほとんどの場合、プロジェクトのビジネスケースについても話し合いません。

通常、作業分解図を作成します。

ただし、これは内部でのみ使用され、顧客に提供されることはありません。次に、作業をアクティビティに分解し、プロジェクトを見積もります。ボトムアップの見積もり手法を使用します。

最初の期待値チェックが行われます：

プロジェクトの見積もりを提示します。

ご覧のとおり、明らかにここでの透明性の欠如。お客様は、私たちが実際にどのような作業を見積もりたかを知りません。

見積もりがお客様の期待に近い場合、お客様は詳細を掘り下げません。これは、彼がすでにその金額と時間を費やす準備ができているためです。彼は貴重な時間を無駄にしたくありません。

真実は次のとおりです：

多くの組織やプロジェクトマネージャーは非効率性を隠していますこのような沈黙の合意の背後にあります。

これは別の投稿のトピックですが、多くの問題の根本的な原因です。

次に何が起こりますか？

プロジェクトの実行を開始します！遅かれ早かれ、お客様は別の作品を追加するように求めます。

その後、未確認の作品の一部が見つかります。後で、品質の問題が発生します。彼らは多くの時間を浪費するでしょう。

全体として、私たちは何か間違ったことをしたことを見つけるために配達を引き渡します。

そしてそれは顧客が彼が彼を私たちに知らせたときです何かを忘れたので、できるだけ早く追加する必要があります。

信じてください。何度も経験します。

スコープベースラインの定義

「スコープベースラインは承認されたバージョンです。スコープステートメント、作業分解図（WBS）、およびそれに関連するWBSディクショナリの、正式な変更管理手順によってのみ変更でき、比較の基礎として使用されます。」 -PMBOK®ガイド

プロジェクトスコープステートメントとは何ですか？

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

プロジェクトスコープステートメントは、製品とプロジェクトスコープの説明です。

これは、プロジェクトが何をどのように作成するかを書面で確認するために使用されます。

貴重なプロジェクトスコープステートメントの鍵は何ですか？

利害関係者が理解できる用語と言語を使用する必要があると思います。このプロジェクトスコープベースラインは主に顧客向けです。

OK、何を含める必要がありますか？

プロジェクトの正当化

これは簡単な説明です。ビジネスのニーズ。一文で十分な場合もあります。残りはプロジェクト憲章にとどまる必要があります

製品の範囲

これは、作成する製品またはサービスの特性、特性、および機能の説明です。

さまざまな利害関係者から要件を収集したことを忘れないでください。したがって、それらすべてが各要件を追跡していると想定しないでください。また、要件を満たすために必要な作業量が常に明確であるとは限りません。

主要な利害関係者の期待を調整するための主要な場所です。

量と複雑さを示す必要があります。さまざまな要件を満たすために必要な作業の。したがって、このセクションに最大限の努力を払ってください。

承認基準

プロジェクトの成果物が承認される前に満たす必要がある条件です。

含めることができます。ここでも許容レベルと欠陥の数。

成果物

プロジェクトが作成するすべての成果物の説明です。

製品またはサービス、プロジェクトドキュメント、製品マニュアル、製品の教材など。

プロジェクトの除外

ここでは、プロジェクトの範囲外のものを指定する必要があります。

かなり頻繁に、利害関係者の一部は特定の何かを望んでいます。利害関係者または顧客の他の部分はそれをサポートしていません。

したがって、それは対立状況です。競合が解決され、プロジェクトスコープから何かを削除することが決定されたら、ここに配置します。

具体的かつ明確にします。将来的に時間を節約できます。

まず、これらのプロジェクトの除外を再度確認する必要はありません。利害関係者は、プロジェクトの実行中に後でそれらを含めようとする場合があります。

ただし、何かが劇的に変化しない限り、除外の確認に時間を無駄にしないでください。

次に、明確に述べられていない限り、誰かがそれでもあなたがそれを届けることを期待します。誤った期待を与えないでください。最後にプロジェクトを引き渡す方が簡単です。

制約

製品を効率的に提供することを制限するものはすべてここに記載する必要があります。

前提条件

現時点で明確にできなかったのは不確実性です。

計画時にそれらのいくつかを受け入れる必要があります。仮定が無効であることが判明した場合、プロジェクト計画を変更する権利があります。

顧客はプロジェクトスコープステートメントを承認する必要があります。実際、これは正式な相互合意です。

また、明確な仮定の下で、明確な制約の下で、説明された結果を提供することを約束していると述べています。一方、お客様は指定された結果を受け入れることに同意します。

プロジェクトの範囲を変更できないという意味ではありません。いいえ。変更を加えるには、契約を修正する必要があります。

WBSを使用してプロジェクトスコープを整理する

WBSは、すべてのプロジェクトのスコープベースラインの必須部分です。大小。アジャイルまたは計画主導型。

PMの基本に関する作業分解図の完全なガイドはすでにあります。ここでは繰り返しません。

強調したい重要なポイントは1つだけです。

プロジェクトスコープステートメントに記載されている成果物は、そのままWBSに取り込む必要があります。プロジェクト全体で成果物の一貫性を保ちます。

知っていることすべてをWBSディクショナリに入れます

WBSディクショナリは、各作業パッケージに対して実行する必要のある作業を説明するドキュメントです。

現代のPMとして、私はそれがタスク追跡システムの一部であるべきだと思います。ほとんどのプロジェクト管理ソフトウェアでは、この情報を1か所に保存できます。

したがって、別のドキュメントを作成することはお勧めしません。 WBS辞書の保守は大変な作業です。統合ソリューションを探します。

WBSのコンポーネントを指定する任意の情報を含めることができます。たとえば、WBSディクショナリには次のものが含まれます。

• 作業の説明
• 前提条件と制約
• 責任者または組織
• マイルストーン
• 関連アクティビティ
• 必要なリソース
• コスト見積もりまたは予算
• 受け入れ基準
• 他のドキュメントを参照

つまり、ニーズに合ったもので、WBSを他のプロセスに統合するのに役立ちます。

結論

「港がどこにあるかわからない船乗りにぴったりの風はありません。」

何をする必要があるかを知らなければ、プロジェクトを成功に導くことはできません。

もう一度、その点を強調したいと思います。

アジャイル環境にいて、プロジェクト全体のスコープが明確に定義されていない場合でも、プロジェクトスコープを定義、管理、追跡、および変更する方法を計画する必要があります。

両方とも反復レベル

以下もお読みになることをお勧めします。

• 注目の記事：経験のないITプロジェクトマネージャーになる方法
• 次の記事シリーズ：堅牢な作業分解図を作成する方法に関する究極のガイド
• シリーズの前半：プロジェクト管理の要件トレーサビリティマトリックス（例十分な+テンプレート）