スコープやチームが変わったときにRACIを見直す
キックオフで作成され、二度と更新されないRACIは、最初の変化が起きた瞬間に時代遅れになっている。
Why it works
スコープの変更、人員の変更、マイルストーンの完了はすべて、元のRACIの一部を無効にします。マトリクスが更新されなければ、もはや権限を持たない人によって意思決定がなされ、相談されるべき人が知らされず、説明責任が隙間に落ちます。定期的なRACIレビューは、説明責任の構造をプロジェクトの実際の状態と一致させ続けます。
How to do it
- 各主要なマイルストーン、または大きなスコープや人員の変更があるたびにRACIレビューをスケジュールする。
- 問う:「Aは変わったか?マトリクスにない新しい意思決定はあるか?誰かのCがIに、あるいはその逆に変わったか?」
- 更新したマトリクスを再配布する。古くなったRACIをプロジェクトのリスクとして扱う。
エビデンス
適応型プロジェクト管理の研究は、役割の明確さが最初に確立されるだけでなく、動的に維持されなければならないことを示しています。変化する環境における静的な割り当ては、役割が明示的な再設計なしに進化するにつれて説明責任のギャップを生み出します。 (mechanistic)
この実践はRACIのレビュー頻度とプロジェクト成果に関する特定の実証研究というより、プロジェクト管理のベストプラクティスの論理に基づいています。
よくある間違い
RACIを、維持を必要とする生きたガバナンスツールとしてではなく、キックオフ文書のための一度きりの成果物として扱うこと。
IX Coach でこれを実践する
More practices for RACIマトリクスを実践的に使う
- 意思決定ごとに正確に1人のAccountableを割り当てる
すべての意思決定または成果物には正確に1人のAが必要である——0人でも2人でもない。
- 実行者(R)と所有者(A)を分ける
作業を実行する人が結果を所有する人と同一でないことが多い——これを明示する。
- Consultedを、その意見が実際に意思決定を変える人に限定する
すべてのCは時間を消費する双方向の会話である。相談しすぎることは、相談しなさすぎることと同じくらい危険である。
- 尋ねられる前に、苦情が来る前に関係者に伝える
Iは一方向である——情報を受け取るだけである。彼らを驚かせるコストは、伝えるコストより常に高い。
- RACIを意思決定ログと組み合わせる
誰が決めるかを知ることはシステムの半分にすぎない——何が決められたかを記録することが説明責任のループを閉じる。