A steering committee meeting in an Olaya boardroom deserves the real project status, not the version that sounds better than what's happening on the ground.

The vendor runs their delivery. The PMO runs the project on your behalf, which is a different job. It holds the vendor to the RFP commitments and contract, tracks value against the business case, coordinates your internal teams, and escalates problems while they are still small. Without it, the client side of an implementation tends to be a finance director doing a second full-time job.

What the PMO controls

Scope, through a formal change process so that every addition is priced, approved and sequenced rather than absorbed quietly into a slipping timeline. Schedule, through an integrated plan that includes your internal tasks, data cleansing, testing, training, not only the vendor's configuration milestones. Budget, tracked against the full investment picture including internal costs. Risk and issues, logged, owned and reviewed weekly rather than surfacing at steering committee after they have become crises.

Saudi-specific project governance

Kingdom implementations carry dependencies a generic PMO plan overlooks: ZATCA Phase 2 onboarding and certification timing, GOSI and WPS payroll cutover windows that cannot slip past a pay date, Hijri year-end close alongside Gregorian, and Arabic-language testing and training that must run in parallel with English. The PMO builds these into the critical path rather than discovering them as late surprises.

Managing the vendor relationship

Weekly status meetings are run to your agenda, not the vendor's. Deliverables are accepted against written criteria. Invoices are released only when milestones are genuinely met. Disputes are documented while the facts are fresh. This is not adversarial, good vendors welcome a competent client-side PMO because it removes ambiguity, but it does shift the balance of information decisively toward the client.

A common Saudi scenario

An Riyadh industrial group is four months into an Oracle implementation. The vendor's reports show green status. The PMO's integrated plan shows that data migration for two of five entities has not started, that the payroll cutover is scheduled for the week of a salary run, and that the ZATCA integration partner has not yet been engaged. Raised at steering committee with evidence, the timeline is re-baselined realistically instead of collapsing at go-live.

What you receive

An integrated project plan, a change control process, weekly status reporting in a format leadership can read in five minutes, a risk and issue register with owners, steering committee preparation and facilitation, vendor deliverable acceptance, and a benefits tracking framework that continues past go-live into the first year of operation.

Keeping the business case alive after go-live

The PMO's job does not end at cutover. The benefits promised in the business case are tracked for the first year of operation, with the same rigor applied to realized savings as was applied to projected ones. Where a benefit is not materializing, the PMO identifies why, an unused feature, a process that reverted to the old way, a workflow that needs redesign, and drives the fix rather than letting the gap become permanent.

Local context

Multi-entity groups across Riyadh need the PMO to run entity-level workstreams with local owners, since a single central plan without site-level accountability is where cutover tasks quietly fall behind.