PMO Support for System Development: Role, Scope and How to Choose an External PMO

What a PMO is, and how it differs from a PM

A PMO (project management office) is the organisation or function that sets up the management system a project runs on (standards, plans, monitoring of progress, risk and quality, and reporting) and supports the decisions of the project manager (PM) and the client. The PM leads one project and is accountable for its objectives; the PMO looks across the project, gathers the facts, spots problems early and makes sure the right people hear about them.

The standard reference is the PMBOK Guide from PMI (Project Management Institute). The eighth edition includes The Standard for Project Management (ANSI/PMI 99-001-2025) and is built on six principles and seven performance domains (governance, scope, schedule, finance, stakeholders, resources and risk) containing 40 processes. Its published table of contents devotes Appendix X2 to PMOs, covering the PMO value proposition, PMO types, models and structures, and maturity models.

Five types of PMO

PMI's research report PMO Frameworks (November 2013) groups the PMOs found in practice into five types.

• Organisational unit PMO: gives a business unit or department portfolio management, governance and project support
• Project-specific PMO: a temporary office for one project or programme, handling data management, governance and reporting coordination, and administration
• Project support PMO: uses the organisation's processes and tools to support project work across it on an ongoing basis
• Enterprise PMO: the highest-level PMO, responsible for strategic alignment, enterprise governance and portfolio management
• Centre of excellence (CoE): supplies methodologies, standards and tools to raise delivery capability

When an external PMO is needed

An external PMO helps when the client does not have enough management capacity for the size, difficulty or number of parties in a project, or when it needs an independent view. Typical situations are:

• Replacing or integrating core systems such as core banking, where an outage has a large impact and specialist knowledge is needed
• Multi-vendor delivery, where the client must keep separately built parts and their schedules aligned
• Fixed deadlines, such as a regulatory deadline or the effective date of a rule change
• Rebuilding a long-running system whose specification is no longer known to anyone or documented
• Delivery across an offshore centre, with different languages, time zones and organisations
• An in-flight project that is slipping or showing quality problems and needs an objective assessment

For multi-vendor delivery, IPA's Model Transaction and Contract for Information Systems (second edition) makes the client responsible, when it splits development across vendors, for functional consistency between their software, schedule coordination, and progress management between the vendors (Article 13). Where the client lacks the capacity to control several vendors, it suggests outsourcing the overall management and coordination work to reduce the risk.

On rebuilds, IPA points out that in long-running systems the business knowledge (documents and experienced staff) has often been lost, so the current system must be investigated before requirements definition, and that many projects which skipped this ran into trouble later in development.

What PMO support covers

PMO support falls into seven areas: planning and scope, schedule, risks and issues, quality, budget, reporting and meetings, and reviews. Decide at the start which of these the external PMO will run and which decisions stay with the client.

IPA's model contract is a useful reference when designing these meetings. The second edition provides that the client and the vendor hold a liaison council at regular intervals to discuss progress, risk management and reporting, and problems and their resolution, with the vendor submitting a progress report and preparing the minutes (Article 12). The PMO helps run these meetings, standardises the reporting and follows each decision through until it is carried out.

PMOs in financial-sector system replacements: lessons from the FSA

In system integration and replacement at financial institutions, a PMO should watch subcontractor management, impact analysis of reused specifications, reviews by knowledgeable staff, agreed test plans, and migration and release decisions, because these are among the causes in the outage cases the FSA has published.

According to the FSA's Analysis Report on IT Resilience in the Financial Sector (June 2025), financial institutions reported about 1,800 system outages in fiscal 2024 (April 2024 to March 2025), and software failures together with management and human factors accounted for about 70% of them.

The report calls system integration and replacement at financial institutions difficult to execute, because an outage has a large impact and the knowledge required is highly specialised. The issues it names are project management that covers subcontractors, development documents such as system specifications, and reviews with knowledgeable reviewers properly assigned. In fiscal 2024, ATM specifications reused from another project in a core banking replacement were not well understood or fully analysed, and some ATMs failed to start.

The report's appendix of cases lists 18 outages that occurred with system integration or replacement. The table below takes some of their causes and countermeasures and turns them into items a PMO can check.

In the same appendix, one case at a funds clearing organisation lists "stronger checks from an external perspective" among its countermeasures, together with strengthening the secretariat by appointing a CIO.

Schedule, quality and cost metrics: JUAS software metrics

To test whether a plan or estimate is realistic, a PMO should compare it with industry statistics as well as the organisation's own history. The guidebook to the Software Metrics Survey 2025 (April 2025) from the Japan Users Association of Information Systems (JUAS) sets out the main quality, cost and schedule metrics from user companies' responses.

The data also show management practice in the results. Projects that finished within the standard duration found an average of 20.92 defects in user testing, about half the 39.55 found by projects that overran, and JUAS reads its data as showing that projects which manage duration phase by phase tend to stay within the standard. Of projects that put the deadline first, 74.5% finished on time, against 61.6% of those that put something else first.

On quality, projects that set a quality target had a weighted defect rate of 0.2, against 0.23 for those that did not, and projects with major requirement changes averaged 0.481, more than twice the 0.192 of projects with no changes. A numeric quality target and change control for every specification change are among the first things a PMO should put in place.

PMOs for delivery that includes offshore teams

When delivery includes an offshore team, the PMO gives the client, the domestic vendor and the overseas centre one channel for specifications, one view of progress and quality, and one change-control process. The more distance, languages, time zones and contract layers there are, the longer a problem takes to reach the client. The main tasks are:

• Fix specifications and acceptance criteria in writing, and keep all questions and answers in one log
• Measure progress by completed deliverables and test results, not by hours worked
• Set meeting times around the time difference, and write down escalation paths and deadlines
• Make sure the client can see the organisation chart including subcontractors, staff skills and review arrangements
• Check that information security requirements, covering test environments, test data and access from the offshore centre, are met in both the contract and day-to-day operation

On the contract side, IPA's second-edition model contract offers two options for subcontracting: one requiring the client's prior consent, and one leaving the choice of subcontractor to the vendor in principle while letting the client demand a stop (Article 7). If the offshore centre is a subcontractor, the PMO confirms which option applies and builds the consent and reporting steps into the project routine.

Contract types: contract for work, quasi-mandate, and where the PMO fits

An external PMO contract covers the performance of professional services, not the completion of a deliverable, so a quasi-mandate contract (jun-inin) is the norm. IPA's second-edition model contract also states that when a client in a multi-vendor setup outsources its overall management and coordination work, that contract should be a quasi-mandate.

As IPA explains, under a contract for work (ukeoi) the vendor must complete the work, while under a quasi-mandate the vendor owes the duty of care of a prudent manager but not a duty to complete the work. The model contract uses the following contract types by phase as its baseline.

The model contract is multi-stage: each phase has its own individual contract and fee, so the next phase can be re-estimated in the light of the previous one. The commentary also notes the concern that a contract for work can lead the client to hand everything to the vendor. The PMO checks that contract types and responsibilities match the actual team and work.

In preparing the second edition, IPA discussed how court cases often turn on the vendor's project management duty and the client's duty to cooperate. It chose not to add these duties as clauses, and instead set out that client and vendor both have to manage the project, each understanding its own role in every phase. An external PMO does not remove the client's own project management responsibility.

For agile development, IPA published an agile edition of the model contract in March 2020. It adopts Scrum and assumes a quasi-mandate, paying for the work performed rather than a finished deliverable. The client appoints the product owner and the vendor the Scrum Master, and the pre-contract checklist asks, among other things, whether one team of up to about 10 people can build the product and whether completion and quality criteria are clear.

How to choose an external PMO: eight checks

Choose an external PMO on its experience with comparable projects, its independence on the client's side, the concreteness of its reporting, and the clarity of its staffing and contract. Certifications show knowledge, but what decides it is hands-on experience with similar projects and a habit of reporting bad news early and accurately.

1. Comparable experience: same industry (such as financial services), same kind of system (such as core system replacement or migration), similar scale and delivery approach
2. Independence: if the PMO comes from a delivery vendor, how are conflicts of interest avoided? (IPA's model contract envisages the coordination work going either to a separate firm or to one of the vendors.)
3. Concrete reporting: does a sample status report describe delays and risks with facts and numbers?
4. Metrics: can they justify plans and estimates with your history and industry statistics such as JUAS?
5. Staffing: clear roles and time commitments, managed handovers, and experience with offshore teams and subcontractors
6. Contract: quasi-mandate or deliverable-based, with clear scope, reporting, meetings and limits of responsibility
7. Information security: rules for confidential information and access control, and a certification such as ISO/IEC 27001
8. Certifications: project management certifications such as PMI's PMP (the PMI Japan Chapter provides information on certifications and exams)

If the scope is hard to pin down, start with an assessment of the in-flight project and use the result to decide the scope of ongoing support.

PMO support at findn

findn Co., Ltd., based in Chiyoda-ku, Tokyo, supports project management through PMO, planning and scope definition, scheduling, risk and quality management, budget control and stakeholder reporting. It also provides system development, from requirements and design through testing, operations, modernisation and offshore delivery, and IT consulting on IT governance frameworks such as the FISC Security Guidelines and COBIT. findn is certified to ISO/IEC 27001:2022, and its CEO, Saravana Prathap (CISA), has more than 25 years of experience in IT and, since moving to Japan in 2005, has worked with major securities firms in Japan and abroad.