プログラム全体のリスクをどう束ねるか

プログラムを始めると、リスク一覧がどんどん長くなります。各プロジェクトから上がってくるものを全部集めると、100件を超えることもあります。

そして、長すぎて誰も見なくなります。これが一番よくない状態です。

解き方は単純で、全部を1か所で管理しようとしないことです。

リスクは層ごとに持ち主を変える

図のように、リスクは3つの層に分けます。分ける基準は「誰が手を打てるか」です。

特定の機能の技術的な難しさは、プロジェクトの中で解決できます。プログラム側に上げても、できることはありません。逆に、要員の取り合いはプロジェクトでは解決できません。上に上げる必要があります。

プログラムのリスク一覧に載せるのは、プログラムの層のものだけ。10〜20件に収まります。これなら毎週見られます。

エスカレーションが機能しない現場では、たいてい基準が曖昧です。「重要なものは上げてください」では、誰も上げません。上げると心配をかけると思うからです。

だから、数字で決めます。

基準を超えたら自動的に上げる。判断を挟まないのがコツです。「これは上げるべきか」と考える余地があると、遅れます。

各プロジェクトのリスクを足し合わせても見えてこないものがあります。これがプログラムマネージャーの本当の持ち場です。

つなぎ目が落ちる。どのプロジェクトも「自分の担当ではない」と思っている作業が必ずあります。依存一覧を作り、渡す側と受け取る側の名前が両方入っているかを確認します。名前が片方しかない行が危ない行です。

全部できても成果が出ない。プログラム最大のリスクです。中間指標を早めに測ることでしか見つけられません。「全部終わってから測る」では、手を打つ時間がありません。

現場が新しいやり方を使わない。システムは動いているのに、旧来の手順が続いている状態。実施率を測ると分かります。低ければ、手順が現実に合っていないか、研修が足りていません。

キーパーソンの取り合い。業務に詳しい人は、だいたい1人か2人しかいません。その人の予定を、全プロジェクト分まとめて1枚に並べてみてください。たいてい破綻しています。

リスク一覧が形骸化する原因は、書き方にもあります。

よくある書き方	動く書き方
要員不足のリスクがある	3月から業務側のレビュー担当が1名不足。2月末までに人事と調整（担当：佐藤）
連携先システムの対応が不透明	連携先の改修可否を、1月20日までに先方の課長に確認（担当：田中）

右のように書けないリスクは、まだリスクとして把握できていないということです。その場合、「調べる」こと自体を最初のアクションにします。

リスクは悪いことだけではありません。プログラムでは、良いほうのブレも拾います。

プログラムは構成を組み替えられるのが強みです。良い変化を見つけたときも、すぐ判断の材料にします。

リスクは層ごとに持ち主を分け、プログラムの一覧には上の層のものだけを載せる。エスカレーションの基準は数字で決め、自動で上げる。そして、つなぎ目・成果・定着・キーパーソンという、プログラム固有の4つを自分の持ち場として見る。

いまのリスク一覧が50件を超えているなら、一度「これはプロジェクトで解決できるか」で仕分けしてみてください。プログラムが見るべきものが、はっきりします。

ユーザーコメント（0）