リスク管理プロセスにはリスクの識別、分析、計画、追跡、および通信が含まれます。 リスク管理にはリスク、問題、および変更依頼が含まれます。 潜在的な問題や問題の及ぼす影響の重大性を意識した上で評価し、情報に基づいて決定を行うことが、プロジェクトのリスク管理において最も重要です。
プロジェクト マネージャはリスクを識別し分析した後にリスクが及ぼす影響に基づいてリスクまたは問題を作成します。
リスクは、プロジェクトのライフ サイクルを通じていつでも特定できます。 リスクを問題へエスカレートするのは、プロジェクトに重大な影響を与えると思われる場合です。 変更依頼は問題の結果行われ、変更依頼により効果的な解決が促されます。
以下の図およびこのシナリオでは、プロジェクト リスク管理の 1 つの方法について説明します。 プロジェクト リスクを管理するその他の方法の詳細については、「プロジェクト管理ユーザ ガイド」を参照してください。

例: プロジェクト リスクの作成と管理
この例では、Forward 社のプロジェクト チームは、ニッチな技術を使用して新製品を開発しています。 この技術を使用した経験を持つ組織内のリソースは限定されるため、チームは、プロジェクトを完了するために外部リソースを使用する必要があります。 さらに、その製品には、法的な承認が必要なサードパーティ API がバンドルされます。
チームは、分析のため、それらのプロジェクトに重大な影響を与える以下の 2 つのリスクを識別します。
分析の後、プロジェクトへのリスクの影響に基づいて、プロジェクト マネージャは、限定されたリソースに対するリスクおよび依存関係の問題を作成します。
プロジェクト リスクを管理するには、以下の手順に従います。
このシナリオ内のタスクをすべて完了するには、以下のアクセス権を必要とします。
リスクは、プロジェクト目標に正か負の影響を及ぼす潜在的な将来のイベントです。 リスクをプロジェクトの初期に識別することで、プロジェクトのスコープ、スケジュール、予算および他の要因上の潜在的な影響を認識することができます。 このシナリオで、チームは、外部資源を使用することで、リソースが限定されていることによるリスクを緩和することを決定します。 プロジェクト マネージャは、情報をすべて提供する詳細なリスクを作成し、[カテゴリ]ドロップダウン リストから[リソース利用可能時間]を選択します。
詳細なリスクに対する総合スコアが、割り当てた評価と異なる場合、2 つのリスク管理コンポーネントは影響し合います。 詳細なリスクのスコアが、ユーザが割り当てた評価を上書きします。 評価を割り当てずにリスクの詳細を作成すると、リスク入力のスコアがリストのしかるべき要因に色を付けます。 リスクの詳細を削除すると、プロジェクト全体のリスク スコアと特定のリスク カテゴリを組み合わせたリスク スコアが変更されます。
以下の手順に従います。
リスクが属するカテゴリを定義します。
値:
注: リスクカテゴリを指定した場合、そのリスクの総合スコアは、リスク カテゴリまたは要因に対して行う異なるステータス選択を無視します。
リスクを管理しているリソースの名前を定義します。 このリソースは、リスクのライフ サイクルを通じて、リスクの適切な管理および追跡を確認することに責任を持ちます。
既定値:現在ログインしているリソース
プロジェクトにこのリスクの影響が及ぶ日付を定義します。 影響日を特定したら、[解決予定日]フィールドに日付を入力します。
既定値: 現在の日付
この項目がリスクとなりうると決定するための想定を定義します。 これらの想定を検証することにより、リスクのライフサイクルを通じてこれらの想定が有効であり続けるかどうかを確認することができます。 想定が変更された場合、リスクの影響または可能性も変更されます。
このリスクと関連するプロジェクトのリスクを定義します。 リスクを関連付けられるのは、このプロジェクト内のリスクのみです。
このリスクと関連するプロジェクト内の問題を定義します。 リスクを関連付けられるのは、このプロジェクト内の問題のみです。
このリスクに対する対応のタイプを定義します。
値:
既定値: 監視
注: このシナリオで、[軽減]を選択します。
リスクが発生する可能性を定義します。 リスクの可能性は、リスク顕在化の計算に使用されます。
値: 低(1)、中(2)、高(3)
既定値: 低
[可能性]と[影響]フィールドで選択した値に基づいて計算されたスコアを表示します。
値:
このリスクがプロジェクトに与える影響を定義します。 リスクがプロジェクトに及ぼす影響は、パフォーマンス、サポート性、コスト、およびスケジュールによって決定されます。 この値は、リスク顕在化の計算に使用されます。
既定値: 低
リスクが軽減された後の、このリスクの最終的な解決方法を定義します。 解決データは、将来プロジェクトのリスクに対して計画または対策を立てる場合に、リスク対応方法の結果を再考するのに役に立ちます。
注: リスクの作成中または終了前に、解決を定義できます。
リスクを解決するための緩和策の結果としてプロジェクト内で発生または作成されたリスクを指定します。 関連リスクとは異なり、残存リスクは結果がさまざまですが、リスクを解決するために行った措置の結果生じます。
リスク軽減の意思決定が行われると、プロジェクト マネージャは、リスクのオーナーを作成し、対応方法の策定に割り当てます。 リスク対応方法は、アクション、追跡要件、その他リスクの可能性と影響を排除するのに必要なサポート情報を文書化します。
誰がリスクを所有しているかにかかわらず、個々の応答方法を別のリソースに割り当て、応答方法ごとに個別に期限を設定できます。 これらの日付および名前は、リスク オーナーに通知および事前通知を送信するプロセスに使用できます。 通常、対応のタイプとして[軽減]を選択した場合に、リスク対応方法を作成します。
リスクの可能性を認め、リスクの解消を求めない場合もあります。
以下の手順に従います。
リスクの軽減に成功したら、リスクのステータスを[クローズ]に変更し、最終的な解決策を入力します。 解決を詳細に記録しておくと、将来プロジェクトのリスクに対して計画または対策を立てる際、リスク対応方法の最終結果について再考するのに役に立ちます。
以下の手順に従います。
問題はプロジェクトに影響を与えたイベントです。 リスク緩和計画が失敗した場合、リスクを問題へエスカレートできます。 既存のリスクから問題を作成し、次に、リスクを終了します。 新たに作成された問題は、リスクの名前と説明、および[ステータス]([オープン])や[作成日](現在のカレンダ日付)などの値を継承します。 常に元のリスクにリンクによって戻ることができます。 問題をリスクから作成することで、プロジェクト チームが結論を下すための問題に関する認識、アクション、タスクが生じます。 また、このような作成方法により、チームが問題とその結果を継続的に記録し、プロジェクトの終了時および将来のプロジェクトの計画時に分析を行うことができます。
また、この問題に関連した他のリスクまたは問題を連携させることもできます。 関連する問題およびリスクを連携させることは、依存関係を追跡し、かつ将来の分析および監査におけるトレンドを認識することに役立ちます。
このシナリオでは、緩和計画の一部として、外部契約業者がプロジェクトを完了するために雇用されます。 ただし、雇用された契約業者は、プロジェクトの納品の進捗ステータスに影響を与える、要求される経験レベルを持っていません。 この段階でリスクが問題になります。また、プロジェクト マネージャは次にこのリスクから問題を作成し、リスクを終了します。
以下の手順に従います。
問題が属するエンティティを定義します。
値:
問題を管理しているリソースの名前を定義します。 このリソースは、問題のライフ サイクルにおいて、問題の適切な管理および追跡を確認することに責任を持ちます。
既定値:現在ログインしているリソース
リスクが重大な影響をプロジェクトに与える場合、問題を作成します。 承認プロセスの遅延が予想されるので、プロジェクト マネージャは問題を作成し、依存関係としてカテゴリを割り当てます。
以下の手順に従います。
問題の一意の識別子を定義します。 問題の保存後は、識別子を変更することはできません。
問題が属するカテゴリを定義します。
値:
問題を管理しているリソースの名前を定義します。 このリソースは、問題のライフ サイクルにおいて、問題の適切な管理および追跡を確認することに責任を持ちます。
既定値:現在ログインしているリソース
問題を作成したリソースの名前が表示されます。
既定値:現在ログインしているリソース
問題が解決したら、ステータスを[クローズ]に変更し、最終的な解決方法を入力します。 解決を詳細に記録しておくと、将来プロジェクトの問題に対して計画または対策を立てる際、問題の結果を振り返るのに役立ちます。
以下の手順に従います。
|
Copyright © 2013 CA.
All rights reserved.
|
|