PMOと言えば・・・進捗管理、課題管理といったPMBOKベースの管理業務部隊。そんなイメージが強いかもしれません。確かにこういった管理業務は絶対に必要ですし、こういった活動が安定して行われていることが、プロジェクトの基礎にもなります。
これがやれていないプロジェクトは、相当少人数で1つの解を追い求めているような戦略的プロジェクトならまだしも、大人数・多領域横断の施策検討や（ITだけでなく）開発プロジェクトならありえないでしょう。
プロジェクトマネジメントでは基礎的なトーンで扱われることが多い一方、しっかりとPMOの役割を理解して運営できているパターンは少ないと感じます。
ましてや、もし仮に「PMOは基礎的な領域」であるなら、わざわざ外部のコンサルタントを雇う価値はなんでしょうか？
■プロジェクト管理者から見たPMOの必要性。
ここで言うプロジェクト管理者というのは、
- 請負で行う、特にITプロジェクトの場合は請負側が立てるプロジェクトマネージャー（PM）というよりは、発注したクライアント側のプロジェクト責任者（プロジェクトの大きな方向性について意思決定権を持つ人）。
- クライアントにプロジェクトマネージャー（PM）がいる場合は、その人。コンサルタントやベンダーと混合チームを編成する場合も同様。
というのを指しています。
ちょっと複雑な言い方をしてしまいましたね。簡単に言うと会社からプロジェクトを任されたクライアント側の責任者で、
「自社だけで大きなプロジェクトを管理推進していく自信がないなぁ or ノウハウや工数が足らないから外部調達しなきゃなぁ」
という人たちのことです。
昨今は「自分たちの事業が目指すところや、施策は自分たちが主体で考えて実行しなければ」という考えをしっかり持っているクライアントも多く、コンサルティングファームに丸投げするようなことは少ないです（デジタルトランスフォーメーションなどの専門領域は除く）。
そうすると、基本的にはクライアント主体で進めたいが、プロジェクトコントロールや検討の進め方・議論のサポートが欲しい、という意図でサポート的に仕事を受けることが多いです。PMOチームも含めて、各領域ごとにクライアントとコンサルタント混在チームを置くという体制です。
予算が限られていると、プロジェクト体制の頂上にいるプロジェクトマネージャーの側近としてPMOだけを発注することも多くあります。この場合、クライアントからPMOチームへの期待は過剰になることもあり、工数と金額の問題からスコープを細かめに設定しておかないと働くコンサルタントメンバーはシンドイ想いをすることになるかもしれません。
ざっと書いてもわかる通り、PMOの必要性はそのプロジェクトごとに結構異なります。プロジェクトマネジメントそのもののノウハウを身につけるためだったり、難易度の高いプロジェクトを管理するスキル・工数確保のためだったり、さらには現場メンバーがプロジェクトマネージャーの言うことを聞かない（ガバナンスが効いてない）ので外部の人間に間を取り持ってもらいたい場合も多々あります。