PMOのスキルや成果物は、様々なプロジェクトで有効に再利用できる貴重なリソースです。そんなリソースを特定プロジェクトだけで専有していてはもったいない。PMOを"クラウド的"な共有リソースと考えてみてはどうでしょうか。
プロジェクトの「専任PMO」として業務遂行したことがある人は実感できると思いますが、プロジェクトのフェーズや状況によって、PMOの仕事量には大きな波が生じます。寝る暇もないぐらい忙しい時期があるかと思えば、ルーチン的な業務を回していくだけの、余裕がある時期もあります。
PMOの業務は、立ち上がりと終結の時期に負荷が大きくなります。なぜならば、立ち上げ時にはそのフェーズでのプロジェクト運用ルールの整備やひな型の作成、定着化などで作業量が増えます。また、終結の時期では、そのフェーズの成果物の取りまとめや次のフェーズの計画作りで作業負荷が増えます。
一方、当該フェーズを立ち上げて軌道に乗り、プロジェクトメンバーが運用ルールとWBSに従って、粛々と作業を進めていく期間は、PMOとしては課題管理や進捗管理といったルーチン的な作業が中心になります。加えて、『［ヒント14］トラブルに必要な余裕をどう作るか』でも述べたように、PMOの作業をある程度は自動化してしまえば、比較的「余裕」を作り出すことができます。
作業負荷の波は、できるだけ平準化する必要があります。また、PMOのスキルや成果物は、様々なプロジェクトで有効に再利用できる貴重なリソースです。そんなリソースを特定のプロジェクトだけで専有するのは、もったいないと言えます。そこで、各プロジェクトに散らばっているPMOメンバーを組織的に管理することで、「PMOをクラウド的に利用する」という使い方が見えてきます。
つまり、PMOメンバーのリソースプールを作り、必要な時に、必要なだけ、必要なPMOスキルを持った人材を各プロジェクトのPMOメンバーとして割り当てていくのです。そのためには、PMOを組織として機能させる必要があります。PMOをクラウド的な共有リソースとして定義すると、3つのメリットが生まれます。
（1）あるプロジェクトが忙しい時には、当該プロジェクトに対するPMOメンバーのアサインを増やせる。これにより、PMOがボトルネックになってプロジェクト運営が停滞するリスクをなくす。
（2）PMOメンバーが各プロジェクトでの教訓や良いところを知識化して、PMO組織に持ち帰ることができる。これにより、PMO組織としてのスキルや知識が向上し、各プロジェクトにも還元できる。
（3）あるプロジェクトにアサインされているPMOメンバーがスキル不足の場合でも、「一時的に必要なPMO知識」を共有リソースから調達できる。
ただし、PMOをクラウド化すると、プロジェクト専任担当ではなくなるため、プロジェクトへの帰属意識が薄まる可能性があります。また、大手のシステムインテグレーターなどでよく見られるように、PMOメンバーが複数の組織（事業部など）に分散している場合があります。このようなケースでは、PMOメンバーの統合・組織化を巡って「組織的にどう位置付けるか」といった問題も発生し得ると思います。
上記の懸念に対しては、各プロジェクトには数人のプロジェクト専任のPMOメンバーを固定的に割り当て、必要に応じてPMOメンバーを追加するような方法でもいいでしょう。組織の問題として全社的な実施が難しければ、1つの事業部や部門の単位で実施してみるのがよいかもしれません。