PMO and VMO as a service: governing projects and vendors with metrics

In many IT organizations the problem is not a shortage of projects or vendors. It is the lack of a single view across both. Each initiative reports in its own way, each contract gets reviewed only when something breaks, and the steering committee receives information late and in different formats. A project management office (PMO) and a vendor management office (VMO) exist to fix exactly that: to turn delivery and third-party relationships into something measurable and governable.

This article explains what each office does, when it makes sense to run them as a service instead of building them in-house, and which metrics, contract terms and governance rituals are worth having from the first month.

What a PMO does and what a VMO does

They are often mentioned together, but they answer different questions.

The PMO answers: are we doing the right projects, and are we doing them well? Its usual functions are:

• Maintaining the portfolio inventory: which projects exist, their status, budget, sponsor and expected benefit.
• Defining a common method (phases, minimum deliverables, phase-gate criteria) without imposing a single methodology; agile and predictive teams can coexist.
• Consolidating reporting on progress, risks, issues and scope changes.
• Supporting prioritization and capacity balancing across initiatives.
• Ensuring formal closure: lessons learned, handover to operations and benefit verification.

The VMO answers: are our vendors delivering what we pay for, and are we controlling the risk they bring? Its usual functions are:

• Maintaining the register of vendors and contracts: services, terms, amounts, renewals and internal owners.
• Measuring performance against SLAs and contractual obligations.
• Managing third-party risk: dependency, concentration, information security and continuity.
• Running periodic reviews with each vendor and tracking improvement plans.
• Preparing renewals, renegotiations and exits based on data, not perceptions.

The link between the two is direct. Much of IT project work is delivered by vendors, and many vendor problems first show up as a project delay. When the PMO and VMO share data, the committee sees the cause and not just the symptom.

When the "as a service" model makes sense

A PMO or VMO as a service means an external team runs the office's functions, tools and reporting, while the organization keeps the decisions: prioritizing, approving, renewing or penalizing. It is not outsourcing governance; it is outsourcing the mechanics that make governance possible.

The model usually makes sense in these situations:

• There is no office, or it is understaffed. Building an internal PMO takes time for hiring, defining the method and choosing tools. A service lets you start with a proven method and adjust later.
• Portfolio peaks. A transformation program, a cloud migration or a core system replacement multiplies projects and contracts for a limited period.
• Need for independence. When reporting comes from a third party that does not deliver the projects, status indicators are more likely to reflect reality.
• Regulatory expectations on third parties. In regulated industries, supervisors expect evidence that critical vendors are managed. A VMO with a register and documented reviews makes that easier to show.

There are also cases where it does not fit. If the portfolio is small and stable, a light internal function may be enough. And if the organization is not willing to make decisions based on the data the office produces, no service model will fix that. A common mistake is to buy reporting without first defining who decides on it.

Portfolio and vendor metrics

Metrics should be few, comparable across periods and tied to a decision. The table below proposes a starting set; specific targets depend on each organization and are agreed with the committee.

Scope	Metric	Question it answers
Portfolio	Schedule variance per project	Which initiatives are slipping, and by how much?
Portfolio	Cost variance against approved budget	Where are we spending more than planned?
Portfolio	Scope changes approved in the period	How stable is what we defined?
Portfolio	High risks open without a response plan	Where are we exposed with no action?
Portfolio	Benefits verified after closure	Did the delivery produce what justified the investment?
Vendors	SLA attainment per service	Is the vendor delivering the agreed level?
Vendors	Incidents attributable to the vendor	How much instability does it bring?
Vendors	Overdue improvement actions	Does it deliver on what it commits to fix?
Vendors	Concentration of spend or critical services	Do we depend too heavily on a single third party?
Vendors	Contracts nearing expiry without a decision	Will we reach a renewal unprepared?

Two practical recommendations. First, every metric needs a written definition: formula, data source, frequency and owner. Without it, the committee ends up debating the number instead of the action. Second, separate control metrics (reviewed every month) from analysis metrics (consulted when something drifts).

SLAs and penalties: how to think about them in the contract

A useful SLA describes a measurable service level, how it is measured and what happens if it is missed. The ITIL 4 service level management and supplier management practices, and ISO/IEC 20000-1 for service management systems, provide a recognized basis for structuring them.

In general terms, a well-built IT services contract usually includes:

• A precise service definition and its boundaries: what is included and what is not.
• Metrics with a measurement method: availability, response and resolution times by priority, deliverable quality. Agree on who measures, with which tool and over which window.
• Exclusions: scheduled maintenance, causes attributable to the client or to other third parties.
• Service credits or penalties: typically a percentage of the period's fee, tiered by severity and capped.
• Repeated breach: what happens if the SLA is missed several periods in a row, including the right to terminate.
• Improvement plans: an obligation to present root cause analysis and corrective actions with dates.
• Audit and information access rights, especially relevant in regulated industries.
• Exit and transition: return of data, documentation and support during handover to another vendor.

A caveat: penalties do not improve a service on their own. Their role is to align incentives and give the conversation an objective basis. If the SLA measures what is easy to measure rather than what matters to the business, the vendor can report green while users suffer. That is why technical SLAs should be complemented with some experience or business impact indicator.

Governance cadence: who meets, when and why

Metrics are only useful if there is a meeting rhythm that turns them into decisions. A typical three-level cadence:

1. Weekly, operational. Project managers, the PMO and technical leads review progress, blockers and new risks. With vendors, they review open incidents and the week's deliveries. Output: actions with an owner and a date.
2. Monthly, tactical. The PMO and VMO present the consolidated dashboard to IT management. SLA attainment is reviewed, minor scope changes are approved and escalations are decided. Each relevant vendor gets a formal performance review.
3. Quarterly, strategic. The committee reviews the full portfolio, reprioritizes, approves or cancels initiatives and decides on renewals and critical vendors. Benefits from closed projects are verified here too.

Each level needs a stable report format, minutes with decisions and a mechanism to escalate to the next. A common mistake is letting every meeting become a status review: if a meeting does not produce decisions, it is probably unnecessary or has the wrong attendees.

How to start in the first weeks

A reasonable sequence for launching a PMO and VMO as a service:

1. Inventory. List active projects and current contracts with their minimum data. It is common to find initiatives without a sponsor or contracts without an internal owner.
2. Criticality. Classify projects by value and risk, and vendors by the criticality of the service they provide. Not all of them need the same level of oversight.
3. Metrics and sources. Agree on the initial metric set, its definitions and where each data point comes from.
4. Cadence and roles. Set the meetings, their attendees and who decides at each level.
5. First dashboard. Publish a first version even if it is imperfect. Data improves when it is used.
6. Critical contract review. Compare the contracts of the most important vendors against the minimum elements above and plan adjustments for the next renewal.

The goal of the first months is not methodological perfection. It is for the committee to make better decisions with reliable, timely information.

This content is informational and does not constitute legal or contractual advice: validate contract templates and penalty clauses with your legal and compliance team.