最近、PMO(Project Management Officeほか、何種類かある)という言葉がはやり始め、導入している組織も多いことと思います。
ですが、多くの場合、PMOはプロジェクトマネージャの補佐として動いているのではないでしょうか。
位置づけ
以前、ポートフォリオの話を書きましたが、管理の仕方はいろいろあるにせよPMOは会社にあるソフトウェア資産というポートフォリオの価値を最大化させるというのが最も大きな目的となります。
通常、プロジェクトマネージャは自分の扱うプロジェクトの利益を最大化するために注力するものです。いわゆる個別最適化です。一方でPMOには複数のプロジェクトにまたがった最適化を行う責務があります。
人選
PMOは、ポートフォリオの価値に興味がある取締役を中心に組織するのが良いです。
PMOにはある程度の予算と権限、そして人的リソースが必要です。特に、人的リソースについては、一番良い人を当てることが大事です。
PMOはプロジェクトマネージャを指導する立場になる場合もありますから、プロジェクトマネージャから信頼されていなければいけません。どうでもよい人を当てると、すぐにプロジェクトマネージャの補佐的仕事をする組織になってしまいます。
とはいえ、プロジェクトの指揮官はプロジェクトマネージャなのですから、プロジェクトマネージャの最終的な判断を支持しなければいけません。でないと、うるさいだけの人になって、プロジェクトマネージャのやる気をそいでしまいます。
プロジェクトマネージャとの関係
プロジェクトマネージャは大きな責任を負っていますから、その負担を軽くしてあげることが大事です。プロジェクトがうまくいかないとき、単に責めるのは良くありません。一緒になって考えることが大事です。
一方で冷静な視線で、プロジェクトマネージャを評価することは大事です。特にプロジェクトマネージャがプロジェクトの状況を理解しているかどうかは重要なポイントです。
プロジェクトをコントロールしたうえでの遅延は、先が予測できるので大きな問題ではありません。
反対にたった今、遅延がなくてもプロジェクトの先が読めないというのであれば、すぐに手を打たないと大変なことになります。
プロジェクトの状況を聞いたときに、リスクや体制、進捗などをすらすら答えられるかどうかで大体はわかると思います。
そうそう、プロジェクトをやめるという判断はプロジェクトマネージャにはできません。
これはPMOの最も大事な仕事のひとつです。
最後に
いろいろ書きましたが、最後に。
標準化だなんだといったところを、PMOが行うことは多いのですが、莫大な工数がかかるので中途半端になるのがオチです。
明確に解決したい課題がない限り、やめておくべきでしょう。
そもそも、PMOはマネジメントの専門家であって、ソフトウェア工学の専門家ではありません。
どう作るかについてはソフトウェアアーキテクトに任せておくのが良いと思います。
それに、そんなことをしている暇もないくらい、PMOは忙しいですよ。
