• Book Reviews
• Cultural Diversity
• Project Management
• Risk
• Technology

You are here:

1. Home »
2. PM Topics »
3. Taking OPM3 to the Next Level

Taking OPM3 to the Next Level

Have you ever been riding on an elevator and overheard one executive say to another that his or her company is working on maturity level 3, 4, or 5? In any maturity model, whether the Project Management Institute’s (PMI) OPM3 or the Software Engineering Institute’s (SEI) CMMI or any number of other models, a maturity level is a set of performance requirements with rules regarding how those requirements are met in order to achieve higher distinctions of maturity or performance. Levels signify compelling improvement goals and milestones in the journey to excellence. Each maturity model describes maturity or advanced capabilities in a specific domain (like software development, or human resource management, or project management), and each maturity model contrives maturity levels in a way that makes sense for its intended use and audience.

The Project Management Institute’s OPM3 maturity model describes Best Practices and advanced capabilities in the specific domain of Organizational Project Management (OPM), which is the science and art of choosing the right projects to advance organizational strategies, and the implementation of the processes, structures, and behaviors necessary to deliver projects successfully, consistently, and predictably. As will be explained below, because of its ingenious modular architecture, PMI’s OPM3 offers richer maturity profiles than other current models. However, PMI has not standardized naming conventions for OPM3 maturity levels, much less standardized naming conventions for the most commonly assessed and sought OPM3 maturity profiles. If we wish levels to become formal designations, signifying the shorthand for an organization's vision or goal for the future (or its accomplishments to date), then how should we leverage the ingenious modular architecture and existing groups of OPM3 content to help organizations get their heads and hearts around the transformational possibility of OPM3? 

An elevator speech is so called because it can be delivered in the time span of an elevator ride. Venture capitalists often judge the quality of an idea and team on the basis of the quality of its elevator pitch, and will ask entrepreneurs for the elevator pitch so to quickly weed out bad ideas. It has been said that many of the most important decisions made on the floor of the United State’s House or Senate are made “within the span of an elevator ride” as a staff aide whispers into a Congressman or Senator’s ear while they head to the floor to cast their vote. A variety of other people commonly use elevator speeches to get their point across quickly.

Any number of approaches may work for an OPM3 elevator speech, but a few key points should always be made, including the following:

• The Project Management Institute is the leading global advocate of the project management profession.
• Members of the profession have developed a PMI Capability Maturity Model that is designed exclusively to help companies improve the project management, program management, and portfolio management of projects, unlike the SEI’s CMMI.
• The PMI Capability Maturity Model is applicable to all kinds of organizations and all kinds of projects.
• It is an industry standard developed by hundreds of project management practitioners in 35 countries, unlike commercial models developed by individual companies interested in promoting their intellectual property.

Once these key facts are out of the way, the next logical statement is something about the possibility of adopting certain OPM3 Best Practices or achieving certain Capabilities within a particular time horizon, like “achieving level 2 by next quarter.” The problem, however, is that PMI has not decided on standard naming conventions for OPM3 maturity levels.

The requirements for achieving each OPM3 Best Practice are already defined in OPM3, but groups of Best Practices that should be accomplished together (as levels) in order to distinguish maturity in compelling ways have not been defined as a market standard. The new OPM3 ProductSuite Assessment Tool, however, does group OPM3 content that should be addressed together, and this is done from the perspective of scoping an assessment or scoping an improvement initiative. The OPM3 ProductSuite Tool also allows the certified user to characterize maturity results by level (or stage, as it is called in OPM3) and by a point system in which the organization can earn points for each Best Practice, individual Process Group, or Domain.

Despite the advance that is the OPM3 ProductSuite, PMI is still catching up as regards sanctioning relevant groups of content as levels in the OPM3 standard that the OPM3 ProductSuite is based upon. What the marketplace already knows is that maturity levels, which are purely human inventions contrived to facilitate change, communicate in simple terms maturity goals that people inside an organization can rally behind. Maturity levels also become meaningful qualifications in a competitive marketplace, pre-qualifying service providers and distinguishing one’s company from competitors.

The original OPM3 program team decided deliberately not to impose levels in the manner that some other popular models had. The rationale for this decision was that the marketplace should (and will, hopefully soon) decide the levels that become the shared norms for distinguishing stages of maturity. Since OPM3’s debut many users have viewed the stages of process management described in the OPM3 as the maturity levels, i.e. Standardization, Measurement, Control, and Continuous Improvement (Level S, Level M, Level C, Level I) across the domains of Project Management, Program Management, and Portfolio Management. Indeed these are the de facto maturity levels of OPM3. But these levels or sections of content are unnecessarily large buckets of requirements for some users, and OPM3 lets you split these into smaller buckets. Many OPM3 users will not necessarily want to implement all of the Best Practices defined in the standard; some users, for example, are interested exclusively in Portfolio Management, while some are interested exclusively in Project Management or Program Management. So, how do you define levels that are relevant to most organizations most of the time? Fortunately OPM3’s ingenious architecture allows more refined levels than S, M, C, and I, and can distinguish organizations in more useful and more compelling ways. Below I suggest various ways to group content within OPM3 beyond the de facto levels. I describe scenarios that can be sanctioned by PMI as the standard for communicating OPM3 maturity levels. My goal is to advance the dialogue among current users of OPM3, volunteers on the current OPM3 update team, and PMI.

It is interesting how some things come around full circle. The very first PMI Standards Committee meeting in 1998 about whether to create a maturity model (OPM3) was largely about levels. In that meeting we talked about levels in the SEI SW-CMM versus SPICE's approach, and so on. The first task was to analyze dozens of existing models in the marketplace, and that task was assigned to me. Little did I know at the time that I would immediately become PMI’s project manager for this little project called OPM3, which grew to a team of over 800 volunteers from 35 countries, and consumed nearly half a decade of my life before we delivered a prototype based on surveys of 30,000 project management professionals. Now, years later, after OPM3 has been adopted by leading companies in industries ranging from telecommunications and financial services to education and defense, the time has come to revisit the naming of OPM3 maturity levels in order to socialize OPM3 benchmarking with the next generation of users. When I looked into the question of levels on PMI’s behalf for the first time in 1998, I learned that the two prevalent structures of existing models were hierarchical and continuous. In hierarchical maturity models, a level defines requirements that must be addressed all at once, or together, or as a whole before proceeding to the next level. In continuous maturity models, a level defines requirements that are related but can be addressed separately or independently in order to proceed to the next level. There are valid arguments in favor of each structure in various contexts. So we tried to incorporate the best of both worlds in a way that would add value beyond existing approaches, while allowing the ways we package the model to evolve with the marketplace, as explained below. This resulted in a modular architecture that permits future users (or PMI, if truth be told) to redefine levels, should they so choose, without reinventing the underlying model. OPM3 is a hierarchical model insofar as Best Practices in Standardization are predecessors to Best Practices in Measurement, which are predecessors to Best Practices in Control, which are predecessors to Best Practices in (Continuous) Improvement. But OPM3 is a continuous model insofar as users can choose any number of processes they wish to make capable from among the three domains of Project, Program, and Portfolio Management. In summary, OPM3 is both hierarchical and continuous, but more importantly it is modular.

In order to understand how the underlying architecture of OPM3 is modular, it helps to visualize a device that is common in the management of projects: the network diagram. As all professional project managers know, a network diagram is a schematic display of the sequential and logical relationship of the activities that comprise a project, (Figure1).


Figure 1: This is an example of a network diagram of a project schedule.

OPM3 is much like the network diagram of a project, although the OPM3 network is depicted as directories of Best Practice statements and Capability statements in a textual format rather than a graphical one. A Best Practice in OPM3 is like the project finish in a network diagram, whereas the lowest (or least advanced or least mature) Capability related to that Best Practice is like the project start in the network diagram. We can, quite simply, define levels in much the same way that one asserts that sections of a schedule are stages, (Figure 2).


Figure 2: Because OPM3 contains an underlying network of testable capability statements aggregating to Best Practice statements, by superimposing categories or groups or boundaries onto sections of the OPM3 network, we can define maturity levels in much the same way that one asserts that sections of a schedule are stages by grouping sets of tasks or activities.

No matter what the maturity levels are called, or which Best Practices and Capabilities are grouped into a level, the underlying network diagram will dictate the sequence of capability assessment and development, (Figure 3).


Figure 3: No matter what is grouped into a maturity level, the network defines the sequence of Capability development.

No other existing maturity model defines all the dependencies among Best Practices and constituent Capabilities, but OPM3 does. Instead of a network diagram, call it modular architecture. The modular architecture is the same feature that allows OPM3 to be scaled to fit any organization. You can choose any combination of Best Practices to implement. Granted, some Best Practices depend on others (for example, Measurement Best Practices depend on Standardization Best Practices), and this is hard coded as the underlying network in the model. If you choose a Measurement Best Practice, you will automatically pull in the preceding Standardization Best Practice, and the sequence of developing the capabilities required to implement these Best Practices is shown clearly to the user. Likewise, simply by demarcating sections of the underlying OPM3 network, PMI can choose any combination of Best Practices to sanction as a specific group of testable statements that will be assessed together (as a discrete maturity level). PMI can choose any combination of Best Practices that will be accomplished or implemented together (as a discrete maturity level) in order to signify compelling improvement goals and milestones in the journey toward continuous improvement. Whether PMI groups less content in initial levels, (Figure 2) or more content, (Figure 3), the underlying modular architecture (or network diagram) of OPM3 remains the same.

In addition to defining the dependencies described above, the team that developed OPM3 suggested some useful groups of content. OPM3 has 3 domains (Project, Program, and Portfolio) and 4 stages (Standardization, Measurement, Control, Continuous Improvement), which is a total of 12 groups of content.


Figure 4: OPM3 has 3 domains and 4 stages, resulting in 12 groups of content.

Within each of the domains of Project, Program, and Portfolio Management, many processes are defined that can be Standardized, Measured, Controlled, and Continuously Improved. We can group content into levels by domains, processes, stages, or combinations of these.

If we wish levels to become formal designations signifying the shorthand for an organization's vision or goal for the future (or its accomplishments to date), then how should we leverage the ingenious modular architecture and existing groups of OPM3 content to help organizations get their heads and hearts around the transformational possibility of OPM3?

SCENARIO 1
You could simply say the four stages of S, M, C, I across the 3 domains (project management, program management, portfolio management) are the levels (S PPP = level 1, M PPP = level 2, C PPP = level 3, I PPP = level 4), but anyone using the model for less than all 3 domains would not like it. There would be no scalability. A large number of organizations interested in only one of the domains would never achieve level 1, and OPM3 adoption would suffer. Figure 5 depicts this scenario.


Figure 5: PMI could designate the stages of process improvement as the sanctioned levels.

SCENARIO 2
Per Figure 6, you could simply say that the four stages of S, M, C, I are the levels in each domain respectively, separating each domain from the others. So, for example, you could be S (level 1) in one domain and C (level 3) in another. This offers scalability. But the need to be the same level in two or more domains becomes an issue at the M level (level 2) . Ask yourself this question: Can you really do Program Management if you can't do Project Management? How do the outputs of some processes become the inputs to other processes across the domains of Project, Program, and Portfolio Management? Certain processes are coupled and must be made capable together. That is, they must be Standardized together, then Measured together, then Controlled together, then Continuously Improved together.

In OPM3, at the M level, when you are assessing any given process, you identify that process’s inputs and the processes that are creating the outputs that become those inputs. You ensure that the critical inputs and feeding processes are measured, and in order for them to be measured (M) they must first be standardized (S).


Figure 6: PMI could designate each of the domains as discrete 4-level sub-models within OPM3.

SCENARIO 3
Per Figure 7, you could say that some combination of the four stages and domains is level 1. For example, achieving Standardization and Measurement in both the Project and Portfolio domains could constitute level 1. And so on. This offers scalability to varying degrees depending on the combinations.


Figure 7: PMI could designate combinations of domains and stages as levels.



The scenarios described above are based on various approaches to slicing and dicing the stages of process management (S, M, C, I) by domain process areas (Project, Program, Portfolio). As OPM3 users know, OPM3 includes content described as “Organizational Enablers” beyond mere process management. That is, OPM3 correctly distinguishes between a given process and the environment in which the process operates; both the process and the environment must be made capable. The categories of OPM3 Organizational Enablers include:

• Organizational Project Management Policy and Vision
• Strategic Alignment
• Resource Allocation
• Management Systems
• Sponsorship
• Organizational Structures
• Competency Management
• Individual Performance Appraisals
• Project Management Training
• Organizational Project Management Communities
• Organizational Project Management Practices
• Organizational Project Management Methodology
• Organizational Project Management Techniques
• Project Management Metrics
• Project Success Criteria
• Benchmarking
• Knowledge Management and PMIS

Any scenario of OPM3 maturity levels must designate how the Best Practices and constituent Capabilities of this value-added content are allocated to one maturity level or another. As with the content related to Standardizing, Measuring, Controlling, and Improving processes, the content related to Organizational Enablers is defined in terms of a network. No matter what the maturity levels are called, or which Organizational Enabler Best Practices and Capabilities are grouped into a level, the underlying network diagram will dictate the sequence of capability assessment and development.

Conclusion
The original OPM3 program team decided deliberately not to impose maturity levels in the manner that some other popular models had. The rationale for this decision was that the marketplace should decide the levels that become the shared norms for distinguishing stages of maturity, and now the time for that decision has come. Maturity levels facilitate change and communicate in simple terms maturity goals that people inside an organization can rally behind. Maturity levels also become meaningful qualifications in a competitive marketplace, pre-qualifying service providers and distinguishing one’s company from competitors. If we wish levels to become formal designations signifying the shorthand for an organization's vision or goal for the future (or its accomplishments to date), then we should leverage the ingenious modular architecture and existing groups of OPM3 content to help organizations get their heads and hearts around the transformational possibility of OPM3. PMI now has the opportunity to shape elevator speeches about OPM3 among executives ascending to boardrooms and to higher levels of maturity throughout the world.

References
Organizational Project Management Maturity Model (OPM3®). Project Management Institute, 2003. ISBN 1930699085.

John Schlichter, PMP

John Schlichter, founder and CEO of OPM Experts, is a recognized leader in the field of Organizational Project Management. "John Schlichter has contributed greatly to the Project Management Institute," said Greg Balestrero, CEO, PMI. John was the original Program Manager of the PMI OPM3 Program from the origination of the program in 1998 through delivery of the OPM3 prototype in 2002, and was subsequently contracted by PMI and DNV in the development of the OPM3 ProductSuite. "In John Schlichter's role as leader of the OPM3 program, he has immeasurably contributed to the growth of the (project management) profession," said Rebecca (Becky) Winston, J.D., Chair of the Board of Directors, PMI. John has implemented OPM3 in leading federal and commercial organizations in a variety of industries, and he is widely regarded as the world’s foremost expert in the content and application of PMI’s OPM3 Standard. John holds an MBA from the Goizueta Business School of Emory University and is a PMI Certified OPM3 ProductSuite Consultant. Visit http://opmexperts.com. For further discussion on the subject, please visithttp://opmexperts.com/mb/viewtopic.php?t=61. Registration to join the discussion on the message board is free.