Most software companies do not decide to build a PMO. They drift into needing one. Somewhere between 30 and 100 people, the founder can no longer hold every project in their head, two client deadlines collide, and the leadership meeting becomes a debate about whose spreadsheet is right.
The usual reaction is either to do nothing ("we're Agile, we don't need project managers") or to hire someone who installs a heavyweight framework built for a bank. Neither works. This guide shows how to set up a lightweight, Agile-friendly PMO in about 90 days: what it should do, what it should not do, and how to tell whether it is earning its keep.
Signs you need a PMO
A PMO (project, programme or portfolio management office) is simply the small function that makes delivery visible, predictable and governed across teams. You need one when the cost of not having it starts to show. In our experience, these are the warning signs:
- Nobody can answer "what are we working on?" in one place. Work lives across Jira boards, client emails, Slack threads and someone's private spreadsheet.
- Priorities change weekly and nobody knows who decided. Sales commits a feature, a team lead pulls in a refactor, and the CEO hears about the conflict from a client.
- Status reports are written, not generated. Project managers spend Friday afternoons rewriting the same update for three audiences, and the reports are green until the week they go red.
- Scope changes are agreed in conversation. Client work grows without a change request, so margin quietly disappears.
- The same risks surprise you twice. A key engineer leaves, a third-party API changes, a client sign-off stalls, and there is no record that anyone saw it coming.
- Releases slip and nobody can say why. If this one sounds familiar, our article on why software releases slip goes deeper on root causes.
If three or more of these apply, a PMO is likely to pay for itself. If only one applies, fix that one problem directly and revisit in six months.
PMO types, explained plainly
The textbooks describe three PMO types. The labels sound bureaucratic, but the idea is simple: how much control does the PMO have over how teams work?
Supportive PMO
A service function. It provides templates, tools, training and reporting, and helps project leads when asked. Teams keep full control over how they deliver. Low control, low friction.
Controlling PMO
Sets a small number of standards that every project must follow: a common intake process, a RAID log, a status format, a change-control rule. It checks compliance but does not run the work. Medium control.
Directive PMO
Owns delivery directly. Project managers report into the PMO, which assigns them to projects and is accountable for outcomes. High control, and usually only justified at larger scale or in regulated environments.
| PMO type | Control level | When it fits | Watch out for |
|---|---|---|---|
| Supportive | Low | 30 to 80 people, a few teams, strong team leads, mostly product work | Becoming optional and ignored |
| Controlling | Medium | 80 to 500 people, several teams, a mix of product and client projects, shared dependencies | Standards growing faster than value |
| Directive | High | Large programmes, regulated delivery, or a turnaround where delivery has failed badly | Undermining team ownership and Agile ways of working |
For most firms of 30 to 500 people, the right answer is a supportive PMO with a few controlling rules. Be supportive by default, and controlling only on the handful of things that genuinely need consistency: how work enters the system, how scope changes are approved, and how risk and status are reported. Leave sprint mechanics, estimation and team rituals to the teams and their Scrum Masters or delivery leads.
The minimum PMO toolkit
A lightweight PMO needs six things. Resist adding a seventh until these are used every week.
1. RACI for decisions that matter
Do not build a RACI for every task. Build one for the ten or so decisions that cause friction: who approves a new project, who can change priority, who signs off a release, who approves scope changes on client work, who owns hiring for a team. One page, reviewed by the leadership team, published where everyone can see it.
2. RAID log
Risks, assumptions, issues and dependencies, one log per project or programme, plus a short portfolio view of the top items. Each entry needs an owner, a date and a next action. A RAID log without owners is a worry list. Review it in the weekly delivery meeting, not once a quarter.
3. Intake and prioritisation
A single front door for new work. Every request above an agreed size (for example, more than two weeks of team effort) goes through a short intake form: problem, expected value, rough size, sponsor, deadline and why. A monthly or fortnightly prioritisation forum ranks it against existing work. If you use OKRs, tie each item to an objective so trade-offs are explicit.
4. SOW and change control
For client or contract work, a standard statement of work template with clear scope, assumptions, acceptance criteria and exclusions. Pair it with a one-page change request: what changed, impact on time, cost and quality, and who approved it. The rule is simple: no change to agreed scope without a recorded decision. This is the single biggest protector of margin in services firms.
5. Status reporting from live data
Status should come from the tools teams already use, not from someone retyping it. Pull progress, throughput and blocked items directly from your work tracker into a dashboard, and ask project leads to add only what data cannot show: a RAG judgement, the top risk and the decision they need. If a status report takes longer than fifteen minutes to produce, the process is wrong.
6. A handful of delivery KPIs
Pick five or six measures and stick with them. A sensible starting set:
- Delivery predictability: planned versus delivered scope per sprint or release.
- Cycle time: how long work takes from start to done.
- Deployment frequency and lead time for changes, two of DORA's four key metrics.
- Change failure rate, to keep speed honest.
- Scope change volume on client projects, with approved versus unapproved changes.
- Portfolio health: the share of active projects that are green, amber and red, with trend.
Use these to start conversations, not to rank teams. The moment a metric becomes a target for individual performance, people will game it.
If you want a quick way to see where your current setup stands before you start, use our free Agile & AI Delivery Health Check. It takes a few minutes and highlights the gaps a PMO should close first.
A 30/60/90 day plan to set up a PMO
Ninety days is enough to get a lightweight PMO running and proving value. Longer than that, and the effort tends to become a documentation project.
Days 1 to 30: understand and agree
- Week 1: confirm an executive sponsor (usually the CEO, CTO or COO) and agree the PMO's purpose in two or three sentences. Write down what it will not do.
- Week 2: inventory all active work. List every project, owner, team, deadline and client commitment. This alone often surprises leadership.
- Week 3: interview team leads, product owners and account managers. Ask where delivery hurts, which decisions are unclear and what reporting they waste time on.
- Week 4: agree the PMO type, the operating rhythm (weekly delivery review, fortnightly or monthly prioritisation forum) and the first draft of the decision RACI.
Days 31 to 60: build the minimum toolkit
- Launch the intake form and run the first prioritisation forum using the inventory from month one.
- Set up RAID logs for the top projects and run the first weekly review using them.
- Roll out the SOW and change request templates on the next new client engagement, not retrospectively on everything.
- Connect your work tracker to a simple dashboard and agree the KPI definitions. Baseline the numbers now, even if they look bad.
- Pilot with two or three teams before asking everyone to adopt.
Days 61 to 90: embed and prove value
- Extend the toolkit to all teams, adjusting based on pilot feedback.
- Retire old reports and spreadsheets that the dashboard replaces. If you do not remove anything, you have added overhead.
- Run a retrospective on the PMO itself with team leads and the sponsor: what helps, what gets in the way, what to drop.
- Present a short 90-day review to leadership: what is now visible that was not, decisions made faster, and the baseline KPIs with early trends.
Our PMO setup service follows this shape. The PMO-in-a-Box package delivers the operating model, RACI, RAID, SOW and change-control templates and delivery KPIs in three weeks, so your team can spend the rest of the 90 days embedding rather than designing.
Common mistakes to avoid
Turning the PMO into a reporting bureaucracy
The fastest way to kill a PMO is to make it a machine for collecting status. If teams experience the PMO as people who ask for updates, they will treat it as a tax. Every request the PMO makes should give something back: a decision, an unblocked dependency, a clearer priority.
Templates nobody uses
A 40-page methodology on the intranet is not a PMO. Templates should be short, live inside tools teams already use, and be tested on real projects before rollout. If a template has not been used in a month, either fix it or delete it.
No executive sponsor
A PMO without a senior sponsor has responsibility but no authority. When the prioritisation forum ranks a project below the line and a director ignores it, someone with authority has to back the process. Without that, the PMO becomes an advisory body that teams politely route around.
Fighting Agile instead of supporting it
A PMO that demands Gantt charts from Scrum teams, or insists on fixed long-range plans, creates two parallel systems and friction between them. The PMO should consume the data Agile teams already produce: backlogs, sprint goals, release plans. If your teams are still finding their Agile footing, pair the PMO work with Agile coaching and Scrum training so both move in the same direction.
Starting with tooling
Buying a portfolio management tool before agreeing how intake, prioritisation and change control work simply automates confusion. Agree the process on paper first, then choose tools that fit it.
How to measure whether the PMO is working
A PMO should be judged on delivery outcomes, not on how many templates it has produced. After 90 days, and then quarterly, ask:
- Is delivery more predictable? Compare planned versus delivered scope against the baseline from month two.
- Are decisions faster? Track how long it takes for a new request to get a yes, no or not now. If it used to take weeks of corridor debate and now takes one forum cycle, that is real value.
- Are there fewer surprises? Count issues that were never on a RAID log as a risk first. This number should fall.
- Is scope change under control? On client work, check what share of changes went through a recorded change request.
- Is reporting cheaper? Ask project leads how long status reporting takes now compared with before.
- Do teams find it useful? Run a short, anonymous survey of team leads each quarter. Ask one question above all: would you keep the PMO if it were optional?
If the answers are mostly no after two quarters, do not add more process. Go back to the purpose statement, cut what is not helping and double down on what is. An independent software delivery assessment can help here by looking at your delivery data objectively and pinpointing where the PMO should focus next.
It is also worth asking where AI can reduce PMO overhead. Drafting status summaries from tracker data, flagging stale RAID items and spotting slipping work early are all reasonable candidates. Our guide to AI in software delivery covers how to test these ideas without creating new risk.
Next steps
A good PMO in a growing software company is small, useful and mostly invisible. It gives leadership one view of the work, gives teams clearer priorities and fewer interruptions, and protects margin on client projects. Start with a sponsor and an inventory, build the six-part toolkit, pilot it, and remove something old for every new thing you add.
If you would like help designing a PMO that fits your size and your Agile ways of working, book a free discovery call. There is no obligation, and you will come away with a clearer view of where to start.
Frequently asked questions
How many people do you need to run a PMO in a small software company?
In a company of 30 to 150 people, a PMO is often one experienced delivery or programme manager, supported by project leads who spend part of their time on PMO duties. As the number of teams and client projects grows, you might add an analyst to manage reporting and the RAID log. Start small, prove value, and add people only when the workload clearly justifies it.
Does a PMO conflict with Agile and Scrum?
It does not have to. A lightweight PMO focuses on the edges of delivery: how work enters, how priorities are set, how scope changes are approved and how risk and status are reported. It leaves sprint planning, estimation and team rituals to the teams. Conflict usually appears when a PMO demands traditional plans and reports that duplicate what Agile teams already produce.
What is the difference between a PMO and a project manager?
A project manager is responsible for delivering a specific project. A PMO looks across all projects, setting shared standards for intake, prioritisation, change control and reporting, and giving leadership one view of the portfolio. In smaller firms the same person may do both, but the roles are different: one delivers a project, the other makes delivery consistent and visible across the organisation.
How long does it take to set up a PMO?
A lightweight PMO can be designed and running in about 90 days. The first month is spent agreeing purpose, a sponsor and an inventory of work, the second building the minimum toolkit and piloting it with a few teams, and the third rolling it out and reviewing results. A packaged approach can compress the design work into a few weeks, leaving more time for embedding.