プロジェクト体制図を正しく書いていますか?

コラムカテゴリー:

 運営がうまくいっていないプロジェクトは「プロジェクト体制」が良くないところが少なくありません。体制の悪さはプロジェクト計画書等に記載される「体制図」を見るとすぐにわかります。

以下に実際にあったプロジェクトの体制図(簡略版)を記載していますので、どこに問題があるか考えてみましょう。

 食品メーカーグループのホールディングス会社A社とグループ会社B社とで共同で行われた「基幹システム導入プロジェクト」の事例です。
※実際には各ボックスの中に実名が入っています

問題点①:プロジェクト責任が2系統に分かれている

最終的な意思決定者が一人でないためプロジェクトの方針がなかなか決まらない、一旦決まってもすぐに変わるといった事が頻繁に起き、プロジェクトの進行に支障が出ていました。
責任者はグループ全体の視点が必要となるので、このケースではA社が担うべきでした。

問題点②:ボックスの左右に線が伸びている

通常はボックスの上下に先があるので指揮命令系統が分かりますが、「支援チーム」と「事務局」には左右に線が伸びています。
これではどちらの意思決定、指示を優先すべきか不明確です。
また、酷いことに一方の線の先が更に分岐しているので、もはや線の意味が分からなくなっています。

問題点③:役割や責任がはっきりしないチーム名称である

「支援チーム」は上記の通り指示系統が不明確なチームですが、そもそも“支援チーム”という名前が漠然としており果たすべき機能も不明確です。これではプロジェクトメンバーによって「支援チーム」に求めることがバラバラになり「支援チーム」に対しての評価は低くなる可能性が高くなります。これはプロジェクト全体にとっても良いことではありません。
「プロジェクト管理」もプロジェクトマネージャーとしての責任を持つのか、管理チームの位置付けなのか不明確です。

問題点④:意味の不明な線がある

「グループ共通化プロジェクトマネージャー」(以下、共通化PM)と「基幹パッケージ導入チーム」が点線で結ばれています。グループ共通化メンバーとの連携が必要となるのは想像できますが、結局このプロジェクトにおける共通化PMの責任の有無が不明確です。責任が無いのであれば線は無い方が良いでしょう。
「基幹パッケージ導入チーム」は「プロジェクト管理」チームから指示を受ける一方、内容の異なる要求を共通化PMからも受け、プロジェクト運営に混乱が生じていました。

プロジェクト開始前にメンバー間で責任と役割を明確にして合意形成をしておかないと、プロジェクト開始後に必ず混乱が生じます。そのためにはプロジェクト体制図をしっかり作ることはとても重要な事なのです。

今回の事例のToBe(あるべき姿)は以下の通りです。

関連サービス

2013年09月01日 (日)

青山システムコンサルティング株式会社

池田洋之