PMBOKを含む教科書では、リスク管理手順は非常に明確で理解可能な用語で説明されています。
リスクが必要です：
- 明らかにする
- 定性的および定量的分析の対象
- リスクマトリックスの適切なセクションに入れる
- 彼と仕事をすることを決定する
- 関連性の開始または喪失まで追跡します。
ただし、実際には、これらの手順をきちんと実行していることを確認できるほど頻繁ではありませんが、この利点はあまりありません。
見かけの単純さの背後には、規律、創造性、知的努力を必要とするプロジェクトマネージャーの日々の仕事があります。 そして、リスクは将来起こりそうな出来事であり、起こらないかもしれないので、今私はそれをやりたくありません-より緊急のタスクがあります。
プロジェクトマネージャーがリスク管理が必要であると理解しているとします。 これを彼に納得させる必要はありません。 しかし、最も効率的な方法でそれを行う方法は？ 最小限の時間投資でリスクの発生による損失を実際に減らすために、どのような手法とツールを使用する必要がありますか？
リスクツール
必須ツールのセットがあり、その存在とコンテンツの品質は、プロジェクトマネージャーがリスクを管理しようとしていることを既に示しています。 それは
- リスク登録
- クリティカルリスクカード
- リスクの割り当てとタスク
ただし、それらの存在だけでは結果は得られません。
最初に、リスクを正しく識別する必要があります。 原則として、一連のイベントは悪影響をもたらします。 リスクとは何ですか？ 結果またはそれにつながるイベントの1つ？
簡単な例を見てみましょう。
図は同じチェーンを示していますが、重点は異なるリンクにあります。
仕事に遅刻しないようにしてください。 たとえば、確実に遅れることを避けるために、30分早く外出します。 あなたがひばりである場合、これは良いオプションであり、朝の30分の睡眠はあなたにとって大きな価値はありません。
また、固定電話を携帯電話にリダイレクトすることができ、遅れても、不在着信を避けることができます。
2つのケースでリスクの可能性に対処するコストは異なります。 半時間のスリープまたはモバイルへの無意味なリダイレクト。 私たちが苦労しているものの定義に応じて、予防のコストは劇的に異なります。
危険なイベントとは、私たちが戦うものであり、予防しようとします。
次の基準は、リスクイベントを判断するための実用的なヒントとして使用できます。
- イベントは直接制御されています-認識でき、影響を受ける可能性があります。
- イベントは、結果の発生につながることが保証されています。
- 問題を解決する標準的な方法があり、この方法は通常安価です。
リスクの特定は継続的なプロセスです。 それらは、以前の経験、現在の状況の分析に基づいて定式化することができ、誰からでも、あらゆる形で報告することができます。 目を開けておくと、リスク情報が常にそこにあります。
問題は、これからレジストリに入る価値があるのは何ですか？
リスク登録簿のエントリは具体的でなければなりません：
- 起こったら...
- 結果が来る...
- これについて次のことができます..
リスクごとに、責任者と管理日が割り当てられます。
リスクレジスターの次の構造をお勧めしますが、特定の条件や好みに応じて変更または補足することができます。
- いいえ-固有のリスクコード
- タイトル-リスクの簡単な指定
- 説明-リスクイベントと結果の説明
- オープン-リスク登録日
- イニシエーター-イニシエーターのフルネーム
- リスク管理-定期的なリスク管理の責任者の氏名
- 優先度-高/中/低
- 決定日が必要-リスクまたは問題のアクションを決定するタイミング
- リスクの開始の結果（タイミングとコスト）-数値的には、リスクの開始はどうなりますか。
- リスクアクション-リスクの対処方法
- 行動の責任者-これらの行動を誰が実行すべきか
- アクションの予定日-アクションを実行するタイミング
- リスクのあるアクション-リスクが発生した場合の対処方法
- ステータス日付-ステータス更新日
- ステータス-オープン/分析完了/解決済み/クローズ
リスクマップ
最も重要なリスクは、個別のドキュメント、つまりリスクマップを作成する価値があります。
リスクマップでは次のように記述します。
- 何が起こるかについての詳細な説明
- 結果は何ですか、できればお金で表されます
- 発生確率
- アクションのオプション（何もしない、何かをする、何か他のことをする）
- 決定および行動計画
リスクマップはエスカレーションに非常に便利です。 アクションがプロジェクトマネージャーの権限のない他の誰かに依存している場合は、エスカレーションが必要です。
3.リスク管理計画の実施
リスクを特定し、登録を行い、カードを作成できます。 しかし、リスクアクションがない場合、前の手順はすべて役に立たない。
次のリスク管理戦略とその適用例が考えられます。
- 回避 -プロジェクトを作成しないでください。 未知の技術の使用を拒否します。
- 制限 -結果の可能性または影響の程度を減らすために何らかの行動を取ります。関連する経験を持つ下請業者を引き付けるため。 危険なタスクをプロジェクトの最初に移動します。 追加のテストを実施します。
- 受諾 -リスクの発生に対する引当金を作成します（一時的なバッファー、予算内の在庫）
- 転送 -リスク（またはその結果）のあるタスクの実装に対する責任（顧客、請負業者、保険会社）を割り当てます。
どの戦略を選択するか、計画されたアクションを決定したら、それらを確実に実装することが重要です。
プロジェクトの1つで、次のプラクティスを適用しました。 彼は、顧客の副部長とのリスクに関する会議を任命し、いくつかのリスクカードを持ってきました。 彼は、必要に応じて何かを説明し、オプションの1つを選択するか、別の解決策を策定するように求めました。 その後-紙にサインします。 これは、この指導者の従属における人々の行動を大いに刺激しました。
ただし、このようなスキームは、企業文化に対応していない場合や、マネージャーが決定を回避するための戦術を持っている場合、常に適用できるとは限りません。 操作は創造的な問題です。
別のプロジェクトでは、プロジェクトポータルでリスクマップを作成し（ プロジェクト管理でJIRAとConfluenceを使用するを参照）、レジストリに自動的に収集されました。 このオプションは、Excelスプレッドシートのすべての豊富な情報に対応しようとするよりも便利です。 さらに、タスク管理システムとの接続により、リスクアクションの計画と制御が容易でした。
この声明は、トピックの厳密な条件および完全性を主張するものではありません。 代わりに、実際に機能するものを共有しようとしました。
リスク管理の重要性を認識し、ツールを体系的に使用し、実際にこれにアプローチすれば、多くの合併症とそれらが引き起こす余分な作業を回避できます。