The client-side PMO

A large program has an implementer who knows their software, internal leads who know the business, and a sponsor who signed the business case. On paper that looks complete. In practice a set of activities belongs to nobody: keeping one plan that covers both sides, chasing the decisions that are late, holding risks until they're actually closed, and telling the steering committee what's true.

The implementer won't do this work, and saying so is no criticism of them. Their engagement manager is measured on their firm's scope, margin and delivery method. When your data cleansing slips, that's your task on your side of the line. They'll note the dependency, flag it and keep moving, which is the correct behavior for them. The note goes into their log and the slip stays on your side. No single person is holding the arithmetic of what that slip does to your go-live.

The evidence points the same way from three independent angles. McKinsey attributes roughly 90% of cost overrun to four management dimensions: strategy and stakeholders, technology and content, team effectiveness, and core project-management practice. BCG studied 895 transformations and found only 30% met or exceeded their target value. Their conclusion was blunt: the technology matters, but the people dimension is usually what decides the outcome. Panorama's 2026 ERP survey found the most common cause of schedule overrun was organizational issues, which it defines as governance, resistance to change and process redesign. Fewer than a quarter of organizations reported an intense focus on change management. Every one of those causes is a management gap, and management was never in the implementer's scope.

The term PMO covers three different things, and mixing them up does real damage.

UK government guidance on the senior responsible owner states it flatly: there can only be one accountable person who can be held to account, and this accountability cannot be delegated or shared. The same guidance makes the SRO the owner of the business case and accountable for all aspects of governance, and notes they remain accountable after the program ends.

The investing organization is you. The supplier only delivers the work. The control belongs to you.

Strip away the tooling and the templates and the job comes down to five accountabilities. Read as a list they look administrative, but each one is the point where a specific failure mode gets caught.

The integrated plan is the most useful artifact the client-side PMO owns, and the one most often fudged. Nearly every program has something called an integrated plan. Fewer have one with client tasks at the same level of detail as implementer tasks, real dependencies between them, a genuine critical path and a baseline both parties signed.

Client activities go in at working detail. Data cleansing, policy decisions, security role sign-off, legal review, backfilling the people you seconded to the program, communications, training delivery, environment access. These are your tasks. If they appear as one summary bar called Client Readiness, the plan can't compute anything useful.

It's baselined jointly. The client-side PMO and the implementer's engagement manager agree the baseline together. It's an uncomfortable conversation and worth having, because that's where the assumptions each side has been carrying get said out loud.

It's change controlled. A plan that gets redrawn every time something slips is a record of optimism. The UK National Audit Office lists the warning signs of an unrealistic schedule. In each of them the plan bends to protect a date:

This matters more than it sounds because of interdependency. Research on 5,392 IT projects found cost overruns follow a power-law distribution with a fat tail, and proposed the mechanism: a problem in a single component triggers chain reactions through interdependent components. The authors put it starkly. The average cost overrun for IT projects does not exist and cannot be calculated. Your contingency is a guess against a distribution with no meaningful average. The only defense is seeing the chain before it fires, and you can't see a chain that spans two plans.

Every program has a RAID log. Most of them are parking lots. Items get raised, assigned to a workstream, given a mitigation sentence and then reviewed in a meeting where the update is that it's being worked.

The outcomes sit in the difference between logging and driving. A study of risk management maturity found the least mature attribute across organizations was risk analysis: they record risks and skip the thinking. The NAO makes the program-level version of the same point, criticizing organizations for focusing on individual project risks instead of stepping back to assess the totality of risk facing the program.

Its worked example is instructive because it looks like success. On a major UK defense program the team had tracked progress, monitored risks and identified interdependencies. A radar subsystem still landed 18 months late, because the department didn't oversee its contract with the supplier effectively and wasn't aware of the subcontractor's lack of progress until it was too late. The dependency had been on the register the whole time.

Escalation matters because delay compounds mechanically. Research on large projects found that each year of delay after the decision to build adds 4.64 percentage points to cost overrun. The same body of work found 9 out of 10 projects have cost overrun, and estimates haven't improved across the 70 years studied.

Workstream coordination sounds like scheduling. In practice it's the early warning system, and it works because problems between workstreams show up in conversation weeks before they show up in a deliverable.

The structure that works is unglamorous:

The individual check-in is the part people cut first and should cut last. In a group setting, a lead who's behind will describe the position carefully. One to one, with 15 minutes and no audience, the same person will tell you what's actually happening. None of this is a character flaw. Research on status reporting shows the effect is structural: the stronger the perceived power of the sponsor or project leader, the less inclined subordinates are to report accurately, and the greater the power distance between the reporter and the recipient, the greater the level of misreporting.

The integration points that matter recur on every program.

It's the accountability that looks softest and matters most, because everything else in the handbook is worthless if what reaches the steering committee is wrong.

The bias has been measured. Researchers reviewed the records of 56 experienced software project managers and found project managers write biased reports 60% of the time, with bias more than twice as likely to be optimistic as pessimistic. The same body of work names five uncomfortable findings. One is worth sitting with: putting a senior executive in charge of a project may increase misreporting. Another is that executives often ignore bad news when they receive it. There's a documented mum effect (reluctance to pass bad news up) and a documented deaf effect (refusal to act on it once it's passed).

None of that requires anyone to lie. Every individual statement stays true.

There's a second force underneath. HM Treasury instructs UK government appraisers to apply optimism bias uplifts to project estimates. For equipment and development projects, the category that covers ICT and software, the upper-bound uplift on capital expenditure is 200%. The guidance says to start with the upper bound and reduce it only where mitigation is demonstrably evidenced and independently verified. A government treasury tells its own people to assume the technology estimate could be wrong by a factor of three.

Then there's the cultural half, which no reporting format can fix. The research found that trust in the supervisor had the strongest and most significant effect on a project manager's willingness to expose a challenged project. When trust is low, adding aggressive auditing may produce more misreporting. If the first red is met with a search for who's at fault, the second red arrives much later and much redder.

The staffing question comes up immediately, and the benchmark is more forgiving than most people expect. PM Solutions found the median PMO operating cost sits at about 3% of the value of the portfolio it supports, roughly unchanged over a decade. Experience is what separates the high performers from the rest.

There's also a cost the client side routinely forgets to count. A US audit of a federal modernization program found the cost estimate considered work in the contractor's performance work statements but left out government and system operations costs, and concluded that a cost estimate missing cost elements will underestimate the total. The client costed the implementer's work and forgot to cost its own.

Most client-side PMOs are stood up for one program and dissolved at hypercare. That's a choice, and often a defensible one. Make it deliberately, though, because the alternative is worth real money. The capability view has nine blocks, and all nine sit inside one loop.

For a single program, the classic project management function map still works as a checklist. Each area has its planning, execution and control processes. It's a poor outline for an article and an excellent test for a PMO charter. Run down the list and ask who owns each one on your program. The gaps are usually procurement, quality and communications, and they're usually assumed to belong to somebody else.

Maturity is where the evidence gets thinner. Research on maturity models and delivery outcomes is limited, and the studies that exist are largely qualitative. One multiple case study of OPM3 found a positive contribution to project performance in scope, schedule, cost and stakeholder communication. It also noted openly that little evidence exists in the academic literature on the impact of maturity models on project performance. Maturity models are useful as a structured conversation about what's missing. No published effect size backs them as a lever, and anybody who tells you otherwise is selling an assessment.

Capability retention is what does have evidence behind it. The NAO, having assessed over 350 government commercial arrangements across two decades, expects knowledge and experience of underlying contract issues to be retained throughout the lifecycle of the relationship. Its case study is a nuclear decommissioning contract terminated 9 years early. The client commissioned a review specifically to improve its intelligent client capability, and strengthened its commercial and contract management team before changing the contracting arrangements. It had to rebuild the client side before it could fix the supplier side.

Two things stay constant across all of them. The implementer is scoped to their contract, and the value is realized on your side after they leave.