We’re working with a number of organisations at the moment to support the set-up of a Project Management Office (PMO). As most people acknowledge, no two PMOs are the same. While there are common themes across frameworks, methodologies and service areas, what works in practice depends on the organisation’s context, maturity and priorities.
Practical pointers for setting up a PMO
Given the range of what organisations expect from a PMO, we thought it would be useful to capture a few practical pointers that apply regardless of the type of PMO you’re setting up. These are also helpful if you want to take stock of an existing PMO or run a reset. They are intended as universal principles to help you establish and maintain a value-adding PMO
1. Start with the why
Before you talk structure, talk purpose. What problem is the PMO there to solve? Too many priorities? Patchy delivery? No visibility? Poor benefits realisation?
If you cannot clearly articulate the ‘why’ in two sentences, you will struggle to make good decisions about services, governance and resourcing.
A useful framing is:
- What outcomes must improve in the next 3 to 6 months?
- What outcomes must improve over 12 to 18 months?
- What will leaders notice is different when it is working?
2. Be explicit about who the PMO serves and what ‘value’ means
A PMO serves someone. Sometimes it is the executive and board. Sometimes it is delivery teams. Often it is both, but in different ways. Spell it out, because ‘value’ is different depending on the customer:
- Executives want clarity, prioritisation, trade-offs, confidence in delivery, assurance
- Delivery teams want practical standards, fit for purpose governance, coaching, templates, tools that save time
- The organisation wants capability uplift and more consistent delivery outcomes
If you do not name the customer, the PMO becomes a catch-all and may be judged on conflicting expectations. The old saying ‘you can’t please all of the people all of the time’ is true, but you can try if you know who they are and what they want.
3. Define a small number of services you can deliver well
Most PMOs fail by trying to do everything at once. Start with a minimum viable service catalogue and build maturity in phases.
A practical starting point is typically:
- Project fundamentals and data quality (clear scope, schedule, baseline, RAID, benefits intent, consistent status definitions)
- Delivery rhythm and governance (lightweight stage gates, a predictable cadence, escalation pathways that work)
- Support and coaching (help project leads lift capability, remove friction, and apply standards consistently)
Once those building blocks are in place you can scale into true portfolio services with confidence:
- Portfolio visibility and prioritisation (consolidated view you can trust, dependencies, capacity, trade-offs)
- Benefits and value management (tracking outcomes, not just milestones)
- Resource and financial management (capacity planning, cost to complete, investment reporting)
- Assurance and commercial support (targeted health checks, governance maturity, supplier performance)
Build credibility before expanding services. When project-level information is clean and consistent, portfolio reporting start to enabling real strategic insights which can then inform decision making at the highest level.
This won’t happen overnight. Manage expectations about maturity.
4. Put governance in plain English and make it easy to follow
Governance should reduce friction, not create it. If it feels like a compliance trap, people will work around it.
Keep it practical:
- Clarify decision rights: who decides, what they decide, when they decide
- Minimise meetings. Set a small number of consistent forums with clear inputs and outputs
- Standardise the minimum artefacts needed to make decisions
- Make escalation pathways obvious and fast
Good governance is not more meetings. It is fewer meetings, with fewer participants and better, faster decisions.
5. Design reporting that supports decisions, not just status updates
A good report does not just record activity. It tells you what has changed, what it means and what you need to do about it.
It should make it clear:
- What has changed since the last report, with the impact on time, cost, scope, benefits, value and risk
- What decisions are required, who owns them and the latest date they can be made without affecting delivery
- What the priority risks are, what is being done and what support or escalation is needed
- Where the portfolio is stretched: capacity pinch points, competing priorities and the trade-offs on the table
Done well, status reporting becomes the backbone of your governance rhythm, keeping decisions moving and conversations focused.
6. Agree measures of success up front and revisit them regularly
PMOs get challenged when success is vague. Define success in terms leaders care about and be realistic about maturity stages.
Early measures might include:
- Visibility and data quality improving month-on-month
- Improved predictability of project outcomes
- Faster decision turnaround
- Improved transparency of benefits and value
Later measures might include:
- Increased benefits and value realisation
- Improved portfolio throughput and value delivery
- Capability uplift across the delivery team
Importantly, these measures should not be static. Ideally they should be reviewed quarterly. A PMO should evolve with the organisation.
7. Set the PMO up as a capability builder, not just compliance
If the PMO only checks artefacts, it becomes known as a ‘policing’ function, becomes resented and often bypassed. If it builds capability, typically its more likely to become valued.
Capability-building behaviours include:
- Coaching sponsors and project leads
- Facilitating planning and prioritisation sessions
- Running practical training that solves real delivery problems
- Creating reusable assets that make delivery easier
Over time, this uplift of personal capability transfers into organisational maturity uplift.
8. Tools: choose a toolset that supports the operating rhythm, not a shiny platform
The technology matters, but it should not be the starting point (unless you have no choice, sometimes a tool is the mandated starting point). Tools should ideally reinforce the PMO’s service model and governance rhythm.
A pragmatic approach would be to define:
- What decisions need to happen regularly (and what data those decisions require)
- What the ‘source of truth’ is for portfolio, schedule, risks, issues, benefits, finance
- How information moves from teams to leadership without double-handling
- Who needs to input the information, who needs to view the information, who is the owner of the information
Then select or configure tools to match.
You typically need four layers:
- Work management (delivery execution)
Where teams plan work and track progress. Key requirement: it must be used consistently, not just by a few teams. - Portfolio view (PMO oversight and prioritisation)
Where you see the portfolio in one place: status, spend, capacity, dependencies, risks, decisions.
Sometimes this is a dedicated portfolio tool, sometimes it is a well-designed Power BI view over work management and finance systems. - Document and artefact management
A consistent place for business cases, charters, plans, RAID logs, stage gate packs. SharePoint and Teams usually do this well if designed properly. - Reporting and dashboards
May come from a dedicated PPM tool, could be from a dedicated Business Intelligence (BI) layer or could be pulled together manually from different systems.
Implementation principles that should keep you out of trouble
- If using multiple systems, ensure one source of truth per data type (one place for status, one for financials, one for risks etc)
- Minimum viable data (capture only what you will actually use to make decisions)
- Standard definitions (what “on track” means, what a “risk rating” means, what counts as “baseline”)
- Automation where possible (reduce manual reporting, reduce reliance on slide-decks)
- Usability beats feature depth (the best tool is the one people actually use)
Before buying anything new:
Ask:
- What will this tool replace?
- What manual work will it remove?
- Who will maintain the data quality?
- What decisions will improve because of it?
- Can we get 80 percent of the value with better configuration of what we already have?
Ultimately, a good PMO is not defined by how comprehensive its framework is or how complex its tools are. It is defined by whether it improves decisions, increases confidence in delivery and lifts capability across the organisation. Start small, be clear on purpose, and build maturity in deliberate phases. If you get the fundamentals right the PMO can evolve over time without losing trust or momentumTop of Form
