When an organisation grows into several business units, its strategic initiatives multiply faster than its ability to see them. Each division launches its own transformation, technology and expansion projects, often competing for the same capital, systems and specialists. A PMO that worked well inside one unit cannot simply be copied into five. Enterprise PMO scaling is the decision about which governance controls must be held centrally so that the portfolio is visible and capital is allocated deliberately, and which must stay with the divisions so that delivery remains fast and accountable. Within PMO and Execution Governance, scaling PMO operations across business units is therefore a question of decision rights, not of headcount or software. Get the allocation wrong in one direction and the centre becomes a bottleneck. Get it wrong in the other and the enterprise loses sight of where its money goes. Centralise standards. Federate delivery.
Why Does Execution Fragment Across Business Units?
Business units are designed to be autonomous. They have their own leadership, customers, operating models and performance targets. That autonomy is valuable for running the business, but it creates three predictable problems when it comes to change.
First, visibility is lost. Leadership can see each division’s budget but not the combined portfolio of initiatives, so duplication and conflict remain hidden until they become expensive. Two divisions may each be implementing a customer relationship platform, or three may each be negotiating separately with the same technology vendor.
Second, shared resources are contested informally. Group technology, finance, legal and specialist talent are allocated to whichever division escalates most effectively rather than to the initiatives that matter most to the enterprise.
Third, governance becomes incomparable. Each division approves projects using its own criteria, reports progress in its own format and defines risk in its own terms. The board cannot compare a project in one unit with a project in another, so it cannot rank them. Enterprise PMO scaling exists to solve these three problems without taking delivery away from the people closest to it.
Which PMO Model Fits a Multi-Unit Organisation?
There are three broad structural choices. In practice most groups of meaningful size settle on a federated model, but the choice should be made deliberately, based on how integrated the business units are and how much capital flows through shared initiatives.
| Dimension | Centralised PMO | Federated PMO | Decentralised PMOs |
|---|---|---|---|
| Where delivery sits | Central team runs major projects | Divisional PMOs deliver within enterprise standards | Each division runs its own projects independently |
| Portfolio visibility | High | High, through common reporting | Low |
| Speed of local decisions | Slow | Fast within delegated limits | Fast |
| Capital discipline | Strong but can be rigid | Strong at portfolio level, flexible within divisions | Weak across the enterprise |
| Best suited to | Highly integrated businesses with shared platforms | Diversified groups with significant shared investment | Holding structures with genuinely independent businesses |
The federated model balances central oversight with operational flexibility. The enterprise PMO sets standards, maintains the portfolio view and supports capital allocation. Divisional PMOs manage execution in their own context. The difficulty is not choosing the model. It is defining precisely which decisions belong to which level.
What Should the Enterprise PMO Actually Own?
An enterprise PMO that tries to manage every project will fail, and one that only collects reports will be ignored. Its legitimate scope is narrower and more powerful than either. It should own the common language of execution: the stage gates through which initiatives pass, the minimum content of a business case, the definitions of status, risk and benefit, and the reporting format used across the group. It should own the integrated portfolio view and the analysis that supports prioritisation. And it should own the process by which shared resources and enterprise capital are allocated, although the decisions themselves are taken by executive leadership or an investment committee.
Divisions should own delivery: planning, resourcing within their allocation, vendor management for local projects, day-to-day risk management and the realisation of benefits. The enterprise PMO supports and challenges. It does not run divisional programmes.
Standardising Governance Without Standardising Everything
Standardisation is the foundation of enterprise PMO scaling, but it should be applied selectively. Three areas require consistency.
Approval pathways. All business units should initiate projects through the same stage-gate process, with a business case, financial evaluation and strategic alignment review appropriate to the size of the investment. A small local initiative may pass through a light version. A cross-divisional programme passes through the full one.
Reporting and metrics. Milestone progress, financial performance, risk exposure and resource utilisation should be reported in a common format with common definitions. A project marked amber should mean the same thing in every division.
Methodology interfaces. Divisions may use different delivery methods, whether structured or adaptive, provided their outputs map into the common reporting and gate structure. Mandating a single method across very different businesses usually produces compliance on paper and workarounds in practice.
The UAE Group Structure Dimension
Many groups operating in the UAE combine onshore companies under the Commercial Companies Law (Federal Decree-Law No. 32 of 2021), free zone entities and holding or financing vehicles in the DIFC or ADGM. Business units frequently map onto separate legal entities, each with its own board. An enterprise PMO does not override those boards. Directors of each entity remain responsible for decisions that bind their company, so the PMO’s decision-rights framework should align with the group’s delegation of authority and with the reserved matters of each subsidiary board.
Cost allocation also needs care. Where an enterprise PMO is funded centrally and recharged to business units in different legal entities, those recharges are transactions between related parties. Under the UAE Corporate Tax regime (Federal Decree-Law No. 47 of 2022), transactions between related parties are expected to follow the arm’s length principle and may carry transfer pricing documentation requirements. The charging model should be agreed with the group’s tax advisers when the PMO is designed, not after the first year-end.
Original Analysis: The Federated Control Matrix
The practical test of a scaled PMO is whether every recurring governance decision has one clear home. The Federated Control Matrix allocates eight such decisions across three levels: the enterprise PMO, the divisional PMO and the project team. Each cell carries one of four roles: Decide, Set Standard, Execute or Inform. The allocation of shared resources is the decision most often misplaced.
| Governance Decision | Enterprise PMO | Divisional PMO | Project Team |
|---|---|---|---|
| Stage-gate criteria and business case template | Set Standard | Execute | Execute |
| Approval of initiatives above the enterprise threshold | Prepare for executive decision | Sponsor and submit | Inform |
| Approval of initiatives below the threshold | Inform | Decide | Execute |
| Allocation of shared resources and enterprise capital | Decide, through executive forum | Request and justify | Inform |
| Reporting format and status definitions | Set Standard | Execute | Execute |
| Delivery planning and methodology | Inform | Decide | Execute |
| Escalation of cross-divisional conflicts | Decide | Escalate | Inform |
| Benefits tracking and post-implementation review | Set Standard | Decide | Execute |
The matrix makes two things explicit. The enterprise PMO decides very little on its own; its power comes from setting standards and preparing the decisions that executives take. And divisions retain genuine authority below an agreed threshold. Most scaling failures come from leaving the shared-resource row undefined, so that allocation is settled by escalation rather than by priority.
How Should PMO Scaling Be Sequenced?
Attempting to impose the full governance model on every business unit at once is the most common reason enterprise PMO programmes stall. A staged rollout builds credibility by delivering visible value early and extends control only as divisions see the benefit. Each stage should have a clear exit test before the next begins.
| Stage | Focus | Exit Test |
|---|---|---|
| 1. Visibility | Common taxonomy and a single inventory of all initiatives across units | Every active initiative above a minimum size is recorded with owner, budget and status |
| 2. Comparability | Common reporting format, status definitions and stage gates | Leadership can rank initiatives across divisions on the same criteria |
| 3. Allocation | Shared resource and capital allocation through an executive forum | Contested resources are assigned by priority, not escalation |
| 4. Value | Benefits tracking and post-implementation review | Approved benefits are measured and reported after delivery |
Visibility comes first because it costs divisions little and immediately shows leadership what it has been missing. Allocation comes third because it is the stage at which divisions give up informal influence, and they will accept that only once the portfolio view has proved its accuracy.
A Worked Example: Consolidating the Portfolio View
Consider an illustrative group with four business units running 62 active initiatives with a combined approved budget of AED 310 million. Before scaling, each unit reports in its own format. The new enterprise PMO applies a common taxonomy and finds that three units are separately implementing customer relationship platforms with a combined budget of AED 18 million, that 14 initiatives rely on the same 22 data engineers, and that nine projects worth AED 41 million have no measurable benefit in their business cases.
Executive leadership consolidates the three platform projects into one programme with a revised budget of AED 11 million, re-sequences the data engineering work so that no more than eight initiatives draw on the team at once, and returns the nine projects to their sponsors for revised business cases at the next gate. Roughly AED 7 million is released immediately and AED 41 million is placed under review. The figures are illustrative. The pattern is common: the first integrated portfolio view usually pays for the enterprise PMO.
Technology as the Backbone, Not the Strategy
A portfolio management platform consolidates execution data from multiple divisions into a single environment, so leadership can see progress, financial exposure and resource use across the enterprise. It is an essential enabler, but it should follow the governance design rather than define it. A platform configured before the decision rights and status definitions are agreed will simply automate inconsistency. Agree the matrix, the taxonomy and the reporting standard first. Then configure the tool to enforce them. The platform should also make the matrix visible: who approved each gate, which resources were requested and granted, and where escalations were resolved. That audit trail is what allows the board to rely on the portfolio view rather than commission its own.
Common Enterprise PMO Scaling Failures
- Expanding the central PMO into a delivery organisation, which slows divisional decisions and creates a bottleneck at the centre.
- Issuing standards without an enforcement point, so divisions adopt them unevenly and the portfolio view remains incomplete.
- Leaving shared-resource allocation undefined, so the most persistent division rather than the most important initiative wins.
- Mandating a single delivery methodology across very different businesses instead of standardising only the reporting interface.
- Ignoring legal-entity boundaries, so PMO decisions conflict with subsidiary board authority or create unplanned intra-group charges.
- Buying a portfolio platform before defining decision rights, which turns inconsistent practices into inconsistent data.
- Measuring the enterprise PMO by the volume of reports it collects rather than by the quality of the decisions it enables.
Each failure reflects the same underlying error. Control was centralised where it should have been standardised, or left local where it needed a single owner.
Conclusion
Scaling PMO operations across business units is not about building a larger central function. It is about deciding, decision by decision, where control belongs. The enterprise PMO should own the common language of execution, the integrated portfolio view and the process for allocating shared resources and capital. Divisions should own delivery within those standards and below agreed thresholds. The Federated Control Matrix makes that allocation explicit and exposes the gaps, most often around shared resources, where escalation replaces priority. In UAE groups spread across onshore, free zone and financial free zone entities, the matrix must also respect subsidiary board authority and the arm’s length treatment of intra-group charges. Technology then enforces what governance has defined. When the allocation is clear, the enterprise sees its whole portfolio and divisions keep their pace. Standards travel. Delivery stays local. Capital follows priority.
