プロジェクトマネジメント

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

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

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

 

役立つためのPMOの心構え(嫌われないPMO)

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

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

いずれにしても、PMOは、プロジェクトマネージャ(PM)を支援・サポートする役割なのです。

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

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

 

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

PMOで大切なことってなんでしょうか?

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

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

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

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

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

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

 

PMOとして用意しておく-手元に持っておく-といいもの(組織的なPMO)

カイゼン(KAIZEN)

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

 

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

プロジェクトの標準

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

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

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

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

 

PMOの上位への振る舞い

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

PMがプロジェクト立上げ準備 → 上司(部長)レビュー → PMOレビュー → 役員報告・決裁(金額により)

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

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

 

PMが陥りがちな状況

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

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

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

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

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

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

 

プロジェクトで困った時

これまでの自分の経験やノウハウをもとに、プロジェクトのコンサル、ご支援/PMO、プロジェクトマネージャの育成などを実施しております。
もしプロジェクトでお困りの時はご相談ください。下記にリンクも貼っておきます。

https://simpleonesoft.com/project_support/

-プロジェクトマネジメント

Copyright© SIMPLEONESOFT (BLOG) , 2024 All Rights Reserved.