奇妙だが真実
- 絶対にすべてのプロジェクトおよび会社の管理基準は、リスク管理の必要性について述べています。 さまざまなモデル、ツール、および用語が利用可能です。 すべてのPMは、これが重要であることを理解しています。 そしてトレーニングを受けます。 そして、彼らはリスク管理のような実践（またはプロセス）を実行しようとさえします。 しかし、すべて（ほとんど）がこれを実際の意味と利点と見なしているわけではありません。 最良の場合、リスクレジスター（すぐに忘れられます）が設定され、最悪の場合、リスク管理は日常のコミュニケーションの過程で行われると言われます（ただし、リスクと管理の意味は明確ではありません）。
- プロジェクトにリスク登録がある場合、会社の経営陣は、プロジェクトの予期しない問題について定期的に苦情を申し立てている顧客との積極的なプロジェクト管理およびコミュニケーションが不足していると考えています。
- プロジェクトマネージャーとプロジェクトチームは、リスクの処理に費やした時間が長いこと（および、明らかに、効果の欠如に不満を訴えます）
これらおよび多くの同様の観察は、品質管理システムの実装中およびIT企業でのプロセス監査の実施中に行われました。 特に、プロジェクト管理プロセス。 他のイノベーションと同様に、作業ルールの実装には、これが必要な理由を正当化する必要があります。 このためには、説得力に加えて、理論と実践例の知識が必要です-否定と肯定の両方。 効果的なリスク管理の秘密に関する私の結論は、それらに基づいています。
リスク、リスクのソース、リスクカテゴリ
プロジェクトにおける非効率性またはリスク管理の欠如の原因の分析は、人々がリスクを正しく識別せず、対応計画を策定していないことを示しています。
主にプロジェクトリスクレジスタ（一般的な表現）で遭遇した典型的なリスクの例を次に示します。
- 「クライアントが長時間応答しない場合があります」
- 「従業員が突然仕事を休むかもしれない」
- 「要件を徹底的に調査することなく契約に署名した」
- 「インターネットの問題が発生する可能性があります」
紳士、これらは事実です！ これらの事実に対処するために、品質管理標準（ISO）、プロジェクト管理方法論（たとえば、SCRUM）、作業を整理するためのフレームワーク（PMBOK、CMMI）などがあります。これらは、世代のマネージャーの経験とさまざまな程度のプロジェクトの成功を収集します。 彼らは、契約に署名する前に、当事者のコミットメント（コミットメント）を規定すること、プロセスの人間の独立性の世話をすること、作業成果物（モニタリングの結果として得られる文書とデータ）を作成することなどが必要だと言います。 しかし、これはあまりにも「官僚的」であり、「時代遅れ」である、と多くのマネージャー（特に「プログラムされた」プログラマー、違反は言われない）によると。 私たちは、個々のプロジェクトごとに車輪を再発明し、一般的にヒーローに火を消すことを好みます。 このような「リスク」は、プロジェクトの予備計画段階で、できれば契約に署名する前に防止する必要があります。
プロジェクト中、このような未解決の問題はすでにリスクの原因になっています。 ソースについて：私が観察したリスク登録簿に記載されているリスクの典型的なソースは、「クライアント」、「チーム」、「環境」などです。 潜在的な問題の原因が一般化された概念ではないと考える人はいませんが、特定の状況はほとんどの場合否定的です！
「クライアント」、「チーム」、「環境」は、プロジェクトの状況を確認するカテゴリであり、プロジェクトの目標の達成に疑問を抱く否定的な事実や状況を見つけることができます。
特定の否定的な状況（多くの場合、これは、エラーと意識的な決定の両方によって引き起こされる契約からの逸脱、作業基準からの逸脱）は、望ましい（および計画された）作業結果、つまりプロジェクトの目標から逸脱する可能性があります。 これはプロジェクトのリスクです！
リスク評価
このリスクの影響は、プロジェクトの目標からの逸脱の大きさ、およびこの目標に関して許容できる逸脱の大きさによって決まります。
おそらく例を挙げるべき時でしょう。 典型的なのではなく、より便利ではありませんか
「 ソース 」：チーム
「 リスク 」：人は病気になります
「 影響 ：」は時間通りに行いません
次の情報があります。
「 ソース 」：クリティカルパスでタスクを実行する人（A）には、その人の（A）タスク中に出産しなければならない妊娠中の妻がいます（これは事実です）
「 リスク 」：上記の事実により、3営業日以上（A）人が不在になる可能性があります
「 影響 ：」スケジュールから20％の逸脱が可能です。
スケジュールから20％の逸脱は、1つのプロジェクトでは些細なこと（20％が4労働時間であり、クライアントとの時差は8時間である）が、別のプロジェクトでは実際の悲劇（20％は2日であり、クライアントが割り当てられる所定の数の重要な利害関係者とのプレゼンテーション）。 このようなすべての現実を考慮して、リスクの重大度が評価されます（たとえば、当社のように1〜9）。
リスクの結果を決定したら、その確率（確率）について考える必要があります。 プロジェクトに複数の人がいるため、人が突然仕事を休む可能性が非常に高くなります。 欠席する理由はいくつかあります。 しかし、特定の期間に明確な人がいないことは問題ではないかもしれませんし、同じ期間に別の人がいないことは悲劇です。 一般化された問題に反対し、特定のリスクを支持する別の議論があります。
リスクの重大度-古典的には-確率への影響の積によって決定されます。 まず、マネージャーの仕事は最も深刻なリスクに取り組むことです。 誰もがこれを理解しています。 誰もがリスクに対応するための基本的な戦略を知っています。 問題は、リスク対応計画について考える必要があるときに始まります。
リスク対応計画
私が遭遇したリスク対応計画の典型的な例は次のとおりです。
- 「顧客と話す」
- 「休暇に行かせないで」
- 「開催集会」
これらの計画を適用すると、どの程度のリスクが軽減されると言えますか？ つまり、リスク管理活動はどれほど効果的か：確率はどれだけ低下するのか？ どの程度のダメージが軽減されますか？
リスク対応計画は、潜在的な問題を完全にまたは部分的に削除する必要があるアクションですが、それを防ぐ意図の声明ではありません。
アクションにはコストもかかります（プロジェクトの目標の達成に与える影響：たとえば、労働時間）。
プロジェクトのコストを示す2つ以上の代替シナリオがある場合のみ（たとえば、1つは事後対応的、つまりリスクがトリガーされた後、2つ目はリスク対応計画がプロジェクト計画に最初から含まれている場合は予防的であり、満たされている場合）、これから何をすべきかを決定できます。 または、経営者またはクライアントが決定を下す機会を提供します。 この場合にのみ、プロジェクトの管理（または管理への参加）を行い、プロジェクトマネージャーの肩書きを正当化します。 ちなみに、これはクライアントの目に敬意を払う良い方法であり、それは彼の側のプレッシャーの減少につながります。
たとえば、人（A）のリスクがある場合、答えは次のようになります。
「 他の人がタスクを実行できるようにするために：2人目の人との知識共有に関する毎日の会議（メインキャラクターは1日1時間、「バックアップ」は1日1時間）。」
リスクへの対応コスト= 1週間あたり10人時間。これは、スケジュールの面でN％の遅れです。
起こりうる逸脱と比較して、リスクが発生した場合、リスクの可能性を考慮に入れ、これを決定者に委ねます。 考えられる結果は、作業量の減少または偏差の1つをクライアントが受け入れることです。
リスクの数
興味深い質問の1つは、プロジェクトにいくつのリスクがあるかということです。
論理的な答えは好きなだけ多く、システムの編成が少なく、プロジェクトの計画が弱いほど多くなります。
より具体的には、質問は次のとおりである必要があります。「制御する必要があるリスクの数（文書化、変更の監視）」
実際には、次の場合があります。
- 記録には、さまざまな詳細度のいくつかのリスク（2〜3以上）が含まれています。 マネージャーはそれらのレビューに多くの時間を費やし、最終的には「屠殺」されます。
- リスク登録簿には約5〜7のリスクがあり、それぞれがグローバルであり、プロジェクトで起こりうる問題ではなく、技術、人事管理などの業界の問題を反映しています。 さらに、重大度、戦略、および対応計画がすでに示されています。 それらは「リスクを発見しない」という目標で定期的に見られます。 ここには少なくとも2つの問題があります。
- 非特定のリスクは、非特定の対応計画につながり、プロジェクトの目標に対するリスクの影響を効果的に評価できない
- 再開の理由は異なる可能性があり、潜在的な損傷もそれぞれ異なり、応答は再開ごとに異なる必要があります。 T.O. これら5つの「リスク」は、本質的にリスクの原因です。
- リスク登録はありません。 リスクは文書化されていません。 最良のケースのシナリオでは、リスクが議論され、評価され、場合によっては応答の評価も含めて、応答アクションが提供されます。 この場合、問題は次のとおりです。
- 応答が効果的だったかどうかの分析を忘れることがあります
- クライアントを「飼いならす」ためのツールとして、もう一度適用できる重要な教訓を失います。
同時に、今週10件と昨年10件のリスクがあったとしても、少なくとも部分的に異なるリスクである可能性が高いです。状況が変化し、新しい状況が現れ、古いものが消えました。 しかし、これらのリスクの原因は同じかもしれません。
つまり、全体のポイントはリスクの正しい識別です。 正しく策定されたリスクにより、プロジェクトの目的への影響を評価できるため、最も関連性が高く深刻なリスクを選択できます。 もちろん、プロジェクトの目標も正しく策定されている場合。 しかし、これは別のトピックです。
まとめ
- リスク管理プラクティスの適用はそれ自体が目的ではなく、次のツールです。
- プロジェクトチームの生活を簡素化する
- ビジネス目標（プロジェクト目標）を達成するために、顧客および会社の経営陣（つまり、定期的に毎日使用されるツール）との効果的なコミュニケーション。
- 最短の「余分な」時間で最大限の利益を得るために、リスク登録ではなく、次の手順から始めることをお勧めします。
- プロジェクトの目標を明確かつ正確に策定（要求）します（プロジェクトのリスク管理に携わる人がアクセス可能で理解している、例えば：
「このようなユーザーは、120日後にアプリケーションでそのようなデータを受け取ることができるはずです。 そのようなリクエストのエラーは受け入れられません。」 - 具体的かつ究極の（SMART）リスクを策定して、前述の目標を達成します。 これを行うには、以下を決定します。
- そのソース（リスクとは異なり、プロジェクト全体に関連する可能性があるという事実）。
- 複数のプロジェクト、組織、および業界全体に関連するリスクカテゴリのソースを探します（たとえば、人事管理、特定の技術、顧客の国家文化など）。
- プロジェクトの目標を明確かつ正確に策定（要求）します（プロジェクトのリスク管理に携わる人がアクセス可能で理解している、例えば：
- リスクを扱うときは、次のことに注意してください。
- リスク評価の目的は、プロジェクトの目標に対するリスクの測定可能な潜在的影響です。 リスク対応の目的は、プロジェクトの目標に対する潜在的な影響を（ある程度）変更することです。
- 有効性管理リスクは、プロジェクトの目標からの潜在的な逸脱がどれだけ防止されたかの測定可能な指標によって決定されます。
- そして最後の1つ。 さまざまな理由で「このプロジェクトのリスクを管理することは不可能です」とよく耳にします。 しかし、あなたはマネージャーです！
- プロジェクトマネージャーは、潜在的な問題（リスク）をタイムリーに見つけて代替ソリューションを提案するなど、プロジェクトの目標を達成するための最適な方法の開発に参加するという点でプロジェクトコーディネーターと異なります。