IT部門／情シスにおけるステアリングコミッティの準備とは？

ステアリングコミッティがうまくいかない

「ステコミのやり方を指導してほしい」

ある支援先の常務から依頼がありました。

そのプロジェクトは特に田村の支援対象ではなかったのですが、お困りの様子だったので、とりあえず確認することに。

早速、プロジェクトマネージャーのAさんにヒアリングしました。

まずステアリングコミッティ（以下、ステコミ）のアジェンダを確認すると、進捗・課題・リスク・コストの報告とのことで、問題はない様子。

ところが、お伺いしてみると、Aさんが一生懸命に説明しても、多くの指摘を浴びるそうです。時間内に終わらず、常務からいつも怒られるとのこと。

そこでステコミの「資料」と「議事録」を見せてもらいました。すると理由がすぐに分かりました。

ステコミでオーナーを巻き込んでいるか

Aさんのステコミの「資料」で気づいた点は何でしょうか？

それは、週次定例会の延長で準備していた、ということです。

週次定例会は、現場レベルの情報共有・確認の場です。

具体的で細かい課題や解決策を検討しますが、それは現場レベルの話です。WBSも担当者別の詳細タスクです。

一方で、ステコミはプロジェクトオーナー（以下、オーナー）への報告です。

オーナーは自身が動くべき事案があるかを探っています。

・取引先や関連部門のトップに話を通す
・全体的な方針を示す
・意見が分かれているものに判断を下す

その判断材料として、プロジェクト全体の話が聞きたいのです。逆に現場レベルの細かすぎる話は聞きたくありません。そのレベルの話をひたすら聞かされると、オーナーはどうなるか…ということです。

Aさんからステコミの資料を見せてもらいましたが、週次定例会とほとんど同じ資料でした。当然ながら、説明も現場レベルの細かい内容になっていました。

Aさんには、ステコミのフォーマットを提示し、ステコミ専用の準備をお願いしました。

・概要スケジュールでの予実を作る
・課題やリスクは報告すべきものだけをピックアップする
・具体的な説明は省略し、要点のみで話を組み立てる
・説明のリハーサルを行う（最重要！）

次に、Aさんのステコミの「議事録」で気づいた点は何でしょうか？

過去議事録のどれをみても「決定事項」と「オーナーのTo Do」が全く記載されていなかった、ことです。

ここにオーナーを巻き込めたかどうかが現れます。これらがゼロの場合は、ステコミの内容を見直した方が良いでしょう。

オーナーは偉い立場なので、気を遣うのはよくわかります。しかし、気を遣いすぎると、「プロジェクトオーナー」という体制図上のトップが機能せず、意味がありません。

少々言葉は悪いですが

「プロジェクトを成功させるためにオーナーを利用すべき」

です。

オーナーが動けば、一瞬で解決することはたくさんあります。特に悪い情報ほど、積極的に相談することで、問題が大きくなる前に対処することができます。

そのためには、日頃よりステコミ用のアンテナを張っておくことが重要です。オーナーに報告すべきこと、オーナーに判断してほしいこと、オーナーに動いてほしいこと、それらを記録しておき、アジェンダに反映するのです。

ステコミの成否は雰囲気で分かる

Aさんは次のステコミでリベンジに臨みました。

新しく準備した資料で、細かい話はせずに要点のみに絞って説明します。

報告は15分で終了し、残りの15分は雑談になりました。

その雑談は、前向きで笑いに包まれ、いつもと異なる空気のまま終了しました。

「決定事項」と「オーナーのToDo」も明確になっています。

＜決定事項＞
・今回のスコープからXX事業は外す

＜ToDo＞
・XX事業の担当役員に話を通す（オーナー）
・取引先との打ち合わせに同席する（オーナー）

オーナーは「引き続き頼む」と上機嫌でAさんに話されていました。

貴社のIT部門／情報システム部は、ステアリングコミッティにおいて、プロジェクトオーナーを巻き込む内容になっていますでしょうか？