今日は事情があって、神奈川への移動は午後からとなります。先週は冬に逆戻りした日が続きましたが、週末は穏やかな日和となりました。でも今日は一転朝から冷たい雨が降っています。さすがに、このめまぐるしく変わる天気は体に堪えます。
ラッピング阪急電車。春はすぐそこに!
キックオフ会議の在り方について考えています。
前回はキックオフ会議の場で、PMが説明するプロジェクト概要、特に目的やスコープ、体制などのプロジェクト基本事項について、質疑応答や各人の視点による提案を行うなど議論をすること。その上で、プロジェクトとそれぞれのステークホルダーの役割を認識することが重要だと、お話ししました。
その結果、キックオフに集まったメンバーが共通の合意を形成し、「プロジェクト憲章」に表現されたプロジェクトの目的に向かって走り出すわけです。
もちろん詳細な計画は、次の「計画プロセス」で練っていくことになりますが、キックオフ会議の場で、プロジェクトの基本方針を理解し、了解することは重要であることはご理解いただけると思います。
キックオフ会議の席にはできるだけ多くのステークホルダーが参加することが望ましいのは言うまでもありません。特に、プロジェクトの最高責任者であるスポンサーが、プロジェクトの意義を説明しステークホルダーに直接理解を求めます。
それとともに、プロジェクトの実施メンバーに対して万全のサポートを行うことを表明することも忘れてはいけません。
このことを通して、プロジェクトスポンサーが表明するトップマネジメントの意思とプロジェクトに対する期待を伝えることになります。もし可能であれば、トップマネジメント自身が、キックオフ会議に参加し、直接説明することが望ましいです。特に、組織内の多くの部門、部署が関わるプロジェクトであれば、なおさらです。
ところで、キックオフ会議に参加するのは、組織に所属している人ばかりとは限りません。多くのプロジェクトではプロジェクトを一緒に推進する外部のパートナーが存在し、彼らも会議に参加することになります。
このとき、組織外の彼らとどこまで情報を共有するのかを考える必要があります。
順不動でキックオフ会議に参加するメンバーについて考えてきましたが、メンバー自体がいくつかのカテゴリーに分類されることに気が付きました。
ステークホルダーは様々な要素でカテゴリー化できるのですが、キックオフ会議の場合は、情報のレベルでカテゴリーわけすることが必要になるようです。
したがって、そのカテゴリー毎にキックオフ会議で提供する情報レベルが変わってくることが考えられます。
つまりPMは、キックオフ会議の構造(アーキテクチャー)の在り方を事前に構築し、準備することが必要になります。
次回はこの、キックオフ会議の構造化について考えて行くことにします。
