OPM3 (Organizational Project Management Maturity Model): OPM3 – Tutorial (about 60 minutes)

OPM3, the Organizational Project Management Maturity Model, is a standard from the Project Management Institute (PMI) that helps an organisation judge how well it turns strategy into results through its projects, programmes and portfolios, and then plan improvements in a sensible order. It was used by PMO leaders, portfolio managers, transformation teams and consultants in government, engineering, IT, telecoms and finance. After this tutorial you will be able to explain how the model is built, how an OPM3 assessment and improvement cycle works, what its results mean and do not mean, why PMI has retired it, and how its ideas still help when you assess project management maturity today.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The last edition is the Organizational Project Management Maturity Model (OPM3) – Third Edition, published by PMI in 2013. It followed the first edition (2003) and the second edition (2008), which was approved as an American National Standard (ANSI/PMI 08-004-2008). No fourth edition was published. PMI has retired the model: the OPM3 Professional credential for assessors was officially discontinued on 1 March 2017, and by 2020 OPM3 had been removed from pmi.org without a formal announcement, as practitioners noted in PM World Journal. It is no longer supported as an active product. For guidance in this area PMI points to The Standard for Organizational Project Management (OPM), published in 2018, which explains how to build and run organisational project management and how to use maturity models, but is not itself a maturity model. A PMI shop listing for the third edition still appears in search results, so printed copies circulate, but you should treat OPM3 as a withdrawn PMI standard whose concepts remain influential. This course teaches the model as described in its later editions, notes where the first edition differed, and is honest about what is no longer available. Verified 2026-10-29 against PMI's published list of its standards and credential history, PM World Journal (November 2020) and published secondary sources; PMI's own pages could not be opened directly, and PMI never issued a formal withdrawal notice, so no exact retirement date for the model itself is given here.

Who it is for: PMO staff, portfolio and programme managers, project managers moving into governance roles, quality and process improvement specialists, and managers who have been asked "how mature is our project management?" and want to understand one of the best-known answers to that question.

Prerequisites: none. It helps if you know the difference between a project, a programme and a portfolio, but the tutorial explains these terms before using them.

By the end of this tutorial:

You will be able to explain what organisational project management (OPM) is and why PMI created a maturity model for it.
You will be able to describe the OPM3 construct: best practices, capabilities, outcomes, key performance indicators and the dependencies between them.
You will be able to place a best practice using the model's dimensions: domain, stage of process improvement (SMCI), process group and organisational enabler.
You will be able to walk through the OPM3 cycle of acquiring knowledge, performing an assessment and managing improvement.
You will be able to interpret an OPM3-style result and explain why it is a position on a continuum rather than a certificate or a single level.
You will be able to compare OPM3 with CMMI, P3M3, Kerzner's maturity model, PMI's 2018 OPM standard and the ISO project, programme and portfolio guidance.
You will be able to apply the model's lessons to a maturity assessment today, despite its retirement.

Lesson 1 – Origins, purpose and scope

The problem OPM3 set out to solve

By the late 1990s many organisations were good at running individual projects. They had trained project managers, a methodology and perhaps a PMO. Yet strategy still failed to turn into results. The wrong projects were started, too many ran at once, scarce specialists were spread thin, and successful deliveries did not add up to the benefits the board had expected. The gap was not inside each project but between strategy and the collection of projects. An organisation could do projects right without doing the right projects.

PMI's answer was to talk about organisational project management: the systematic management of projects, programmes and portfolios, linked to each other and to the organisation's strategy. If that is the target, an organisation needs a way to ask how far along it is, which weaknesses matter most and what to fix first. That is the job of a maturity model, and OPM3 was PMI's attempt to write one that covered all three levels of work at once.

How the model was developed

PMI started the OPM3 programme in the late 1990s. The development team studied existing maturity models (a presentation by Lynda Bourne cites 27 contemporary models), and volunteers took part from more than 35 countries, with reports of over 800 contributors. The team deliberately avoided simply copying the five-level staircase popularised by the software Capability Maturity Model. Instead it built a large database of best practices, each broken down into the capabilities that make it real and the evidence that shows it is present.

The first edition appeared in 2003. Because the model was so detailed, PMI soon packaged its assessment content in software. PMI formed an alliance with the classification and certification company Det Norske Veritas (DNV), and in 2006 the OPM3 ProductSuite was launched: assessment software plus training and certification for assessors and consultants. The second edition, published in December 2008, reflected field experience, aligned the model with PMI's newly revised project, programme and portfolio standards and became an American National Standard. The third edition followed in 2013, released alongside and aligned with the fifth edition of the PMBOK Guide and the third editions of PMI's programme and portfolio standards.

Retirement

The model's later history matters for anyone studying it today. The licensed assessment route proved expensive and was not widely adopted. PMI officially discontinued the OPM3 Professional credential on 1 March 2017 and no longer allows former holders to use the designation. In 2018 it published The Standard for Organizational Project Management (OPM), which describes how to design, implement and sustain OPM and discusses maturity models in general. By 2020 OPM3 had disappeared from PMI's website without a formal announcement. Commentators such as Peter Rogers, writing in PM World Journal in November 2020, have criticised the quiet way this happened and noted that the detailed capability and outcome statements are no longer part of any current PMI standard.

Scope: what OPM3 covers

OPM3 covers the whole system by which an organisation selects, governs and delivers work through projects, programmes and portfolios. It looks at processes (how work is initiated, planned, executed, controlled and closed at each level) and at the organisational conditions that support those processes: structures, culture, technology and people. It does not tell you how to manage a single project; that is the job of the PMBOK Guide. Nor does it prescribe an organisation chart or a tool. It describes what a mature organisation can do and lets each organisation decide which of those abilities it actually needs.

Why it is still worth learning

Even though PMI no longer supports OPM3, three of its ideas remain useful. First, maturity should be judged across portfolio, programme and project management together, not only at project level. Second, a practice is not mature until it has been standardised, measured, controlled and continuously improved. Third, an improvement plan should follow the dependencies between capabilities instead of chasing a single headline score. Many assessment approaches used by consultancies and PMOs today still borrow these ideas, and you will meet OPM3 vocabulary in research papers, job descriptions and older PMO documentation.

Lesson 2 – Key concepts and vocabulary

OPM3 uses everyday words in specific ways. The definitions below are paraphrased in plain language; the standard's own glossary is longer and more precise.

Project – a temporary effort to create a unique product, service or result. It has a defined start and end.
Program (programme) – a group of related projects and other work managed together to obtain benefits that would not be available if they were managed separately.
Portfolio – a collection of projects, programmes and other work grouped together so that the organisation can select, prioritise and balance them to meet strategic objectives.
Organisational project management (OPM) – the framework that connects portfolio, programme and project management with organisational strategy and with supporting practices, so that the organisation consistently delivers its strategic goals.
OPM maturity – how far an organisation can deliver its strategy reliably and predictably through projects, programmes and portfolios. In OPM3 it is expressed as a position on a continuum, not as a single named level.
Best practice – in OPM3, a statement of an ability the organisation should have, recognised by the profession as an optimal way to achieve a stated goal. The model contains hundreds of them; the first edition database was described as holding about 600.
Capability – a specific competency that must exist for a best practice to be in place. A best practice is achieved only when all its capabilities exist. The first edition was described as containing around 3,000 capabilities.
Outcome – the tangible or intangible result that shows a capability exists, such as a published procedure, a functioning review board or a change in behaviour.
Key performance indicator (KPI) – the criterion used to decide whether an outcome is present, either by direct measurement (a number) or by expert judgement.
Dependency – a relationship in which one capability builds on another, either within the same best practice or across best practices. Dependencies are what turn a long list of practices into an improvement path.
Domain – one of the three levels at which practices apply: project, programme and portfolio management.
SMCI – the four stages of process improvement used to classify process-related best practices: Standardise, Measure, Control and continuously Improve.
Organisational enabler – a structural, cultural, technological or human-resource practice that supports and sustains best practices across projects, programmes and portfolios, for example sponsorship, competency management or a shared information system.
Assessment – the comparison of the organisation's current practices against the model to find which best practices and capabilities are present and which are missing.

Best practice versus capability: an analogy

Think of a best practice as a dish on a menu and capabilities as the ingredients and kitchen skills needed to cook it. "The organisation uses a standard method to prioritise projects against strategy" is a dish. To serve it reliably the kitchen needs several ingredients: agreed strategic criteria, a scoring method, a forum that applies it, people trained to use it and a record of decisions. The outcomes are what a diner can see on the plate, and the KPIs are how a food inspector decides whether the dish is really there. Missing one ingredient means the dish cannot be served, however good the others are.

Maturity is not the same as size or bureaucracy

A common misunderstanding is that a mature organisation has more templates, more meetings and more forms. In OPM3 terms maturity is about reliability and alignment: whether the organisation consistently picks work that serves its strategy and delivers it predictably. A small organisation with light but consistent, measured and improving practices can be more mature than a large one with thick manuals that nobody follows. This is why the model asks for evidence of outcomes rather than counting documents.

Lesson 3 – Structure of the model

Three interlocking elements

OPM3 describes itself through three elements that give the model its name: Knowledge, Assessment and Improvement. The Knowledge element explains OPM, maturity and the content of the model. The Assessment element is the method and tools for comparing an organisation with the model. The Improvement element turns assessment results into a plan and helps the organisation carry it out. The elements are meant to be used together and repeatedly, as a cycle, which Lesson 4 describes.

The construct: from best practice to evidence

At the heart of OPM3 is a hierarchy that links an aspiration to observable evidence. Each best practice is made up of capabilities. Each capability is demonstrated by one or more outcomes. Each outcome is checked through a KPI. Capabilities are linked by dependencies, so building one capability may require another to exist first, sometimes in a different best practice. The first edition database was described as holding about 4,000 such relationships.

Figure 2 – The OPM3 construct: a best practice exists only when all its capabilities exist; each capability is shown by outcomes that KPIs confirm, and dependencies link capabilities within and across best practices.

This structure is what made OPM3 different from simple questionnaires. A survey might ask "Do you prioritise projects?" and accept "yes". OPM3 asks which specific capabilities sit underneath that practice, what outcome proves each one, and what indicator confirms the outcome. It also tells you that some capabilities cannot be built until others exist, which is information you need to plan improvement.

The dimensions used to classify best practices

Each best practice is tagged along several dimensions, which lets an organisation filter the model to its own scope and read results in useful slices.

Domain. Practices belong to project, programme or portfolio management. An organisation that only runs individual projects might start by assessing the project domain, while one that has a strategic investment board would include portfolio practices. OPM3 argues that full OPM maturity needs all three domains to work together, because excellent projects inside a poorly chosen portfolio still waste money.

Stage of process improvement (SMCI). Process best practices are arranged by four stages that echo classic quality management thinking:

Standardise – the process exists, has an owner, is documented and is used consistently.
Measure – the process is measured, customers' needs are reflected in the measures, and the right inputs are identified.
Control – the measurements are used to keep the process stable and predictable, with action taken when it drifts.
Continuously improve – problems are analysed for root causes and the process is improved in a sustained, organisation-wide way.

The order matters. You cannot meaningfully measure a process that is done differently every time, and you cannot control a process you do not measure. SMCI therefore gives each process a natural path upwards.

Figure 3 – The SMCI stages of process improvement: each stage builds on the one before it, and the same path applies to processes in the project, programme and portfolio domains.

Process groups. Process best practices are also linked to the process groups familiar from the PMBOK Guide. The first edition used Initiating, Planning, Executing, Controlling and Closing; later editions followed PMI's wording of the time, in which the fourth group became Monitoring and Controlling. This lets an assessment show, for example, that planning is standardised in all domains but controlling is weak at programme level.

Organisational enablers. Not every best practice is a process. Some describe the conditions that let processes work: structural enablers such as governance bodies and a PMO; cultural enablers such as sponsorship and a shared vision; technological enablers such as common tools and knowledge repositories; and human-resource enablers such as competency frameworks, career paths and resource allocation. The later editions present these organisational enablers as their own category. They do not climb the SMCI path in the same way process practices do; they either exist and support the processes or they do not.

No single maturity level

Unlike staged models such as CMMI or Kerzner's model, OPM3 does not award an overall level from 1 to 5. Its designers argued that maturity has several dimensions and that collapsing it into one number hides the information an organisation needs. Results are expressed as the proportion of applicable best practices that the organisation has achieved, often shown as a percentage along a continuum, and broken down by domain, SMCI stage and enabler category. Some secondary sources loosely call the SMCI stages "maturity levels", but they are stages of process improvement applied to individual processes, not a rating for the whole organisation.

What lives in the book and what lived in the tools

The published editions explain the concepts, the cycle and the lists of best practices. The detailed capability statements, outcomes, KPIs and dependency data were, for much of the model's life, delivered mainly through the licensed ProductSuite tools and the certified assessor route. That is one reason the model is hard to use fully today: commentators report that the detailed capability content is no longer available as part of any PMI standard. When you read OPM3 material, check which edition it comes from and whether it includes the capability level or only the best-practice list.

Lesson 4 – How OPM3 works in practice

The OPM3 cycle

OPM3 is not a one-off audit. It is designed as a repeating cycle. The first edition described five steps: prepare for assessment, perform the assessment, plan improvements, implement improvements, and repeat the process. Later editions grouped the work into three phases that map onto the model's elements: Acquire Knowledge, Perform Assessment and Manage Improvement. The phases are explained below, using the five steps where they help.

Phase 1 – Acquire Knowledge

Before assessing anything, the people leading the effort must understand three things: what OPM is, how the model is structured, and how their own organisation works. The last of these is often skipped, yet it matters most. Assessors need to know the strategy, the way investment decisions are made, the governance bodies, the delivery methods in use and the culture. Without this they cannot judge whether a best practice is relevant or whether the evidence they see is genuine.

Typical outputs of this phase are a sponsor, an agreed purpose for the assessment (for example "prepare the portfolio office for a new five-year capital plan"), an assessment scope, and a small team that combines people who know the model with people who know the business.

Phase 2 – Perform Assessment

The assessment compares current practice with the model. Scope decides which domains, business units and best practices are included. A team assessing only an IT delivery department might leave out portfolio practices owned by the corporate strategy office; a team supporting a board-level investment review would put them in. The scope should be written down and agreed with the sponsor, because it determines what the result means.

OPM3 supported two depths of assessment. A high-level self-assessment used a questionnaire, provided with the first edition, to give a quick indication of which best practices were likely present. A comprehensive, rigorous assessment examined capabilities and outcomes in detail, gathered evidence through document review and interviews, and in the ProductSuite era was led by a certified assessor using PMI's licensed software. The results show which best practices are achieved, which capabilities are missing, and how the picture looks by domain, SMCI stage and enabler.

An assessment is only as good as its evidence. Assessors look for outcomes in use, not intentions. A portfolio prioritisation procedure that exists on the intranet but has not been applied to last quarter's investment decisions does not show the capability. Interviews at several levels, samples of real decisions and data from tools are all ways to confirm what the organisation actually does.

Phase 3 – Manage Improvement

The assessment produces a long list of gaps. The improvement phase turns that list into a realistic plan. Three questions drive the plan. Which gaps matter most for the organisation's strategy? Which capabilities must exist first because others depend on them? What can the organisation absorb at once? OPM3 recommends running improvement initiatives as projects or a programme themselves, with sponsors, scope, schedule, resources and benefits, and aligning them with the organisation's strategic priorities.

After implementation the organisation chooses its next move. It can carry on with the next planned improvement or reassess to see how far it has moved. Over time this creates a loop of learning: each round of improvement changes the organisation, and the next assessment starts from a new baseline.

Roles

An executive sponsor who owns the purpose of the effort, funds it and removes obstacles.
An assessment lead who knows the model well, plans the assessment and protects the integrity of the evidence.
Assessors and subject-matter experts from portfolio, programme and project management, finance, HR and IT.
Interviewees across the organisation, from executives to project team members.
Improvement owners who lead the resulting initiatives and report progress.

Artefacts

A typical OPM3 effort produces an assessment charter (purpose, scope, sponsor, timing), an evidence log, an assessment report that lists achieved and missing best practices and capabilities with supporting evidence, a prioritised improvement roadmap, a set of improvement project charters, and later a reassessment report that compares the new position with the baseline.

Linking to business value

OPM3 treats maturity as a route to business value: improvement paths are chosen to meet the organisation's own strategic needs. An improvement plan should explain how each change will help the organisation achieve its goals: fewer failed investments, faster time to benefit, better use of scarce people, more reliable forecasts. Maturity is a means, not the goal. If a capability does not serve the strategy, it can wait.

Lesson 5 – Assessment, certification and compliance

What an OPM3 result tells you

An OPM3 assessment answers three questions. Where are we now? Which best practices and capabilities are present and which are missing in each domain and SMCI stage? Which gaps should we close first? The overall result is a position on a continuum, often shown as a percentage of applicable best practices achieved. The more useful output is the breakdown, because it points to specific improvements.

Two cautions apply. First, a percentage is only meaningful in relation to the agreed scope. Seventy per cent of project-domain practices in one department is a very different statement from seventy per cent of all practices across the enterprise. Second, a higher score is not automatically better business. A score that rises because the organisation adopted practices it does not need adds cost without value.

Self-assessment versus rigorous assessment

A self-assessment is quick and cheap and is good for building awareness, starting conversations and choosing where to look more closely. It is also prone to optimism: people answer about the process they believe exists. A rigorous assessment takes longer, requires evidence for each capability and uses trained assessors, but it produces results that can support investment decisions and can be compared over time. Many organisations used both: a self-assessment to orient, followed by a deeper assessment of the priority areas.

Was there an OPM3 certification?

There was never a certificate that declared an organisation "OPM3 compliant" or "OPM3 level 4". OPM3 is a maturity model for improvement and benchmarking, not a certifiable management system standard like ISO 9001. What PMI did certify was people. During the ProductSuite period, consultants and assessors could be trained and certified to run ProductSuite assessments and improvement work, at first through the DNV alliance. Later PMI offered an OPM3 Professional credential for individuals. That credential was discontinued on 1 March 2017, and PMI no longer supports OPM3 as a product. Today, therefore, there is no official OPM3 assessment scheme, no register of certified OPM3 assessors and no PMI-recognised OPM3 result.

If a supplier or consultant claims an "OPM3 rating" today, ask what method they used, which edition and which content (best practices only, or capabilities and outcomes too), who did the assessment, what scope it covered and what evidence was gathered. The answers will tell you whether the result is a structured self-assessment inspired by OPM3 or something more rigorous. Either can be useful, but neither is an official PMI certification.

Compliance and regulation

No regulator requires OPM3. Organisations used it voluntarily, sometimes because a large client or a government programme asked suppliers to show project management maturity. Where such requirements exist today they usually refer to other models (for example P3M3 in some public sectors) or simply ask for evidence of a credible maturity assessment.

Benchmarking

One attraction of the ProductSuite was the promise of benchmark data: comparing your results with other organisations that had been assessed using the same tools. That data was owned by PMI and its partners and is not publicly available. Anyone using OPM3 ideas today should benchmark against their own earlier results or against peers who used the same method, and should be cautious about comparing percentages produced by different approaches.

Lesson 6 – Worked example

The situation

Coastline Water is a fictional regional water utility with 2,400 staff. A regulator has approved a five-year capital plan with about 180 projects, from pipe replacement to a new customer billing system. In the previous plan period a third of the projects finished late, two large programmes overlapped and competed for the same engineers, and the board could not see which projects supported which strategic goals. The new chief operating officer asks the PMO to "find out how mature we really are and fix what matters". The PMO lead decides to use the OPM3 approach as a structured guide, aware that PMI no longer supports the model and that no official certification is available.

Step 1 – Acquire knowledge and set scope

The PMO lead secures the COO as sponsor and forms a team of five: two PMO analysts, a programme manager from the engineering division, a finance business partner and an HR adviser. The team spends two weeks learning OPM concepts and the OPM3 structure, then maps how Coastline actually decides and delivers work: the investment committee, the capital planning cycle, the engineering stage-gate process and the IT delivery method. They agree a written scope with the sponsor: all three domains, the engineering and IT delivery units, and all enabler categories. Customer operations, which runs few projects, is left out of the first round.

Step 2 – A quick self-assessment

The team runs a short questionnaire with 40 managers. The self-assessment suggests the project domain is fairly strong, the programme domain is weak and the portfolio domain is mixed. Interestingly, engineering managers rate project control much higher than IT managers do. The team treats these results as hypotheses, not findings.

Step 3 – A deeper assessment of the priority areas

The team then assesses selected best practices in detail, gathering evidence for each capability. They sample 20 recent projects, review the last four investment committee papers, interview 30 people and analyse resource data. The main findings are:

Project domain: standardised in engineering, partly standardised in IT. Schedule and cost are measured on most projects, but nobody uses the data to adjust estimates, so the Control stage is not reached.
Programme domain: programmes exist on paper, but there is no standard way to manage benefits or dependencies between projects. Most programme practices are missing at the Standardise stage.
Portfolio domain: the investment committee meets regularly, but projects are scored on cost and regulatory urgency only; links to strategic objectives are not recorded, and there is no regular portfolio rebalancing.
Enablers: there is strong executive sponsorship, but no shared resource management tool and no competency framework for programme managers.

Expressed as a continuum, the team estimates that Coastline has achieved roughly half of the best practices in scope for projects, about a fifth for programmes and about a third for portfolio. The team presents these figures only as an internal baseline and explains that they come from its own adaptation of OPM3, not from an official tool.

Step 4 – Plan improvements using dependencies

The temptation is to tackle the biggest gap, the programme domain, all at once. The team looks at dependencies instead. Programme benefits management depends on knowing which strategic objective each project supports, which is a portfolio capability. Resource balancing across programmes depends on reliable resource data, which needs a shared tool and an agreed way of recording assignments. The roadmap therefore runs in three waves:

Wave 1 (6 months): add strategic alignment criteria to the investment committee's scoring; introduce a single resource register for engineering and IT; standardise project status reporting in IT to match engineering.
Wave 2 (6–12 months): introduce a standard programme management approach with benefits registers; start measuring forecast accuracy on projects and feed it back into estimates; launch a competency framework for programme managers.
Wave 3 (12–24 months): quarterly portfolio rebalancing using resource and benefit data; control limits for schedule variance; a lessons-learned process that changes standards.

Each wave is run as a small programme with its own sponsor, plan and measures. The roadmap is linked to business value: fewer late projects, less engineer overtime and a clear line of sight from each project to the regulator's commitments.

Step 5 – Reassess and continue

Eighteen months later the team reassesses the same scope with the same method so the results can be compared. Programme practices have moved from a fifth to about a half achieved. Portfolio alignment criteria are applied to every investment paper. Project control has improved in engineering but still lags in IT, so the next round focuses there and extends the scope to customer operations.

What the example shows

The example shows the core OPM3 ideas at work: a clear scope agreed with a sponsor, a quick self-assessment followed by evidence-based assessment, results read by domain, stage and enabler rather than as one number, an improvement plan ordered by dependencies and value, improvements managed as projects, and reassessment with the same method. It also shows a responsible way to use a retired model: as a structured reference for internal improvement, clearly labelled as such.

Lesson 7 – Relationship to other standards and frameworks

OPM3 sits in a family of PMI standards and among several other maturity models. Knowing these relationships helps you choose what to use today and read older OPM3 material correctly.

Framework	Owner	What it is	Relationship to OPM3
PMBOK Guide, Standard for Program Management, Standard for Portfolio Management	PMI	Foundational standards for managing projects, programmes and portfolios	OPM3 drew its process best practices from these standards and each edition was aligned with their current editions; they describe how to do the work, OPM3 described how to judge and improve the organisation's ability to do it
The Standard for Organizational Project Management (2018)	PMI	Standard describing how to design, implement and sustain OPM, including governance and the use of maturity models	PMI's current guidance in this area; it covers OPM and maturity in general and is not a detailed maturity model, so it does not replace OPM3's best-practice database
CMMI (current version V3.0)	ISACA (CMMI Institute)	Model of practices with maturity and capability levels and formal appraisals	Both describe maturity through practices; CMMI gives formal ratings and covers development, services and suppliers, while OPM3 focused on the portfolio, programme and project system and gave a continuum instead of levels
P3M3	Axelos (PeopleCert)	Portfolio, Programme and Project Management Maturity Model with five levels across several perspectives	Covers the same three domains as OPM3 but uses staged levels; it remains maintained and is widely used, especially in UK public bodies
Kerzner Project Management Maturity Model	Harold Kerzner (author)	Five-level model from common language to continuous improvement, with assessment questionnaires	Simpler and project-focused; useful for a quick view, while OPM3 aimed at the whole portfolio, programme and project system with much more detail
ISO 21502, ISO 21503, ISO 21504	ISO	Guidance standards on project, programme and portfolio management	Describe good practice at each level, as PMI's foundational standards do; they are not maturity models but can serve as the reference against which practices are assessed

Choosing an approach today

If you need a maintained maturity model with a defined assessment method, P3M3 or CMMI are the usual choices, depending on whether your focus is portfolio and programme governance or engineering and service delivery. If you need to design or strengthen OPM itself, PMI's 2018 standard and the ISO 2150x series give the structure. OPM3 remains a valuable source of ideas: the three-domain view, the SMCI path, organisational enablers and dependency-driven improvement plans. You can use these ideas inside any of the maintained frameworks, as long as you do not present the result as an official OPM3 rating.

OPM3 and agile ways of working

Some practitioners see maturity models as incompatible with agile delivery. OPM3 does not prescribe a life cycle, so its ideas can be applied to agile programmes: standardising how teams plan and review, measuring flow and outcomes, controlling work in progress, and improving through retrospectives. The portfolio-level practices, such as linking work to strategy and rebalancing based on value, are central to scaled agile approaches too.

Common pitfalls and best practices

Common pitfalls

Treating the overall percentage as the goal, so teams adopt practices to raise the score rather than to deliver strategy.
Assessing only the project domain and concluding the organisation is mature, while portfolio selection and programme benefits remain weak.
Accepting self-assessment answers as facts without checking outcomes in real decisions and documents.
Trying to close every gap at once instead of following dependencies, so new practices fail because the capabilities underneath them do not exist.
Skipping the knowledge phase, so assessors do not understand either the model or the organisation's real decision paths.
Presenting a home-made OPM3-style score as an official certification or comparing it with numbers produced by other methods.
Ignoring enablers such as sponsorship, competencies and tools, and wondering why well-written processes are not followed.

Best practices

Start with a clear purpose and scope agreed with an executive sponsor, and record both in the assessment report.
Use a quick self-assessment to orient, then gather evidence in the areas that matter most for strategy.
Read results by domain, SMCI stage and enabler, not only as a single figure.
Order improvements by dependencies and business value, and manage them as projects or a programme with measurable benefits.
Reassess with the same method and scope so that progress can be compared honestly.
Be transparent that OPM3 is retired: use it as a reference and say which edition and content you used.
Combine OPM3 ideas with maintained standards, such as PMI's current standards, ISO 2150x guidance or P3M3, where a current reference is needed.

Summary and key takeaways

OPM3 is PMI's Organizational Project Management Maturity Model, published in three editions (2003, 2008, 2013); PMI has since retired it and points to its 2018 Standard for Organizational Project Management.
It judges how well an organisation delivers strategy through projects, programmes and portfolios together, not just how well it runs single projects.
Its construct links best practices to capabilities, outcomes and KPIs, with dependencies that show which capabilities must exist first.
Best practices are classified by domain, SMCI stage of process improvement, process group and organisational enabler category.
The cycle of acquiring knowledge, performing an assessment and managing improvement is meant to be repeated, with improvements run as projects.
Results are a position on a continuum with a detailed breakdown, not a single maturity level; there was never an organisational certificate, and the individual credential ended in 2017.
Its ideas remain useful inside maintained frameworks, provided you are open about what you used and do not claim an official rating.

Reflection questions

Think of your own organisation. Which of the three domains, project, programme or portfolio, do you believe is weakest, and what evidence would you gather to test that belief?
Pick one process you know well, such as change control or project prioritisation. Describe what it would look like at each SMCI stage in your environment.
Which organisational enabler (structural, cultural, technological or human resource) most limits project success where you work, and how would you show its effect to an executive?
A colleague proposes presenting "OPM3 maturity 62 %" to the board. What questions would you ask before agreeing, and how would you frame the figure?
If you had to start a maturity assessment next month, would you use OPM3 ideas, P3M3, CMMI or a mix? Justify your choice using your organisation's goals.