プロジェクトを失敗させないヒント49『挫折しないリスクマネジメント』

目次

    『プロジェクトを絶対に失敗させない!やり切るための100のヒント』とは

    『プロジェクトを絶対に失敗させない!やり切るための100のヒント』とは

    本記事は、プロジェクトを成功させるために必要なノウハウを、数百の支援実績経験をもとに記述した『プロジェクトを絶対に失敗させない!やり切るための100のヒント』より、 1つずつヒントをご紹介していく企画です。プロジェクトマネジメントについて、何らかの気づきを得るきっかけになれば幸いです。

    当社はプロジェクトマネジメントの知識と経験を有し、皆様のプロジェクトが成功するお手伝いをさせていただいております。 プロジェクトマネジメントに関する疑問や課題がある方、成功への道筋をお探しの方、どうぞお気軽にご連絡ください。
    お問合せはこちらからどうぞ。

    ※『プロジェクトを絶対に失敗させない!やり切るための100のヒント』をPDFまたは電子書籍でダウンロードできます

     


    将来起こり得るリスクを洗い出して、あらかじめ対応策などを決めておくリスクマネジメントは、プロジェクトの成否に大きな影響を及ぼす重要なものです。しかし、リスク検討会を1~2回開催しただけで形骸化してしまうケースは非常に多いもの。やり方を工夫して、効率的なリスクマネジメントを実施していきたいものです。

    プロジェクトのキックオフからおよそ1カ月後、まだ課題管理と進捗管理くらいしか実施していないプロジェクトで、次のような会話がありました。

    ーーーーーーーーーーーーーーーー
    プロジェクトマネジャー:そろそろマネジメント向けの会議があるから、リスクを洗い出して報告してくれないか。

    PMO:今のところリスクマネジメントは実施していませんが、当プロジェクトではリスクマネジメントを導入しますか。

    プロジェクトマネジャー:何を言っているんだ。当たり前だろ。

    PMO:言葉が足りませんでした。「当プロジェクトでは、リスクマネジメントにどの程度の工数(コスト)をかけますか」という確認です。
    ーーーーーーーーーーーーーーーー

    みなさんのプロジェクトでも、似たような議論が起こっていないでしょうか。リスクマネジメントとは、プロジェクトを進めていくなかで将来起こるかもしれないリスクを想定し、対応策を決めておくことです。その際、プロジェクト内でリスク内容と対応策についての共通認識を持ち、準備を整えておくことが肝要です。

    ところで、プロジェクトの開始直後から課題管理を導入していると、いつの間にか管理表の中にリスクと考えていることや日々やるべきTo Doが混在してしまうことが多いものです。こういう時、リスクとTo Doをそれぞれ別の管理表に分けることも重要です。ここで、課題とリスク、To Doをそれぞれ別の管理表とマネジメントプロセスで定着を図る時、私の経験からして最も難しいのは、リスクマネジメントだと感じています。

    教科書通りのやり方で効率的に運用できるか

    PMBOKが一般的になり、リスクマネジメントを実施するプロジェクトが多くなってきました。大抵のプロジェクトでは、リスクの「発生可能性」と「影響度」を指数化し、数値が高い(優先度が高い)リスクを重点的にモニタリングしていく方針で運用していると思います。プロジェクトマネジャー、PMO、チームリーダーの全員でリスクを管理するうえで、リスクに優先度を付ける2つの指標には大きな意味があります。

    果たして、このプロセスをうまく運用できているプロジェクトはどのくらいあるでしょうか。このパターンだけで運用を開始した場合、リスク検討会がすぐ形骸化してしまう例をたくさん見てきました。なぜなら、将来顕在化するか分からないリスクに対して、予想よりずっと多くのマネジメント工数が必要だと分かり、挫折してしまうことが多いのです。

    リスクは時間がたつにつれて変化していく性質があるため、定期的にリスクを評価し直す場(リスク検討会)が必要となります。そこにかける工数が、無駄と思えるほど多いことに、すぐ気づくはずです。

    打開策として色々な考え方があるかと思いますが、実際に運用してみて効果があった方法を紹介したいと思います。それは、「チーム単位でモニタリングするリスク」と「マネジメントレベルでモニタリングするリスク」を分けて管理することです。リスク管理表には、管理主体がチームかマネジメントレベルかを区別するフラグを1つ追加します。

    管理主体を分けると、まずプロジェクトマネジャーやPMOの負担が大幅に減り、プロジェクト全体に影響を及ぼす重要なリスクに集中できるようになります。そしてチームリーダーは、プロジェクトマネジャーに報告する内容(リスクやその状態)をチーム内で吟味してからエスカレーションするようになります。このため、思った以上に要点を突いたリスクが挙がりやすくなるのです。プロジェクト全体で見るべきリスクの共通認識も持ちやすくなるでしょう。

    マネジメントレベルで管理すべきリスクは「ユーザー受け入れテストを実施するに当たり、エンドユーザーの参画調整がうまくできず、使われないシステムになる恐れがある」など、プロジェクト全体で対応策を検討し、定期的にモニタリングをしていくべきことです。一般的には、プロジェクト全体で識別した総リスク数の2割程度でしょうか。マネジメントレベルのリスクとして管理していくことが決まった事項は、短期間で状態の変化がなかったとしても、PMOなどが週次会議などで継続的に確認し、プロジェクト全体で発生を防ぐべく認識を合わせる活動をしていきます。

    一方、チーム単位でモニタリングするリスクは、チーム内で懸念されるリスクの感度をチームメンバーで合わせることに主眼を置いています。必ずしも全てのリスクをプロジェクト全体の週次会議などで報告する必要はありません。2つの指標(発生可能性と影響度)に基づく優先度に従って報告頻度を調整すれば、毎週全てのリスクを評価し直すこともなく、工数を削減できます。これなら挫折することなく、リスクマネジメントを運用していけます。