Your systems implementer is accountable for their scope. Their statement of work says so, their engagement manager manages to it, and their PMO reports against it. Nobody on the org chart is accountable for your whole program unless you make somebody accountable.
The cost of that gap is measurable. McKinsey and the University of Oxford studied more than 5,400 IT projects and found large ones run 45% over budget and 7% over schedule while delivering 56% less value than predicted. Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals.
Read the second half of that McKinsey number again. The value shortfall is bigger than the cost overrun. Value is the owner's problem. No implementer's contract pays out on whether your close got faster or your people stopped working around the system.
This guide defines the client-side PMO: what it is, the five accountabilities it owns, and how to stand one up and run it. It is written for the sponsor, CIO, CFO, or CHRO about to commit to a major program, and for the program managers who will staff the office. ERP is the anchor case. The model applies to CRM and any other business-critical technology program.
You can contract out the work. You cannot contract out the accountability. If your accountable executive has no client-side machinery, they are accountable for something they cannot see.
1. Every large program has a seat nobody fills
A large program has an implementer who knows their software, a set of internal leads who know the business, and a sponsor who signed the business case. On paper that looks complete. In practice there is a set of activities nobody has been given: keeping one plan that covers both sides, chasing the decisions that are late, holding risks until they are actually closed, and telling the steering committee what is true.
The implementer will not 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 is your task on your side of the line. They will note the dependency, flag it, and keep moving. They are behaving correctly. The problem is that the note goes into their log, the slip stays on your side, and no single person is holding the arithmetic of what that slip does to your go-live.
The evidence points the same direction 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. However, 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 they define as governance, resistance to change, and process redesign, while fewer than a quarter of organizations reported an intense focus on change management.
None of those are software defects. They are management gaps, and management was never in the implementer's scope.
Before the contract is signed, name the person accountable for the whole program on your side and fund the role properly. If you cannot name them, you have found your first risk.
The seam nobody owned. On a recent global deployment, the client's own tasks lived in a spreadsheet and the implementer's tasks lived in the delivery plan. Both were maintained. Neither showed that three client decisions were sitting behind the same architecture workshop. The seam was visible only once both sets of activities were in one plan with one critical path.
2. What a client-side PMO is, and is not
The term PMO covers three different things, and conflating them causes real damage.
An enterprise PMO governs a portfolio. It sets standards, manages the pipeline, and reports across many initiatives. Useful, but it operates above the altitude of a single program.
The systems implementer's PMO, or SI PMO, runs the implementer's delivery method. It tracks their tasks, manages their consultants, produces their status, and protects their commercial position. It is competent and it is necessary. It is also scoped to their contract.
The client-side PMO runs your program. It owns the integrated plan covering both sides, drives the risks and issues to closure, keeps the workstream leads aligned, and reports to your leadership on your outcomes. It is the mechanism through which your accountable executive discharges their accountability.
That last point is settled, not a matter of taste. 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.
Governance is the mechanism by which the investing organization exerts financial and technical control over the deployment of the work.Association for Project Management, Body of Knowledge
The investing organization. Not the supplier delivering the work.
Write the client-side PMO into the program org chart and the budget before the implementer mobilizes, not after the first slipped milestone.
3. Five things somebody has to own end to end
Strip away the tooling and the templates and the role reduces to five things somebody must own end to end.
End-to-end delivery execution
Accountable for day-to-day delivery across all workstreams, ensuring milestones are met. Not monitoring the milestones. Meeting them.
Integrated plan ownership
Owning, managing, and updating one program plan for the duration, feeding the client's own activities into it and baselining it jointly with the implementer's engagement manager.
RAID ownership
Owning the risk, assumption, issue, and dependency log, and driving mitigation and escalation rather than maintaining a record.
Workstream coordination
Keeping functional, technical, change, data, and testing leads aligned, integrated, and delivering to plan.
Status reporting
Producing and delivering the weekly report to program leadership and holding a weekly check-in with every workstream lead.
Read as a list these look administrative. They are not. Each one is the point where a specific failure mode gets caught. No integrated plan means nobody sees the cascade. No driven RAID means risks age quietly. No workstream cadence means integration problems surface during testing. No honest status means the steering committee cannot act while acting is still cheap.
4. Two plans means you do not have a plan
If your activities and the implementer's activities live in different plans, you do not have a plan. You have two forecasts that have never been tested against each other.
The integrated plan is the single most useful artifact the client-side PMO owns, and the most commonly fudged. Nearly every program has something called an integrated plan. Fewer have one that contains client tasks at the same level of detail as implementer tasks, with 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 cannot compute anything useful.
It is baselined jointly. The client-side PMO and the implementer's engagement manager agree the baseline together. That conversation is uncomfortable and worth having, because it is where the assumptions each side has been carrying quietly get said out loud.
It is change controlled. A plan that gets quietly re-drawn every time something slips is a record of optimism. The UK National Audit Office lists the warning signs of an unrealistic schedule and puts persistent re-planning to meet the same deadline first, followed by removing scope, shortening test windows, and staging the go-live at the last minute. Every one of those is a plan bending around a date instead of a date bending around the plan.
The reason this matters more than it sounds is 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 that has no meaningful average. The only defense is seeing the chain before it fires, and you cannot see a chain that spans two plans.
3 weeks hiding in a summary bar. A plan showed client data readiness as a single bar. Broken into its real tasks, extract, cleanse, validate, reconcile, sign off, it ran 3 weeks past the conversion window it fed. The bar had been green throughout because the bar had no logic in it.
5. A risk log records. A RAID process manages.
A risk log is a record. A RAID process is a management system with owners, dates, and escalation triggers. Programs fail with tidy logs.
Every program has a RAID log. Most 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 is being worked.
The distinction between logging and driving is where the outcomes sit. A study of risk management maturity found the least mature attribute across organizations was risk analysis. Organizations 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 rather than stepping back to assess the totality of risk facing the program.
Their worked example is instructive because it looks like success. On a major UK defence program the team had tracked progress, monitored risks, and identified interdependencies. A radar subsystem still landed 18 months late, because the department did not oversee its contract with the supplier effectively and was not aware of the subcontractor's lack of progress until it was too late. The dependency was on the register. Being on the register does nothing.
What driving looks like in practice: a named human owner, not a workstream, who can be asked what happened this week. A mitigation with a date and a next action, where monitor is not a mitigation and the test is whether you can say what will be different by Friday. A pre-agreed escalation trigger, decided in advance so the judgment call is removed at the moment when everybody is most invested in not making it. Dependencies managed as commitments between named people, with both names and a date. And assumptions with expiry dates, because the A in RAID is the one everybody skips and planning assumptions quietly become facts.
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 is blunt about who catches this: 9 out of 10 projects have cost overrun, and estimates have not improved across the 70 years studied.
Give every open risk a named owner, a dated next action, and a pre-agreed escalation trigger. Review the trigger, not the sentence.
The risk that aged out. An integration risk sat amber for 11 weeks with the mitigation working with vendor. Nobody had set a date at which amber became red. When it went red it went red 4 days before a test cycle, and the options that had existed in week two were gone.
6. Integration problems are cheap in a workshop and expensive in test
Integration problems are cheap in a workshop and expensive in test. The weekly lead check-in is the mechanism that moves them earlier.
Workstream coordination sounds like scheduling. It is actually 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. A standing weekly check-in with each lead, individually. A weekly integration point where the leads are in the same room. A monthly or stage-gated readiness review with real criteria.
The individual check-in is the part people cut first and should cut last. In a group setting, a lead who is behind will describe the position carefully. One to one, with 15 minutes and no audience, the same person will tell you what is 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. Data to functional, where configuration decisions change what the data has to look like and data leads find out late. Functional to technical, where a configuration choice made to avoid a workaround creates an integration change nobody costed. Testing to everything, where test scenarios expose process assumptions that have been baked for months. Change to functional, where training built on a moving design teaches the wrong thing. And security to everything, chronically late because it depends on final design and gates testing.
15 minutes, 6 weeks early. A testing lead mentioned in a one to one that a downstream reconciliation had no owner. It was not on any log. Raised at the integration point, it became a 4-hour design conversation. Found during test it would have been a defect against a live interface with a fix window measured in days.
7. Status that tells the truth
Status reporting is the sensing mechanism your leadership uses to act while acting is still cheap, and it is systematically biased toward good news.
This is the accountability that looks softest and matters most, because everything else in this guide is worthless if what reaches the steering committee is wrong.
The bias is measured, not anecdotal. 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, including one worth sitting with: putting a senior executive in charge of a project may increase misreporting. And another: executives often ignore bad news when they receive it. There is a documented mum effect, reluctance to pass bad news up, and a documented deaf effect, refusal to act on it once passed.
The mechanics of a green report with red underneath are well catalogued. Selective highlighting, where accurate information is reported in a way that makes it hard to find. Reclassifying, where uncompleted work moves into a newly created phase two so the current phase can close. Redefining deliverables, where the release schedule holds and the functionality inside each release quietly shrinks. Working with the labels, where work is packaged just below the threshold that triggers oversight. None of that requires anyone to lie. Every individual statement stays true.
There is a second force underneath. HM Treasury instructs UK government appraisers to apply optimism bias uplifts to project estimates, and 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.
What a real weekly status contains: a RAG that is defined, not felt, written down before you need it. Movement, not position, because a milestone that has been 90% complete for 3 weeks is the single most useful signal in program reporting and a position-only report hides it completely. Between 30% and 40% of IS projects exhibit some degree of escalation, and the theory that best explained the pattern was the completion effect, proximity to a perceived finish line. Almost done is what keeps failing programs alive. The decisions you need, with dates. Named risks with named owners, not a count. And what changed in the plan and why, so re-planning cannot become invisible.
Then the cultural half, which the reporting format cannot fix. The research found that trust in supervisor had the strongest and most significant impact on a project manager's willingness to expose a challenged project, and that when trust is low, adding aggressive auditing may produce more misreporting, not less. You cannot audit your way to honest status. If the first red is met with a search for who is at fault, the second red arrives much later and much redder.
90% for 3 weeks. A workstream reported 90% complete 3 weeks running. The percentage was defensible each time. What was actually happening was that the last 10% depended on a decision nobody had asked for. A movement-based format would have caught it in week one.
8. The PMO earns its authority in the first 90 days
The client-side PMO earns its authority in the first 90 days, mostly by producing one plan and one honest status that people trust.
Days 1 to 30, establish the facts. Read the business case, the statement of work, and the delivery method. Find out what the implementer has actually committed to and what they have assumed you will do. Meet every workstream lead individually. Get the plan into one place even if the first version is ugly. Stand up the RAID log with real owners. Publish the first status even if it is thin, because the cadence starts on day one and cadence is the thing that becomes normal.
Days 31 to 60, establish control. Baseline the integrated plan jointly with the engagement manager. Agree change control for both plan and scope. Set the governance calendar: weekly leads, weekly integration, monthly steering. Define RAG criteria and escalation triggers in writing. Agree the decision log and how a decision gets made when the meeting does not produce one. Test the critical path by asking what has to be true for the next milestone.
Days 61 to 90, establish the drumbeat. Run the cadence until it is boring. Close the first cohort of risks so people see the log means something. Take the first real issue through escalation and back so the mechanism has been proven. Run a stage-gate readiness review with real criteria. Look ahead two stages and start the work that has a long lead time, usually security roles, environments, and data.
The staffing question comes up immediately. 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. The same research found PMOs delivered a 61% improvement in projects delivered on budget and 62% improvement in the number of successful projects, and that high-performing PMOs delivered on-budget improvement of 77% against 36% for low performers. Experience separates those two groups: high-performer PMO staff averaged 10 years of project management experience against 6.5 in low performers.
There is 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 did not include 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.
The first red. A PMO published amber in week three on a program everyone knew was fine. It was uncomfortable and it was correct. 2 months later, when a genuinely serious issue needed to go red, nobody argued about the color. The precedent had already been set.
9. A program PMO delivers a program. A capability outlives it.
A program PMO delivers a program. A capability outlives it. The difference is whether anything is left in the building at go-live.
Most client-side PMOs are stood up for one program and dissolved at hypercare. That is a choice, and often a defensible one. However, make it deliberately, because the alternative is worth real money.
The capability view has nine blocks: governance, documented authorities and a decision management method; PM best practices and tools, repeatable capability producing predictable outcomes; training integrated with HR, growing intellectual capital; reporting, analysis, and trending that assembles into a portfolio view; operations, a centralized and repeatable service set; HR competency management, anticipating resourcing needs before they bite; strategic sourcing, using PMO scale and partnerships; community of interest, developing project management as a discipline; and information and knowledge management, a sustainable framework for what the program learns. All nine sit inside a loop: communicate and measure, monitor, adjust, improve.
For completeness on a single program, the classic project management function map still works as a checklist. Integration, scope, time, cost, quality, human resources, communications, risk, and procurement, each with its planning, execution, and control processes. It is 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 are usually assumed to belong to somebody else.
Maturity is where the evidence gets thinner and honesty is worth more than confidence. 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, and noted openly that little evidence exists in the academic literature on the impact of maturity models on project performance. That is the honest state of it. Maturity models are useful as a structured conversation about what is missing. No published effect size backs them as a lever, and anybody who tells you otherwise is selling an assessment.
What does have evidence behind it is capability retention. The NAO, having assessed over 350 government commercial arrangements across two decades, sets the expectation that knowledge and experience of underlying contract issues is retained throughout the lifecycle of the relationship. Their case study is a nuclear decommissioning contract terminated 9 years early, where 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. They had to rebuild the client side before they could fix the supplier side.
10. The five accountabilities hold across every program type
The five accountabilities do not change across program types. The integration points and the failure modes do.
CRM programs fail on adoption more than on configuration. The system works and the sales team keeps its real pipeline somewhere else. The plan needs adoption measures as milestones with dates, not as a change management workstream running alongside. Data quality moves from a conversion problem to a permanent operating problem, because nobody trusts a CRM with 10% duplicate accounts, and a CRM that is not trusted is not used.
HCM and payroll programs carry a hard external calendar. Payroll parallel runs are pass or fail against reality, and the fiscal or tax year does not move. The plan is far less negotiable at the back end, which means slack has to be found early or not at all.
Finance transformation lives on the close calendar and on reconciliation. Reporting is the visible surface, and reporting requirements arrive late and multiply. Nailing the reporting inventory early is the single highest-value planning act.
Custom development and platform programs carry the interdependency risk in its purest form, where one component's problem cascades. Interfaces are the risk surface, and the client-side PMO's contribution is insisting that integration testing gets a real window rather than the gap between build and go-live.
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.
Somebody has to run yours
Your implementer will run their machine well. That is what you hired and, in most cases, that is what you will get. The question that decides your outcome is whether anybody is running yours.
The evidence converges from every direction. Accountability cannot be delegated or shared. Governance is the mechanism by which the investing organization exerts control. After reviewing hundreds of contracts, the UK's national auditor recommends departments strengthen their intelligent client function, and defines it as an in-house capability that can monitor, challenge, and verify what the supplier does, with the explicit warning that it requires adequate capacity to be resourced. Where that capability is thin, audit bodies find governance boards that do not meet, business cases never completed, and cost estimates missing the client's own costs.
Three questions to ask at your next steering committee. Does one person own an integrated plan that contains both sides at working detail? Who challenges the implementer's estimate, and are they resourced well enough to do it credibly? And when the status is green, do you know what would have to be true for it to be red?
If those answers are uncomfortable, that is useful information, and it is much cheaper now than at test.