過去の成功プロジェクトで使われた管理指標や管理シートを、自分のプロジェクトに合うかどうかも考えず、そのまま流用するプロジェクトが多くあります。こうした場合、PMOは得てして単なる"管理屋"となりやすく、所定の管理シートに情報が漏れなく記入されているかどうかだけを気にするようになります。
PMOの重要な役割の1つに、様々なマネジメントスキームの導入支援があります。進捗管理や課題管理、リスク管理、変更管理、品質管理、予算管理といった仕組みを、プロジェクトのなかにうまく導入することです。マネジメントを「管理」と訳してしまうとニュアンスが変わってしまいますが、通例になっているので、以下では「××管理」と表記します。
管理スキームは、プロジェクトの状況を把握するために必須です。PMOがそう説くと、メンバーの間で管理そのものは必要だという理解はされるのですが、ではそのスキームをプロジェクト全員に周知徹底しようとすると、骨が折れることがしばしばです。
特に実行段階に入った大きなプロジェクトを、複数企業からの混成チームで進める場合、管理スキームの徹底は相当苦労します。メンバーが全員、プロジェクト管理に慣れ親しんでいる人ばかりだったとしても、それぞれが管理のやり方にこだわり出し、調整が難航してスキームの徹底が遅れかねないのです。
課題管理一つ取っても、管理で必要とする項目や、考え方が人によってそれぞれ異なっていたりします。課題のステータスを示す項目を「起票、対応中、終了」という簡単なものにするか、「起票、事前準備、検討中、承認待ち、完了」と細かく分けるのか、いったいどの項目を使うのか、それだけでも調整が大変です。課題管理シートや課題管理プロセスを定義しても、それらを素直に受け入れる人と、こだわりがあって反発する人に分かれ、ここでもまた調整に時間を取られます。
進捗管理についても、報告に様々なやり方があります。作業の進捗数値をパーセンテージで入れる場合、いくつかのパターンに分かれます。
10種類の設計書に対し、5種類のプログラムが完成したから進捗を50％と算出する場合もあれば、あらかじめ予算としておいた必要期間や工数を何％消化したかという「予算消化率」で表現することもあります。進捗数値の算出方法を決めるにも調整が必要となりますし、この調整もまたもめるところです。
厄介なのは、感覚的に完成度合いを測っていながら、何％と数値で報告してくるケースです。ある案件について「進捗率80％」と報告した後、何週間たってもやはり「80％」と報告してくる。実際、こうしたケースをしばしば見かけます。こうなると、残りが20%といっても、どのような仕事がどのくらい残っているのか分かりません。こういう事態をなくすためにも、進捗管理の報告のやり方を決めておかないといけないわけです。
一連の管理プロセスを決めるための調整工数を減らしたり、効率的に管理したりするために、プロジェクトマネジメントの方法論（メソドロジー）や、過去の成功プロジェクトで使われた成果物（管理指標やシートなど）がしばしば使われます。PMOは、担当するプロジェクトに合った方法論や、応用できる成果物を探し出し、プロジェクトメンバーに対して方法論の研修を実施したり、成果物を提供したりします。
ところが現実には、そのプロジェクトを改善できる管理方法なのか、プロジェクトに合っているのかを検討せずに、方法論だけを導入しようとするケースが見られます。こうなると、PMOは単なる管理屋と化し、所定のフォーマットに情報が漏れなく記入されているかどうかだけを気にするようになります。これでは、本質的なプロジェクトマネジメントの改善につながりません。
よく考えもせずに、方法論や管理ツールだけを導入しようとするPMOに限って、各チームリーダーにしつこく報告を求めたりします。各チームからすると、PMOが管理をしたいがためにチームに報告を求めているように見え、「管理のための管理」と言わざるを得ません。PMOは「何のために管理するのか」という基本について深く考える必要があります。
管理することによって抽出された情報は、マネジメントに活用され、その結果、プロジェクトが改善されなければなりません。進捗管理により作業の進み具合を測り、課題管理により進捗の阻害要因を把握し、リスク管理により将来起こる問題の発生可能性を測ることは、全てマネジメントの意思決定に寄与します。
つまり、管理はマネジメントの意思決定につながるべきであり、素早い意思決定や的確な意思決定が管理の成果、そしてPMOの成果になります。
プロジェクトの規模が大きくなり、プロジェクトメンバーが気心知れたプロパーの社員だけではなく、中途入社した社員や組織文化の異なる外部の社員、あるいは個人事業主のプロフェッショナル、さらには海外のメンバーが混在する場合、現場任せのマネジメントを行うことは大きなリスクを伴います。
情報システムの開発プロジェクトを例に取りましょう。プロジェクト当初は互いによく知ったメンバーで作業を進めることになり、密なコミュニケーションが取れ、夜もノミニケーションの機会が頻繁にあり、管理に関してさほど注意が払われません。というより、この状態では管理の必要があまりないのです。
プロジェクトが順調に進み、設計作業に入っていくとメンバーが増え、管理プロセスが必要になりますが、急にPMOの作業が増えるため、様々な点で後手に回り、管理プロセスの導入についても十分な時間をかけることができません。そもそも現場は、仲良しメンバーでやっている居心地のよさを保ちたいと思っていますから、なおさら管理すること、されることに抵抗を感じます。このままプロジェクトが進んでいくと、中盤以降になって状況把握が困難になり、最後はシステム利用の遅延や予算超過に陥ります。今一度、プロジェクトの状況に応じた管理の在り方を考えてみるべきです。