数値でユーザーを安心させればPMOの評価は高まる

1、KPI設定

最初のプロセスはKPI設定である。KPIを考えるにあたっては、プロジェクト計画で定義した管理領域は何のために設定したのかを考えてみるとわかりやすい。課題管理でいえば、プロジェクトのQCD^※1を計画目標通りに達成するために、課題を確実に検知・対策することが目的なので、検知や対策の度合いを認識できる指標をKPIとすれば良い。具体的には、課題検知数、課題解決数、そして、課題の重みの3つはどうだろうか。本ケーススタディではこれらをKPIと設定した例として話を進めたい。

※1

QCD：Quality＝品質、Cost＝コスト、Delivery＝納期

課題の検知数や解決数については、PMOが主体的に検知・解決したものと、プロジェクトの自助努力で検知・解決したものか区分しておくことが、「だれの」貢献か判別するに必要となるので、課題管理表に識別子（課題検知者）を加えておくといいだろう。次に、課題の重みであるが、仮にその課題を検知しなかった、または、検知したが放置してしまった場合、プロジェクトにどんな被害が想定されたのかをQCDの観点等で定義しておくと、PMOが「どのくらい」貢献したかを計ることが可能になるだろう。

最後に、プロジェクトオーナーほかユーザーとKPIについても合意しておくことも欠かせない。ユーザー幹部の成果評価傾向などのアドバイスを貰えるかもしれないし、折角なのでユーザーに響きそうなKPIを設定したいからである。

2、モニタリング

KPIが明確になったら、次はそれを如何に収集・記録するかの検討であるが、これは一般的な課題管理のスキームに付加するだけでいいだろう。課題を検知し、課題管理表（データベースなどシステム化されているケースもあるだろう）に登録する段階で、その検知者とその課題の重みも登録しておくのである。検知者判定の正当性や、重みの妥当性は、定例会議などPMO内の課題棚卸の場でレビューのうえ確定すればよいだろう。

リソース管理（各メンバのパフォーマンス管理）という目的では、管理対象プロジェクトの特性や工程にもよっては数が多ければよいというものでもないが、課題検知数の量や推移は各メンバの活躍状況把握のひとつの参考値にはなるだろう。また、PMOメンバにとっては、レビューの場で他のPMOメンバがどういう思考・方法で課題を検知しているかといったノウハウを知ることは有益なことだろう。結果、PMO全体のパフォーマンスとモチベーションを向上するという効果を発揮するのである。

3、評価

さて、いよいよ成果の評価である。
そう、「Aさん（皆さんである）、プロジェクトは無事終了したわけだけど、Aさん率いるPMOはどの位貢献したの？プロジェクトメンバの自助努力の結果じゃないの？」にズバッと回答するのである。

PMOによる課題検知数と課題解決数は定常的な課題管理プロセスで計測しているので、その課題数に各課題の重みを乗じた値がプロジェクト成功への寄与度すなわちPMOの存在意義であるという論理で回答してみるのである。

想定被害の未然防止がPMOの存在意義

具体例を示そう。ある課題を放置した場合、開発工程の手戻りにより10人日のリカバリ工数が必要な課題を、10件検知ないし解決したとき、計5人月（100人日）　分の予算増加リスクをPMOが潰した、つまりPMOの成果と定義するのである。ここまで定量的に示せないとしても、課題の20%はPMOが検知している、とか、重要課題10件をPMOが主体的に解決した等の値でもいいだろう。

大事なことは、こういったKPIを、ユーザーのプロジェクトオーナー他関係者に定期的に報告し、ユーザーに安心感をあたえること、他社と差別化できること、そして何より、自分たちの活動成果を定量的に認識することによる自己改善ができることである。

※記載内容（所属部署・役職を含む）は制作当時のものです。