PMO functions are the core responsibilities a project management office owns on behalf of the organization: setting governance and standards, managing the portfolio, allocating resources, monitoring performance, handling risk across projects, developing capability, and reporting to leadership. The functions describe what the office does. The PMO process describes how those functions run as one repeatable operating cycle, from a project request coming in to a benefit being confirmed after delivery.
Plenty of offices publish a long list of functions and still fail, because a list of duties is not the same as a working process. This guide covers the core PMO functions one by one, then shows how a PMO actually operates: the end-to-end cycle it runs and the specific processes and procedures that keep it moving.
Key takeaways
- The core PMO functions cluster into governance, portfolio management, resource management, performance monitoring, risk, capability development, and reporting.
- Functions are what the office does; the PMO process is how it does them, as a repeatable intake to benefits cycle.
- Which functions dominate depends on the PMO's authority type. A supportive office emphasizes standards and training; a directive office runs delivery itself.
What are the functions of a PMO?
A PMO's functions are best understood as the handful of jobs no single project team can do for the whole organization. An individual project manager runs one project well. The PMO makes the collection of projects behave like a managed portfolio, and the functions below are how it does that. Most offices own some mix of these seven; few own all seven at full strength on day one. Together, these functions form the operating core of the wider PMO framework.
| Function | What the PMO owns | Why it needs a central office |
|---|---|---|
| Governance and standards | Decision rights, gates, escalation paths, templates, and the methodology projects follow | One consistent process across projects, auditable and comparable |
| Portfolio management | The intake pipeline, prioritization, and the funding of the right work | Only a central view can compare projects and steer investment |
| Resource management | Capacity planning and allocating people across competing projects | Resource conflicts happen between projects, not inside one |
| Performance monitoring | Tracking schedule, cost, scope, and outcomes across every initiative | Early issue detection needs consolidated, portfolio-level data |
| Risk management | Standardizing risk practice and surfacing systemic, cross-project exposure | Cumulative portfolio risk is invisible from any single project |
| Capability development | Training project managers, coaching, and raising delivery maturity | Consistent skills lift the floor on how all projects run |
| Reporting and stakeholder comms | One honest portfolio view for executives and stakeholders | Leaders need a single source of truth, not ten formats |
Swipe to see more →
Notice what is not on the list: personally running every project. A healthy PMO raises the standard of how projects are run across the business; it does not try to deliver them all itself. The exception is the directive office, covered below. Who actually carries out each function depends on how the office is staffed, which is the subject of PMO roles and responsibilities.
Governance and standards
This is the function most people picture first. The PMO defines the decision-making body, the stage gates a project passes through, the escalation paths, and the templates and standardized delivery methodology everyone uses. It then checks that projects actually follow them through reviews and health checks. Done well, governance is light and fast; done badly, it is the bureaucracy that gives PMOs a bad name. The decision rights and cadences that make it work are covered in project portfolio governance.
Portfolio management
Portfolio management is the function that makes the office strategic rather than administrative. It owns the pipeline of incoming project requests, the criteria that decide which get funded, and the ongoing balancing of the portfolio against capacity and strategy. This is where a PMO stops being a reporting layer and starts steering investment toward the highest-value work, using a repeatable way to prioritize the project portfolio.
Resource and performance management
These two functions are where most portfolios quietly break. Resource management means knowing who is already committed and allocating people across competing projects before saying yes to new work, which depends on real resource and capacity planning. Performance monitoring means consolidating schedule, cost, and scope data across every project so problems surface early. The output of both feeds the reporting function: a single portfolio view leadership can trust.
The PMO process from end to end
The functions above only create value when they run as a connected process rather than seven separate activities. A working PMO operates a repeatable cycle: work comes in, gets prioritized and approved, is governed through delivery, is reported on, and its benefits are confirmed after it ships. Each stage hands off to the next, and the cycle runs continuously as new requests arrive.
| Stage | What happens | Function in play |
|---|---|---|
| 1. Intake | New project requests are captured in one consistent way | Portfolio management |
| 2. Prioritize and approve | Requests are scored, ranked, and funded against capacity and strategy | Portfolio and resource management |
| 3. Govern delivery | Approved projects pass through gates and are reviewed against standards | Governance and risk |
| 4. Monitor and report | Progress, cost, and risk are tracked and rolled up for leadership | Performance monitoring and reporting |
| 5. Realize benefits | After delivery, expected value is measured and confirmed | Benefits realization |
Swipe to see more →
The cycle is why the intake stage matters so much: a request captured cleanly at the front feeds every stage that follows, which is why a defined project intake process is the foundation of the whole operating model. The final stage closes the loop by checking the work actually delivered the value it promised, which is the job of benefits realization management. A PMO that runs stages one through four but skips stage five never learns whether its portfolio decisions were right.
PMO processes and procedures
Underneath the operating cycle sit the specific processes and procedures the office writes down, owns, and trains people to use. These are the mechanics that make the cycle repeatable instead of ad hoc. The core set most PMOs maintain:
- Demand and intake management. How work requests flow into the PMO and get logged, so the business is never quietly overstretched by unmanaged demand.
- Project approval. The route a request takes to get funded or declined, with clear criteria for what proceeds past the starting line.
- Change control. The PMO is the guardian of change management: it defines how scope, cost, or schedule changes are raised, assessed, and approved. In practice that means owning the change control process, from the request form through to the thresholds that decide whether a project manager, a board, or the sponsor signs it off.
- Budgeting and financial control. Consolidating project budgets so the office can report the full cost of the work and answer finance's questions about where money is going.
- Performance and status reporting. The recurring measurement of projects against KPIs and the dashboards that give executives clear visibility. How that reporting should be shaped is covered in PMO reporting and portfolio dashboards.
Writing these procedures down is what separates a PMO that survives a reorganization from one that lives in a few people's heads. The office's founding document should record which processes it owns, which is one of the things a good PMO charter exists to capture.
How PMO functions shift by type and maturity
Not every PMO runs every function at the same strength, and the difference is deliberate. The office's authority type decides which functions dominate. A supportive PMO leans on standards, templates, and training with little enforcement. A controlling PMO adds real teeth to governance and compliance. A directive PMO runs delivery itself, so it owns project execution on top of the portfolio functions. Those three types are explained in the project management office overview.
Maturity changes the picture too. A new office typically starts with reporting and standards, because those show value fastest, and adds portfolio prioritization, resource management, and benefits realization as it earns credibility. Trying to run all seven functions from day one is a common way to overload a young office and lose the trust it needs. A PMO maturity model gives you a structured way to sequence which function to build next, and where the office sits in the org chart shapes what it can realistically own, which ties to PMO structure.
What does each PMO function actually produce?
Every PMO function should produce a named output, on a named cadence, for a named consumer. Governance produces gate decisions for sponsors. Portfolio management produces a ranked, funded project list for the executive team. Resource management produces a capacity forecast for delivery leads. A function with no output and no consumer is an intention, not a function.
The catalog below is the most useful thing a new office can publish, because it turns an abstract list of responsibilities into commitments other people can hold you to. It also exposes the functions nobody actually asked for.
| Function | What it produces | Cadence | Who consumes it |
|---|---|---|---|
| Governance and standards | Gate decisions, waivers, and the current method set | Per gate, plus a periodic standards review | Sponsors, project managers, audit |
| Portfolio management | A ranked and funded project list with the cutoff line | Quarterly, adjusted monthly | Executive team, finance |
| Intake and demand | A triaged request queue with a decision and a date on every item | Weekly | Requesters, portfolio board |
| Resource and capacity | A role level supply and demand forecast | Monthly, rolling | Delivery leads, resource managers, hiring |
| Performance monitoring | Exception based status with variance against plan | Every two weeks, or monthly | Sponsors, executive team |
| Cross project risk | An aggregated risk and dependency picture with named owners | Monthly | Portfolio board, sponsors |
| Benefits | Post handover benefit tracking against the business case | Quarterly, after go live | Finance, sponsors |
| Capability | Trained people, templates in active use, a competency baseline | Continuous, reviewed annually | Project managers, HR |
| Reporting | The portfolio dashboard and the decisions it triggered | Monthly | Executive team |
Swipe to see more →
Two tests keep the catalog honest. Name a real person as the consumer, not a committee. Then ask when that person last used the output to make a decision. If the answer is "never" or "I am not sure", you have found a function to fix or retire. The roles that carry each of these are a separate question, covered in PMO roles and responsibilities.
How much effort does each PMO function cost to run?
Effort varies far more by portfolio shape than by portfolio size, so treat the drivers below as a structure for your own measurement rather than as benchmarks to copy. What matters is knowing what each function scales with: reporting cost scales with the number of distinct audiences, governance cost scales with the number of gates held, and resource management cost scales with how much sharing happens across projects.
| Function | What actually drives the effort | What makes it spike |
|---|---|---|
| Governance and standards | Number of gates held, not number of projects | A methodology rewrite, or a gate every project fails |
| Portfolio management | Frequency of re-prioritization | An unplanned funding round or a reorganization |
| Intake and demand | Request volume, and how many arrive incomplete | A new intake form with no field validation |
| Resource and capacity | Degree of sharing across projects | Matrix reporting, or one scarce skill everyone needs |
| Performance monitoring | Number of projects, and how manual the data collection is | Chasing status by email instead of one source |
| Cross project risk | Number of dependencies, not number of risks | Interlocking delivery dates across a program |
| Benefits | How many benefits are still tracked after handover | Benefits defined without a measurable baseline |
| Reporting | Number of distinct report audiences | Every executive asking for a bespoke view |
Swipe to see more →
Measure this for one cycle before you argue for headcount. The case that wins funding is never that the office is busy. It is a measured statement: this function consumes the largest single share of our capacity, here is the driver behind it, and here is the work we would do instead if we fixed that driver.
Which activities belong to the PMO and which belong to the project manager?
The dividing line is the scope of the decision. A project manager owns everything inside one project: the plan, the team, the risks, the delivery. The PMO owns everything that only makes sense across projects: comparing them, sequencing them, resolving contention between them, and reporting the set as a portfolio. Work that crosses that line without agreement is where most PMO friction starts.
| Activity | The PMO owns | The project manager owns | Where it goes wrong |
|---|---|---|---|
| Planning | The template, the required fields, the quality bar | The plan itself and its accuracy | The PMO rewrites plans and becomes accountable for delivery it does not run |
| Risk | Aggregation, cross project themes, the escalation route | Identifying, owning and mitigating project risks | The PMO maintains the register, so the project stops reading it |
| Status | The format, the cadence, the consolidation | The content and its honesty | The PMO edits status into something safe and leadership stops believing it |
| Resourcing | Capacity across projects and the contention rules | Requesting and using the people assigned | The PMO assigns individuals without the delivery context to do it well |
| Prioritization | The model, the scoring session, the published ranking | The inputs for their own project | Each project argues its own score and the model turns into negotiation |
| Change | The threshold above which a change needs a portfolio decision | Change inside tolerance | Every change routes upward and the board becomes a queue |
| Benefits | Tracking after handover, once the project team has gone | Defining measurable benefits in the business case | Nobody owns benefits and the business case is never revisited |
Swipe to see more →
Publish this split and get both sides to sign it. Most arguments about a PMO being bureaucratic are really arguments about an unstated line, and they tend to end quickly once the line is written down.
How can you tell a PMO function has quietly died?
A dead function still consumes effort but no longer changes any decision. The signal is never a complaint, because nobody complains about a report they stopped reading. Look instead for outputs produced on time, every time, and referenced by nobody. Auditing this once a year usually recovers more capacity than any tooling change.
| Function | The signal it has died | What to do about it |
|---|---|---|
| Reporting | A dashboard nobody opens between meetings, while the same questions still arrive by email | Ask each audience which decision the report supports, and delete the views with no answer |
| Governance | Gates that have never produced anything except a go decision | Tighten the criteria or cut the gate count. A gate that cannot say no is a status meeting |
| Standards | Templates filled in after the work is finished | Cut the template down to the fields something downstream actually consumes |
| Risk | A register that grows and never closes anything | Age the entries and force a close or escalate decision on the oldest |
| Benefits | Tracking that stops at go live | Move benefit ownership to the receiving business owner before handover, in writing |
| Capability | Training attendance with no observable change in practice | Measure the practice, not the attendance |
Swipe to see more →
Retire deliberately, and say so out loud. A function that is quietly abandoned leaves the impression the office is unreliable. A function that is formally retired, with the reason published, buys credibility for the ones you keep. Reporting is the usual first candidate, and PMO reporting and portfolio dashboards covers how to cut a reporting set back to what gets read. Benefits is usually the last, because it is the only function that proves the portfolio worked at all, which is why benefits realization management outlives the projects that created it.
Frequently asked questions
How many functions should a PMO take on?
The core functions of a PMO are governance and standards, portfolio management, resource management, performance monitoring, risk management, capability development, and reporting. Together they let the office run the collection of projects as a managed portfolio rather than a set of unconnected efforts. Which functions an office runs at full strength depends on its authority type and maturity; few PMOs own all seven from the start.
What are the five main functions of a PMO?
If you reduce a PMO to five core functions, they are governance and standards, portfolio and resource management, performance monitoring, risk management, and reporting. Governance sets the rules projects follow, portfolio and resource management decide which work gets funded and staffed, performance monitoring tracks delivery, risk management surfaces cross-project exposure, and reporting gives leadership one honest view of the whole portfolio.
What is the PMO process?
The PMO process is the repeatable operating cycle the office runs: intake, prioritize and approve, govern delivery, monitor and report, then realize benefits. Work enters through a consistent intake, gets scored and funded against capacity and strategy, is governed through gates during delivery, is tracked and reported to leadership, and finally has its benefits confirmed after it ships. The cycle runs continuously as new requests arrive.
What are PMO processes and procedures?
PMO processes and procedures are the documented mechanics that make the operating cycle repeatable: demand and intake management, project approval, change control, budgeting and financial control, and performance and status reporting. The PMO writes these down, owns them, and trains project teams to use them. Documenting the procedures is what lets a PMO outlast a reorganization instead of living in a few individuals' heads.
What is the difference between PMO functions and PMO roles?
PMO functions are the jobs the office does, such as governance, portfolio management, and reporting. PMO roles are the people who do them, such as a PMO director, manager, analyst, or coordinator. Functions describe responsibilities; roles describe who holds each responsibility. A small office may cover several functions with one or two roles, while a large office assigns dedicated roles to each function.
What does a PMO do day to day?
Day to day, a PMO logs and triages incoming project requests, runs portfolio and governance reviews, updates resource and capacity plans, chases and consolidates project status, flags risks and issues that cross projects, maintains the reporting dashboards leadership relies on, and supports project managers with templates and coaching. The exact mix depends on the office's type: a supportive PMO spends more time on standards and training, a directive one on running delivery.