ＰＭＯが嫌われる理由【役立つためのＰＭＯの心構え】

世の中にまだＰＭＯという言葉も浸透していなかったころ、僕は日本ＩＢＭのコンサルの方の指導のもと、以前の会社でＰＭＯの組織を立ち上げた。
最初にいろいろ教えてもらっているときに、ＩＢＭの実際のＰＭＯのレビューの現場に同席させてもらったのだけど、これがＰＭＯか、ということがよくわかった。

その時の体験と実際に僕がＰＭＯやプロジェクトの支援をやった経験などを交えて、ＰＭＯ、プロジェクト支援論を今回は展開させていただきます。

役立つためのＰＭＯの心構え（嫌われないＰＭＯ）

ＰＭＯとは、（プロジェクトマネジメントオフィス：Project Management Office）の頭文字をとったもので、プロジェクトに対する支援・サポートをする組織やチームを指します。

組織横断的なプロジェクト支援、監査をするためにＰＭＯという組織（部署）をつくることもあれば、
大規模なプロジェクトの場合は、プロジェクト内でＰＭＯというチームをたててＰＭの補佐をすることもあります。

いずれにしても、ＰＭＯは、プロジェクトマネージャ（ＰＭ）を支援・サポートする役割なのです。

ＩＢＭでＰＭＯをやっていた方は、プロジェクトマネージャからプロジェクトの状況をヒアリングすると即座に、「ここはこうした方がよくなるかも知れませんね。やり方の資料は持っているのでお渡しします」と課題を見つけて対策を出していた。

ダメをダメで終わらせず、具体的なやり方を示してあげる。
ただし、実際のプロジェクトの業務を想定されることには、手出しをしない。

組織横断のＰＭＯとしては、納得ができる行動だった。
僕も指導をうけながら自分の会社にＰＭＯ組織をつくる立場だったので、まねできるように多くを学び取ろうという気持ちで臨んだ。

「ＰＭＯで大切なことってなんでしょうか？」

「プロジェクトやＰＭの役に立つことを心がけています。
現場のＰＭの方は、ＰＭＯのレビューを会社としての監査だと思っています。

ＰＭＯのレビューを通らないと、プロジェクトを進めることができないからしぶしぶレビューをしてもらう、ということになれば、ＰＭＯレビューはこうすれば通る、という本質とは関係ないところでプロジェクト側が対応してくることになります。
そうなったら、ＰＭＯの存在価値はなくなりますよね。

わたしはそうではなくて、ＰＭＯのレビューによって、プロジェクトが成功に近づく、ＰＭＯのレビューに助けられたといってもらえるようにＰＭＯの実務をやっていきたいのです」

確かにその方のようなレビューができるのであれば、プロマネの方も助かるに違いないです。
実際、ＰＭＯのご担当は当時は３名ほどのようでしたが、僕にＰＭＯを手ほどきしえくれた人は常にレビューして欲しいとプロジェクト側から依頼が絶えなかったようです。

なんせ、ダメダメ指摘されるのではなくて、こうすればいいですよという言葉とともに、具体的なやり方やひな形の資料までもらえるのです。

僕も彼の教えを心にとめながら、ＰＭＯ組織を立ち上げて、小さなプロジェクトを兼務しながらですが、ＰＭＯ組織を１年ほど運営しました。
教えがなければきっと無理でしたが、ＰＭＯとしての実施内容などもいただいて、なんとか１年間、ＰＭＯを続けることができました。

ＰＭＯとして用意しておく-手元に持っておく-といいもの（組織的なＰＭＯ）

カイゼン（ＫＡＩＺＥＮ）

ＰＭＯをやるなら、各種標準やツール等の情報を集めて、プロジェクトに対して展開をすると喜ばれます。

１つのプロジェクトから他のプロジェクト

・プロジェクトの標準

プロジェクト計画書のひな形
スケジュール・ＷＢＳひな形
課題管理票
リスク管理表
体制図（例）
プロジェクト
計画書記載内容・記載説明

プロジェクトのチェックリスト（局面完了基準）

・プロジェクト事例
画面標準
コーディング標準
設計標準
性能測定の考え方、やり方
生産性の指標
テスト・品質の基準

・おすすめツール類の資料（製品や他ＰＲＪで効率化のために開発したツール）
性能測定（大量トランザクション発生）ツール
カバレッジツール
テスト支援ツール

ＰＭＯの上位への振る舞い

会社組織のＰＭＯとしては、会社の経営層への会社として重要なプロジェクトの状況報告は重要なタスクですが、プロジェクトのレビューを実施している時には、上への報告については一切触れていませんでした。

ＰＭがプロジェクト立上げ準備　→　上司（部長）レビュー　→　ＰＭＯレビュー　→　役員報告・決裁（金額により）

様々なケースがありますが、上記のような流れがひとつのパターンです。
会社としての重要案件は役員決裁になるケースが多いと思います。

ＰＭＯは、プロジェクトの状況を客観的に判断し、上位層にレポートするのも役割です。
自分のプロジェクトの状況だと、正確な報告ができていないケースがあるため、客観的な報告も大切になります。

ＰＭが陥りがちな状況

・スキル不足でプロジェクトの課題や状況を把握できておらず、報告ができていない
・決裁がおりないと客先に費用が払えない等の問題を先送りにし、あたりさわりのない報告をする
（故意による遅延や障害の状況を隠蔽）
・指摘対応が面倒、出世に響く等の理由で、計画通りという報告をする
・ＰＭやその上司が、多少の遅延ならリカバリー可能と判断し報告をしない

いずれも何度か目の当たりにしてるし、自分がＰＭをしたプロジェクトでは、ＰＭとしての判断で上位報告するしないのフィルターはかけていました。

ＰＭＯはそういうＰＭの実施していることも機敏に察知し、ＰＭＯとしての判断をして上位報告するか、ＰＭに指摘して報告してもらうかの選択が必要となります。

自分は結局、立上げ後１年で他のかたに譲りました。他に大規模なプロジェクトが発生して、結局のところ、実プロジェクトのＰＭを担当することになったからです。

ＰＭに復帰したとき、ＰＭＯをやったおかげかＰＭとしてのスキルも向上したのを感じました。

以上、ＰＭＯをやるための心得、ＰＭＯとしてやっておくべきことを整理してみました。