PMOとしてPJに参画する際に確認すること

投稿の目的

数多くのPJでPMOを経験してみて、
PMOとしてまず動く時にどんな事から始めるかをまとめてみました。

プロジェクトの概要と進捗確認

PMOに限らず、どのポジションでも必要なことだと思うけど、だいたい以下のような事を確認している。

• プロジェクトで実現したいこと

• プロジェクトのマネジメント体制の推移

• 現フェーズの予定と実績差異

• 前フェーズからの申し送り事項

最初のプロジェクトの目的に関しては
設計思想や課題解決する際の軸にする。
プロジェクトによってはこの軸とは違う動きを
してしまう事があるので、注意が必要。
この確認する行為が既存メンバーが
再認識するいい機会になる事がある。

マネジメント体制の推移に関しては
今のマネージャーがいつからプロジェクトに
携わっているかの確認と
当時いなかったからわからない
がどれくらいありそうかの確認になる。

前フェーズからの申し送り事項が曲者で
内容によっては前フェーズが終わっていないに等しい
決定内容としては大きな仕様変更が必要になる
という事がある。

PMOに求めている事の確認

理想は、課題が明確になっていて、それを解消するために
PMOとどうしてほしいというのがあればいいけど
大抵はそこまで整理できていない事がほとんどだと思う。
特に炎上PJの場合は。

ただ一番良く無いと思うのは、PMOが入ればPJが
良くなるという漠然とした理由で設置する事だと思う。

求めている事として、PJがうまくいかない理由や課題を
洗い出して改善したいというのが目的であれば
PMOもまずはその洗い出し、その解決策を
検討・導入する事ができる。

しかし、こういった目的が無いと
「PMOを入れたのにPJが改善されない」
「PMOがこれもやってくれると思っていた」
「PMOが何しているのかわからない」
などPJとPMO間での対立などが起きたりする。

過去のPJで何度かそのような場面を見聞きしたり
実際にPMOにアサインされた方が短い期間で離脱する
といった事が起きた事もある。

プロジェクトのシン・体制を確認

PMBOKのステークホルダーマネジメントになるけど
PJ体制に記載が無い人が該当PJへの発言権が強かったり
PMよりもTLのほうに決定権があったりするPJが存在する。

前者に関しては、本来はアサイン予定だったが
前段や別のPJにアサインされていて合流できていないなど
によって、発生する事がある。

ただこういう方に限って、仕様の背景や例外パターンなどを
熟知している可能性が高いので早めに過去のドキュメントや
現PJの要件定義などに名前が良く見られるがPJにいない方を
探すなどして特定し、週に何時間でもいいからサポートを依頼する。

後者の場合には、PMがあくまでPJの決定者になるので
課題の担当者はTLでTLの報告を受けてPMが承認するという
流れを作る。