PMOの役割と3つの類型
PMOという部署名は広く使われていますが、実際に何をしているかは組織によってまったく違います。テンプレートを整備している部署もあれば、全案件の進捗を審査している部署も、PM自身を抱えて案件を回している部署もあります。
この違いは、担当者の力量ではなく与えられた権限の差です。そして、この点を曖昧にしたまま立ち上げたPMOは、まず機能しません。
■ PMOの3つの類型
支援型は、道具を提供する立場です。テンプレート、チェックリスト、研修、過去事例。使うかどうかは各プロジェクトの判断に委ねます。導入しやすい一方、成果が見えにくく、「あの部署は何をしているのか」と言われやすい面があります。
コントロール型は、標準の遵守を求める立場です。報告様式を定め、フェーズ移行時に審査を行います。案件間で水準を揃えられますが、現場からは「手続きが増えた」と受け取られやすく、導入時の説明が重要になります。
指揮型は、PMO自身がPMを配置し、プロジェクトを直接動かす立場です。PM人材を集約して育てられる利点がありますが、事業部門との間で責任範囲の整理が必要になります。
■ 最も多い失敗
実務で頻繁に起きるのが、権限は与えられていないのに、統制を期待されるという状態です。
「各プロジェクトの状況を把握して報告してほしい」と言われて立ち上がったPMOが、報告を集める役割だけを担うことになる。現場からは「資料を作らせる部署」と見なされ、都合の悪い情報は上がってこなくなります。集まるのは形式的に整った報告書だけで、実態は見えません。
これを避けるには、立ち上げの時点で次の3つをセットで決めておく必要があります。
どの型で始めるのか：支援なのか、統制なのか
どこまでの権限を持つのか：標準の遵守を求められるのか、フェーズ移行を止められるのか
何をもって評価されるのか：報告書の提出率ではなく、何が改善されたかで測る
■ 段階的に立ち上げる
最初からコントロール型を目指すと、たいてい抵抗に遭います。現場にとっては、手続きが増えるだけに見えるためです。
現実的なのは、支援型から始めて信頼を得る進め方です。
まず、現場が困っていることを聞いて回る。報告様式の押し付けから始めない
テンプレートや過去事例など、使えば楽になるものを提供する
使われ始めたら、その様式を標準として位置づける
標準が定着した段階で、フェーズ移行の審査などの統制機能を加える
「PMOに相談すると助かる」という実績が先にあれば、後から統制を加えても受け入れられます。順序が逆になると、統制だけが残って支援が届きません。
■ PMOが持つと効く機能
型にかかわらず、多くの組織で効果が出やすい機能があります。
実績値の蓄積：案件ごとの見積りと実績、工数配分、不具合件数を一か所に集める。次の見積りの根拠になる
テンプレートの整備：計画書、WBS、課題管理表、報告様式。毎回ゼロから作る手間を省く
横断的なリスクの把握：複数案件で同じリスクが出ていれば、組織として手を打つべきサイン
要員の融通：案件をまたいだ人員の配置調整
PM同士が話す場の運営：経験の共有は、研修より効くことが多い
このうち、最初に着手する価値が高いのは実績値の蓄積です。手間が小さく、効果が数字で示せるためです。「前回の同規模案件では見積りの1.3倍かかりました」と言える状態は、PMO自身の存在価値の説明にもなります。
■ 評価指標の置き方
PMOの評価を「報告書の提出率」や「標準の遵守率」に置くと、形式を整えることが目的になります。
見るべきは結果のほうです。案件の遅延率が下がったか。見積り精度が上がったか。同じ失敗の再発が減ったか。時間はかかりますが、こうした指標で測るほうが、PMOの活動が現場の役に立つ方向に向かいます。
■ チェックリスト
どの型で立ち上げるかが合意されているか
権限の範囲が文書で定められているか
支援機能から始める順序になっているか
実績値を集める仕組みがあるか
評価指標が形式ではなく結果を見ているか
PMOは、置けば機能する部署ではありません。何を任され、何を決めてよいのかが定まってはじめて動き始めます。立ち上げの相談を受けたときに最初に確認すべきは、組織図上の位置ではなく、その二点です。